Context Transform

[sebmarkbage]

With the new context API it is really bulky to create a middle man that consumes one context value, transforms it and provides another one. You have to create many components and store an intermediate state to avoid rerendering the provider if the input is unchanged.

We could have a convenience API for this use case.

function transform(inputValue) {
  return [...inputValue, extraData];
}

<Context.Middleware transform={transform}>{children}</Context.Middleware>

cc @acdlite

[acdlite]

I like this but for the love of god let's not call it middleware, please :)

[gaearon]

Context.Map?

[acdlite]

Yeah I like Context.Map or Context.Transform

[sebmarkbage]

I like Context.Transform. Map is so overloaded. Is it a <map> tag, is it a Google Maps map, is it a hash new Map() object...?

[acdlite]

Alternatively, we could add a transform prop to Context.Consumer

[milesj]

Third-party vote for Context.Transform. Just by the name, it's pretty apparent what it does, and has some connotation to Node stream transforms.

[drcmda]

@sebmarkbage i think this is doable in user-land: https://codesandbox.io/s/mjv84k1kn9

Looking at the context api it seems very low level, curious if you really expect plain use that would warrant more add-ons. As it is, everything can be a bit verbose, transforms, creation, reading and sharing. But if it's kept relatively simple and focussed, doing one thing well, then that would be fine as user-land will build patterns around it.

[sebmarkbage]

This is sufficiently covered by #13139