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

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.

[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).

[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.