Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add typescript definitions #25

Closed
wants to merge 6 commits into from
Closed

Conversation

chillitom
Copy link

should close #21

agilgur5 and others added 6 commits May 28, 2019 21:22
- needed to be auto-updated
- seems to have mostly added carets to deps
- no semicolons, no newline at the top
- also change props link to be on one line -- it's important enough
  that I don't think it should be in parens
- not sure if <object> makes sense, but it needed an argument
src/index.d.ts Show resolved Hide resolved
src/index.d.ts Outdated Show resolved Hide resolved
@@ -16,7 +16,7 @@ export interface IOptions {

// props specific to the React wrapper
export interface SignatureCanvasProps extends IOptions {
canvasProps?: any,
canvasProps?: React.CanvasHTMLAttributes<object>,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should the generic type be <object>?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or maybe leave it as a generic as <T>?: React.CanvasHTMLAttributes<T>? I'm not totally sure why it's a generic or best practices around them in TS

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure it should be a generic as that's referencing not the object containing the HTML attributes, but the attributes themselves which can be of various types, giving the object various potential shapes

src/index.d.ts Outdated
@@ -0,0 +1,22 @@
// signature_pad's props
// (taken from https://github.com/szimek/signature_pad/blob/e2af461bca7ceb7cc5afb8349930908ca19f2f56/src/signature_pad.ts#L23)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we import signature_pad's types directly from signature_pad? I haven't updated to the beta yet (as it's beta) so that might not be possible until then and this might be fine in the meantime

@@ -0,0 +1,22 @@
// signature_pad's props
// (taken from https://github.com/szimek/signature_pad/blob/e2af461bca7ceb7cc5afb8349930908ca19f2f56/src/signature_pad.ts#L23)
export interface IOptions {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be IOptions? or SignaturePadOptions? should it be (re-)exported?

package-lock.json Show resolved Hide resolved
@agilgur5
Copy link
Owner

agilgur5 commented May 29, 2019

Thanks for the (much requested) contribution @chillitom ! Took me a while to finally find the time to give this a proper review as there's a lot to consider here

Unfortunately, I'm not sure this should be merged. Aside from my comments in #21 (comment), which still stand, I also did some research since then and found that the TypeScript team themselves has explicitly said to publish types to DefinitelyTyped (@types) if the source code is not TS in https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html (c.f. inikulin/parse5#235 (comment) and inikulin/parse5#235 (comment)). This seems to lend a strong addition to my argument that "third-party typing makes more sense at this time".

I attempted to auto-generate the typings with lyft/react-javascript-to-typescript-transform to circumvent this argument, but not only is there quite a bit more work to do from this transform, it actually doesn't generate types, it transforms the entire JS into TS (with different formatting too). Its types are also not as specific as the ones from the signature_pad TS beta (which should always remain the same, if not just imported)

I added some comments & commits to the PR which made me a bit more familiar with TS, but I'm still not sure this should be merged (and my uncertainty in the comments certainly doesn't help 😅). Open to thoughts and counter-arguments

@benny-medflyt
Copy link

I believe that this PR is missing the style prop, which is valid and will be passed along to the underlying signature implementation

@agilgur5
Copy link
Owner

agilgur5 commented Aug 19, 2019

@benny-medflyt style is not an option of signature_pad and nor is it a direct prop of react-signature-canvas. You can only pass style through the prop canvasProps, which is already typed here.

@remiroyc

This comment has been minimized.

@agilgur5
Copy link
Owner

agilgur5 commented Dec 6, 2019

@remiroyc yes, as you can see, this PR is incomplete and has not been merged (and #21 is still open), therefore there are no types for this pure JS library. And as you can see above, I pretty much recommended the author of this PR submit these types to DefinitelyTyped (though there are still improvements to be made, some of which I made myself here).

As I wrote in #21 (comment), at the time this PR was written, I had never used TypeScript, so I could not reasonably maintain the typings myself, and no one stepped up to maintain them here or at DefinitelyTyped (including the author of this PR, who has not responded to comments).

I've now written a bit of TypeScript and actually do have a ts branch locally, and expect to have a TS re-write out in v1.1.0 before the new year. Now that there's 100% test coverage, that should also give us some confidence that the types are correct before publishing (might add some more tests too).


Was actually going to comment about this in #21 sometime soon, but guess I'll summarize some here. The big blockers are rewriting the 3.5 year old build system used here (it is still on webpack 1) and rewriting the example once the build system is changed (and possibly having JS and TS versions of it).

I was planning on using tsdx to make swapping the build system easier, but jaredpalmer/tsdx#165 is a big blocker for this library that uses default exports. Fortunately, I wrote a PR to solve that recently at jaredpalmer/tsdx#327, but I have no idea when that will be merged or what the hold on it is. I recently created a fork with my changes included and so am planning on using that similar to what I did in agilgur5/mst-persist#24.

For the example, I'm planning on just rewriting it with CRA, similar to the cra-example branch. Just need to figure out what to do about JS vs TS examples.

@alkafaiz

This comment has been minimized.

@agilgur5
Copy link
Owner

agilgur5 commented Dec 23, 2019

Please read the discussion, review, comments, related issues, etc before making comments. Locking this due to multiple comments that have not.

@agilgur5
Copy link
Owner

Closing this as @types/react-signature-canvas has been released thanks to @ksocha in #21 (comment) .

Per the above comments, this is the solution recommended by the TS team for third-party typings that are not generated from TS source code.

A TS rewrite is still in-progress and that will eventually replace the unofficial third-party typings with official, internal typings, planned for the 1.1.x release

@agilgur5 agilgur5 closed this Jan 18, 2020
@agilgur5 agilgur5 added the scope: types Related to type definitions label Jan 18, 2020
Repository owner unlocked this conversation Feb 7, 2020
@agilgur5 agilgur5 mentioned this pull request Feb 7, 2020
@agilgur5 agilgur5 added the problem: stale Issue author has not responded label Mar 13, 2021
Repository owner locked as resolved and limited conversation to collaborators Mar 13, 2021
@agilgur5
Copy link
Owner

Noting here that the internal re-write, #42, has now been merged. Planning to release as 1.1.0-alpha.1 soon

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
problem: stale Issue author has not responded scope: types Related to type definitions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add TypeScript declaration file
5 participants