Visx: [scale] explore new context api for scale provider/consumers

[hshoff]

docs: https://reactjs.org/docs/context.html

In a typical React application, data is passed top-down (parent to child) via props, but this can be cumbersome for certain types of props (e.g. locale preference, UI theme) that are required by many components within an application. Context provides a way to share values like this between components without having to explicitly pass a prop through every level of the tree.

A common use case in data viz land is having multiple charts share the same time scale on a dashboard.

Currently you would have a parent component that controls the scale and passes it down through props. Thinking we could make <ScaleProvider/> and <ScaleConsumer/>.

Not sure how helpful it would be to have this live in vx might be fine letter this live in user land. Wouldn't be too hard to use this convention without vx... maybe a better convention in a charting library vs library of low-level reusable component.

Just a thought, might be worth exploring.

[techniq]

Similarly, using react context to pass the rendering context (for lack of better words). IE. using <svg /> vs <canvas /> (at some point). Could be passed to our @vx/shape components using d3-path or which primitives to use (svg using '', '', '', canvas using say react-konva, react-native, etc). A lot of this would be encapsulated in the @vx/primatives that @browniefed has been working on for react-native support.

General cross-platform support is tracked here and react-native here.

Not to hijack the issue, just thinking more generically about using react createContext and VX and how it all interplays.

[browniefed]

I don't think passing rendering context via react context is a good idea. Doing it via a build step (using primitive, etc) allows for code to be eliminated. In the case of passing via context you'd be shipping native or unnecessary code all over.

I may be misunderstanding what you're saying though.

[techniq]

@browniefed For react-native I could see the build target being able to dictate which components to use (not <svg /> but Art/etc) but not sure this would work for the web (some charts might use svg for convenience (click handlers, styling, etc), others use canvas for performance.

Maybe this is solvable via a build step?

[janbaykara]

I think it 100% makes sense to employ Context in code examples, to be encouraged, but beyond that I'm not sure it's necessary to build into a library that calls itself a "collection of reusable low-level visualization components." What would it do beyond wrapping Context?

Certainly, for passing canvas rendering context, it'd be great (and almost necessary).

[hshoff]

Having thought about this a bit more, I think this is a better fit for a guide or a tutorial than a reusable component.