React compose 2.0 Roadmap
Higher order components is all the rage in React land. Composing React components from smaller functional pieces is very popular with a number of implementations, like transform-props-with and recompose. I have a flavor of my own, in react-compose.
If reusability is what you are after, these compositional patterns can be a great tool. The reason for this is that you can strip out the functionality behind a particular prop and share it between a range of components. Now they all share this prop and the api is consistent. The thing I want to improve upon in the next iteration of react-compose is adding support for extending the meta of a Component, and not just the functionality.
The fader function in the example above is just meant as a discussion reference, the actual implementation is not relevant. Semantically it exposes a prop called fade that fades the color and the background of a component. Now, where should we define the propTypes for the final component? I don’t think it is a good idea to do that explicitly on the composed component.
Why is that bad? You would have to do that on all the other components that is composed of that function. So here is my #1 proposed feature in react-compose 2.0. The composable function is allowed to extend the propTypes of the final components.
The #2 proposed feature is closely related. Should the same work for defaultProps? Well, I would say so.
The #3 proposed feature is, you might have guessed it, displayName. Could we do something cool with that? DisplayName is of great importance when it comes to debugging, for one thing. A good pattern in higher order components is to “wrap” the displayName of the component that you are extending.
compose(fader)(MyButton) => displayName = 'composed(MyButton)'
That may or may not be fine. But maybe we can do something better. Would it not be cool if each composeable function added a prefix to the displayName?
compose(fader)(MyButton) => displayName = 'fadedMyButton'
If there is a ton of composeable functions on one components, maybe the resulting displayName will be too long? In that case you could simply override the displayName with a custom one.
Another aspect of the composeable functions, I have been playing around with, is context. The way stateless components works is that the function gets the context passed as a second argument, besides props. If the function has a contextTypes on it. Now the composeable functions could simple have a way of combining contextTypes just like propTypes, and they could use the same signature as the stateless component have with props and context. Now is this actually useful? With the controversial side to context and the way it interfere with rendering updates etc, I don’t know. Maybe, there might not be too much of a downside including the feature anyway.
What am I missing? What features would you like to see in the next iteration of react-compose?