New React Context API can work simultaneously with the old context. New components should be able to make use of the new way and it should be the way from here forward.
- use React.createContext() in stripes-core to create <StripesContext.Provider> and <StripesContext.Consumer>. Old context stripes can remain while it still works... but by the instant that it's gone (React 17) everything should have moved on a while back.
- create withStripes() HoC for simply wrapping components that require the stripes context. (also in core.) To help, it should make use of React.forwardRefs() docs on React.forwardRefs
- add `stripes` prop to components that need it... for conversion from the "old" context, this means that occurrences of
gets changed to
within the component. Logic that used the old way should survive this.
- enjoy testing components with only props and without any harness/scaffolding.
- if we find ourselves seeing bottlenecks in rendering, it becomes ideal for stripes' keys to break off from stripes and have their own exclusive Provider/consumer pairs - <IntlContext.Consumer>, for example, will get used in many places. It'll need its own ref-forwarding HoC.
- New things to add to stripes old context should get their own Provider/Consumer pair, and the new Context API put to use.
- If importing HoC's directly from stripes-core is a pain/unwanted, one idea is a peer repo (dep of core for those Providers it would have to render) that would effectively split the "core contextual data" from the "core ui". Providers, Consumers, HoC's would all come from here due to the way React.CreateContext() works. It could start at version 1.0.0 and potentially never reach version 2, so that a single version would always be present (semver fun/abuse?)
- sets of keys can be supplied in context, but the potential rendering bottleneck still stands. How often the updates occur and implementation will need to be considered. See React Context Caveats for the object-passing gotcha.