It will be nice to have typings. It will be little easier to understand how to use your package. :)
Also typings are required for typescript setting no implicit any.
As vx isn't a typescript project, we'd welcome a third-party typescript typings project! I could also see a @vx/types package being helpful. If someone would like to start this, I'd be happy to support.
@hshoff Can you assign me to this because I kind of need this :p
I'd like to help out with this and contribute flow typings.
@andyfangdz @victorias wonderful! let me know if there's anything I can do to help
Any updates on the status of typings for vx? @andyfangdz @victorias @hshoff
I also can help. Any news? Branch? Fork?
Any news on this? I am potentially willing to help too.
@hshoff As far as I know, it may be easier to either contribute to DefinitelyTyped/DefinitelyTyped and create the types for @vx/* there, or to have *.d.ts type description files lying next to the .js files.
And I would favor the second solution, as it is easier to remember to modify both files if they live together.
What is your opinion on this matter?
*.d.ts :+1:
I checked out VX a week ago and I'm already hyped.
I see we are all implementing our own typings. I guess I'd make sense to bring them all together.
Without maintaining those typings, they are already out of date once we are finished.
I got an idea.
I see that this library has very good documentation. What about writing typings and then generating the documentation of them? @hshoff
http://typedoc.org/api/
Would it be completely off-menu to port the actual library to typescript? A large amount of it would implicitly come from d3's typings anyway. It'd save having to separately update typings.
Any decision on this?
This is a dealbreaker for us, would have loved to use VX but just can't really justify it without.
I'm one of contributors to vx and have recently begun porting one of my projects that uses vx over to typescript and have been adding typings for the packages I use in said project. I currently do not have time to add typings for everything, but if someone is willing to start a PR with the typescript plumbing, I could add my typings to help the effort along.
I currently have:
axis.d.tsgrid.d.tsresponsive.d.tstext.d.tstooltip.d.tsThese might not be perfect (I'm still understanding typescript and the differences from other strict languages like C#) but should be a good start. There are definitely some room for improvement with regards to using generics more/etc (which I still think is a little weird with JSX). I've also had to leverage a Material-UI type helper on occasion (getting a HOC like withTooltip to be properly typed and not break defaultProps / JSX. LibraryManagedAttributes is a PITA until I saw how they did it with their PropInjector which I leveraged. Some of these helpers could be added to vx as well (Omit is another common one).
A few early decisions we would need to make:
*.d.ts files?@types/vx npm package and keep the typings completely out of the @vx repo (although these would likely get out of date regularly I'd imagine)tsc for the builds, or babel and @babel/plugin-transform-typescript?That's awesome! I was thinking about writing some type declarations for vx, but I'm pretty new to Typescript and didn't really know where to start.
Hi all, thanks again for checking out vx.
Typescript isn鈥檛 currently a priority for vx at the moment. The priority right now is to finish up interactions, improve docs, and ship v1. Happy to revisit this in the future.
Until then, if there鈥檚 a community owned types for vx project out there, i鈥檇 be happy to link to it to help others looking for TS type defs.
Since vx is a Javascript project, I think it makes sense to have no Typescript files in this repo.
As @madprog said, Typescript type definitions for all vx packages could be hosted on DefinitelyTyped. Type definitions are specific for a given version range, but there are already best practices to support different versions. See for example the type definitions for d3-scale.
@hshoff, any tips on which vx packages to start with? I guess it should be easier to start with "leaf" packages. I have just started writing type definitions for @vx/mock-data, @vx/scale and @vx/axis. I'll make a PR on DefinitelyTyped when I'm ready.
Meanwhile, for anyone who wants to use vx in a Typescript project, the quick and dirty approach is to set this flag in the compilerOptions of your tsconfig.json:
{
"compilerOptions": {
"noImplicitAny": false
}
}
Here are my current @vx typings if someone (@jackdbd 馃槈) wants to take them and run with them.
https://gist.github.com/techniq/e52d3f797c827b765ac67ff0cbe98ced
Note that:
Omit,PropInjector`) that we'll probably want to copy into our typings.= {} defaults) to help in places, but was struggling to get them to be inferred from other props (for example withTooltip)Cool :smile:
Material UI seems to have a lot of good type helpers. I still don't fully understand a few of them though :sob:
Maybe in @vx/axis we could declare a generic ScaleFunction like this:
type ScaleFunction = ScaleTime | ScaleLinear | ScaleOrdinal | etc...
Same here regarding the type helpers. PropInjector fixed my HoC typings (not breaking static defaultProps, and simplifying my typings of withTooltip greatly). I only partial understand how it works.
As I thought more on this, the union of all Scale functions might work. Not sure if it would be affected by the generic signatures (some have a single generic property, others have 2 based on their domain/range)
I've recently added TS to a couple of projects and would be happy to review any vx typings on DefinitelyTyped 馃憤
I generally agree with @hshoff 's enumeration of priorities for vx. I think in early 2019 there'll be some more robust ways to support TS + PropTypes simultaneously (e.g., with things like babel-plugin-typescript-to-proptypes), but having types in a separate repo from vx seems like a good solution to start with!
I'm writing the type definitions for vx-scale, then I'll move to vx-grid and vx-axis (they both depend on vx-scale).
I was wondering: what is the main reason to use vx-scale in place of d3-scale?
This is a good question which has been discussed most in #170 I believe. Right now there is not a huge difference/advantage except that the scale takes a single object for configuration scaleXYZ({ range, domain, clamp: true, ... }), rather than requiring the d3 chaining syntax scaleXYZ.range(range).domain(domain).clamp(true), which is more verbose and less "javascript"-y making it less intuitive for people not familiar with visualization engineering (a general theme of vx is a more clear API than d3).
By having a separate package we can add additional functionality, such as scale immutability as discussed in #170, in the future.
I created this repo where I basically copy-pasted some examples from vx-gallery and started using type definitions.
There is still a lot of work to be done, but it's a start.
Hope this helps someone :smile:
@jackdbd Thank you a lot for that. Could we get this up on DefinitelyTyped? I would contribute when I could.
I tried to put a couple of packages on DefinitelyTyped (vx-point and vx-scale I think...) but there was something wrong and their tests didn't pass. Hopefully in the upcoming days I can have a look at these issues.
I tried to make a PR for @vx/point and @vx/scale on DefinitelyTyped but their tests still do not pass.
The problem is that their test script tries to include type definitions which are no longer in the DefinitelyTyped repo. For example, fastify-jwt had its type definitions on DefinitelyTyped, but started bundling them since version 0.8.1 (see index.d.ts). When a package starts bundling its own type definitions, someone has to run a script on DefinitelyTyped that adds such package to this file: notNeededPackages.json. Even if these packages no longer have their type definitions on DefinitelyTyped, the types-publisher tester still tries to include the old .d.ts files.
I guess I should cleanup my fork of DefinitelyTyped, but I'm not sure how to do it.
I find it very confusing, because the test script also fails on my local master, which is up-to-date with the upstream repo.
@jackdbd Anything that can be done to help? I do not have a lot of time, but I am willing to do what I can if time permits.
No ETA, but just wanted to note progress on this front which you can follow here.
Hi! First off, thanks for the great project.
I'm having issues importing the types from packages. For example no declaration files are found when I do something like import { BarGroup } from '@vx/shape';. Do you know what I may be doing wrong?
@sschwartz0 typescript typings have not been published yet. They will be published in v0.0.193. We're tracking progress here: https://github.com/hshoff/vx/projects/2
@hshoff Got it! Thanks
Just curious if there is an ETA on v0.0.193.
@derek126 I made more progress over the holiday and we are very close. The only remaining package technically is @vx/legend (generic scales have been the trickiest thing to type so far), but I'd like to convert the demo package to battle test it more.
As mentioned in #568 we've published @vx/*@0.0.193-alpha.0. After #551 lands I'll release 0.0.193-alpha.1 for more testing.
@williaster that is great news. Looking forward to using vx more in upcoming projects. I have been using it for awhile and really appreciate this push to Typescript.
FYI #579 is in and TONS of fixes published under 0.0.193-alpha.2, hopefully can land non-alpha 0.0.193 soon and call TS v0 done 馃槃
closing this as it's done 馃帀 starting in 0.0.193
Most helpful comment
Would it be completely off-menu to port the actual library to typescript? A large amount of it would implicitly come from d3's typings anyway. It'd save having to separately update typings.