Comments (37)
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.
from visx.
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 π
from visx.
@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
from visx.
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.ts
grid.d.ts
responsive.d.ts
text.d.ts
tooltip.d.ts
These 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:
- Do we consider writing vx in typescript, or just provide the typings as separate
*.d.ts
files?- This is ultimately a @hshoff question as this is his library and would need his buy in. I'm for this, but it would require all contributors to understand typescript, so it has it's pro/cons (writing in typescript means they are always in sync, and we could get some inferred typings/etc).
- Someone could also release a separate
@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)
- Do we use
tsc
for the builds, or babel and@babel/plugin-transform-typescript
?- I'm for using babel as it allows us to continue to use what we're familiar with (and leverage other babel plugins like macros, etc).
- babel doesn't support all typescript features, but 98% of them
from visx.
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
}
}
from visx.
I'd like to help out with this and contribute flow typings.
from visx.
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.
from visx.
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 π
from visx.
closing this as it's done π starting in 0.0.193
from visx.
*.d.ts
π
from visx.
This is a dealbreaker for us, would have loved to use VX but just can't really justify it without.
from visx.
Hi all, thanks again for checking out vx.
Typescript isnβt 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βs a community owned types for vx project out there, iβd be happy to link to it to help others looking for TS type defs.
from visx.
@hshoff Can you assign me to this because I kind of need this :p
from visx.
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.
from visx.
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.
from visx.
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/
from visx.
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:
- I make use of a few Material-UI type helpers (
Omit,
PropInjector`) that we'll probably want to copy into our typings. - These are all a WIP, so if you find problems/improvements, please consider I didn't know what I was doing π. I had plans to use generics more (with
= {}
defaults) to help in places, but was struggling to get them to be inferred from other props (for examplewithTooltip
) - I wasn't sure how to generically handle scales (and leverage's d3's typings) so would usually use the one I was needing at the time (ScaleTime, etc).
from visx.
@jackdbd Thank you a lot for that. Could we get this up on DefinitelyTyped? I would contribute when I could.
from visx.
No ETA, but just wanted to note progress on this front which you can follow here.
from visx.
@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.
from visx.
Also typings are required for typescript setting no implicit any
.
from visx.
@andyfangdz @victorias wonderful! let me know if there's anything I can do to help
from visx.
Any updates on the status of typings for vx? @andyfangdz @victorias @hshoff
from visx.
I also can help. Any news? Branch? Fork?
from visx.
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?
from visx.
Any decision on this?
from visx.
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.
from visx.
Cool π
Material UI seems to have a lot of good type helpers. I still don't fully understand a few of them though π
Maybe in @vx/axis
we could declare a generic ScaleFunction
like this:
type ScaleFunction = ScaleTime | ScaleLinear | ScaleOrdinal | etc...
from visx.
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)
from visx.
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!
from visx.
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
?
from visx.
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.
from visx.
@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.
from visx.
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?
from visx.
@hshoff Got it! Thanks
from visx.
Just curious if there is an ETA on v0.0.193.
from visx.
@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.
from visx.
Related Issues (20)
- XYChart has a zero width or height, bailing - console.log HOT 5
- Tooltip in XYChart - a way to make it compatible for mobile/touch devices
- scroll appears when drawing xychart using LineSeries but doesn't when using AreaStack
- Brush onBrushEnd does not seem to report the end x position HOT 1
- <Axis /> labelProps is documented as Partial, but overwrites values HOT 1
- Adding node version into .npmrc files HOT 1
- Adding inertia option to visx-drag [enhancement] HOT 3
- XYChart forces me to have the yScale include 0 HOT 2
- Zoom: Enable customisation of event handlers HOT 2
- Docs: README.md broken slack link HOT 1
- TooltipInPortal used inside a microfrontend obtains an unstyled (and unstylable) tooltip content HOT 4
- Brush jumps to wrong position when changing selection with a handle
- Nearest datum bug in XYChart HOT 3
- tickFormat function is not working with Typescript HOT 1
- Tooltip with an arrow HOT 7
- Help needed - XY scatter chart with line & area series HOT 5
- Package Responsive: `useParentSize` is not updating the width and height
- Poor performance - XYChart (w/captureEvents) + AnimatedBarSeries + NextJS
- onBrushEnd infinite render loop
- Not able to import bisector from @visx/vendor/d3-array
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from visx.