Migrating to React’s New Context API(blog.kentcdodds.com)
blog.kentcdodds.com
Migrating to React’s New Context API
https://blog.kentcdodds.com/migrating-to-reacts-new-context-api-b15dc7a31ea0
39 comments
This is actually addressing something that you cant really easily do in other frameworks (or even previously in React). The idea is to return control of rendering to the caller rather than have the component be responsible for fully rendering the entire thing. I.e. a toggle component only knows how to toggle and you can choose what goes in it. Ryan Florence has a much better illustration of why you'd want to do this: https://www.youtube.com/watch?v=hEGg-3pIHlE
Just a side note while watching that video. Seems to me that video could be 10 minutes if he would use Sublime, VS or Atom.
Does he uses VIM just to show-off? Seems like everything is super slow because of it.
Does he uses VIM just to show-off? Seems like everything is super slow because of it.
I would not attribute malice to such an insignificant detail. My guess would be that he prefers VIM over the others. I prefer VS Code myself, but an editor is a very personal choice for a developer.
He's not showing off. He used vs code for a while but I believe got frustrated with issues, so he went back to something more stable and familiar for him. I can't blame him there.
He heard you. Check this video: https://courses.totalreact.com/courses/250055/lectures/38973.... The content is same, a bit refined, but the length is 34:51.
Seems to me that vim is superior to the alternatives you listed, but that's just my opinion.
Seemed to me he was struggling with VIM usage. I never said VIM is worse/better.
Just a friendly editor war jab :)
This is actually a really weird example of using the Context API. I have no idea why you would want to use it to manage a single switch of state.
The far better examples are providing a "theme" across multiple disparate components, and each of them being able to access the colours, or styles. (You could also just use CSS)
The other good example is being able to set the logged in user into a context and then being able to consume the context if you need access to the logged in user.
The far better examples are providing a "theme" across multiple disparate components, and each of them being able to access the colours, or styles. (You could also just use CSS)
The other good example is being able to set the logged in user into a context and then being able to consume the context if you need access to the logged in user.
I think it makes more sense if you start thinking outside the Toggle component itself.
For passing down the state to the actual button(s), as Kent says, you could just use React.Children.map(). When you think about consuming that state from other components that need to know the toggle state, things get a bit messier, as many of those components might not be direct children of the actual <Toggle />. Maybe the toggling affects something in your navbar, for example.
In that case, the alternative to using context would be a global store, where the state provider sits above all components (think Redux, MobX).
If you're only consuming the toggle state from child / grandchild / sibling etc. components, the alternative typically involves passing down the toggle state from some parent / grandparent component, which means passing this.state.toggled down 2+ levels, instead of simply importing the context's consumer and subscribing where needed.
Context is now a reasonably simple and clean alternative to those options, but this example leaves envisioning the pain alleviated as an exercise for the reader.
For passing down the state to the actual button(s), as Kent says, you could just use React.Children.map(). When you think about consuming that state from other components that need to know the toggle state, things get a bit messier, as many of those components might not be direct children of the actual <Toggle />. Maybe the toggling affects something in your navbar, for example.
In that case, the alternative to using context would be a global store, where the state provider sits above all components (think Redux, MobX).
If you're only consuming the toggle state from child / grandchild / sibling etc. components, the alternative typically involves passing down the toggle state from some parent / grandparent component, which means passing this.state.toggled down 2+ levels, instead of simply importing the context's consumer and subscribing where needed.
Context is now a reasonably simple and clean alternative to those options, but this example leaves envisioning the pain alleviated as an exercise for the reader.
Fair enough, I suppose. I still think the additional complexity of having to bring in the context for the save of passing 1 variable through the whole tree is overkill though.
I'm developping a web app with fairly complex forms (imagine form sections, form templating...). The immediate use case of Context that comes to mind would be to pass down the `readonly` prop from the top-level Form component all the way down to the Field component, without having to drill through `FormSection`, `Template`, `TemplateSection` or any other component between the Form and the Field.
In the case of a form, what’s wrong with composing a whole tree of custom “presentation” components in one render? Does this take up too much space?
You don’t always need to pass the prop through each individual component, instead you can render a section (or the whole form) together as one larger context-specific UI component, where everything in the render call has access to the same prop values.
You don’t always need to pass the prop through each individual component, instead you can render a section (or the whole form) together as one larger context-specific UI component, where everything in the render call has access to the same prop values.
That's entirely true. It becomes much more applicable where there's more complex state that's used throughout an application.
I worked on a React project for a good six months and even though I hadn't touched it in a while I still felt like I had a good grasp on things. Looking over the code samples in that article, and some of the other things that the article links to, I really struggled to make sense of it all.
I agree. It's like React is slowly morphing into Java and all the classfactory.singleton().instance.objectstore stuff
and even in java this "classfactory.singleton().instance.objectstore" doesnt really happen if you kind of know what you're doing
Frameworks and their abstractions tend to evolve out of what we find people need to use in the real world when building their applications.
Context is generally a pretty powerful thing when used properly, and allows developers to build nice, readable code in more complex applications by extracting some of the complexity elsewhere, while maintaining a conceptually clean model. It's already used in common libraries like React Router, and establishing a first-class API for it seems like a good move in general.
And remember – if it's not useful for your particular use case, don't use it!
Context is generally a pretty powerful thing when used properly, and allows developers to build nice, readable code in more complex applications by extracting some of the complexity elsewhere, while maintaining a conceptually clean model. It's already used in common libraries like React Router, and establishing a first-class API for it seems like a good move in general.
And remember – if it's not useful for your particular use case, don't use it!
Frameworks evolve out of a single group of people's needs. Unfortunately once the entire world gets involved they often end up including every possible need anyone could have.
> they often end up including every possible need anyone could have.
I don't think that's what is happening here with React. It'd be much different than it is already if that were the case, but instead it's stayed pretty lean
I don't think that's what is happening here with React. It'd be much different than it is already if that were the case, but instead it's stayed pretty lean
Really? The old Context api was fairly terse and hard to use. Definitely not what I would call "clean and readable".
In a year every React app will be wrapped in a context called "theGlobalVariables" because while the languages and frameworks change, the programmers don't.
Real functional languages have "lexical scope" and "dynamic scope", both are necessary for proper functional programming. React.js "functions" don't evaluate depth-first like a traditional call stack, but rather "breadth first" (because it offers optimization opportunities) and this breaks dynamic scope, so these Context hacks are an attempt to get it back. You are right though, I think React.js is not the end state and the harder we push it the more the "almost-functional-programming" abstraction is going to leak.
This is totally incorrect. Context has nothing to do with JavaScript scoping behavior. Directly from the React documentation:
"Context provides a way to pass data through the component tree without having to pass props down manually at every level."
"Context provides a way to pass data through the component tree without having to pass props down manually at every level."
That is what dynamic scope is, and javascript doesn't have it, but ClojureScript does, and React still breaks it.
I'm sorry but you're not making any sense. What does the react context api have to do with dynamic scoping?
Today I learned: Haskell is not a "proper" functional programming language
It surprised me to find out that you're right, for anyone following along, I ended up here: https://news.ycombinator.com/item?id=3453141
If you want clean declarative APIs you need context to build them.
I admire the spirit of the post but it seems contrived and hard to grok.
As soon as you go down the state and lifecycle method route my spidy senses start tingling.
I have yet to see an example on the new context api that wouldn't be clearer with stateless components + recompose. Perhaps someone could point me to the advantages?
As soon as you go down the state and lifecycle method route my spidy senses start tingling.
I have yet to see an example on the new context api that wouldn't be clearer with stateless components + recompose. Perhaps someone could point me to the advantages?
I wrote a small library [1] for localization messages using the new Context API; I'm pretty sure that any other base for it would have made its implementation significantly more complicated.
[1] https://www.npmjs.com/package/react-message-context
[1] https://www.npmjs.com/package/react-message-context
The new context api isn't meant to replace stateless components and recompose [0], it's meant to be a more sound context API that lives almost exclusively in library code, replacing usage of the old context + (maybe) 5% more use cases.
[0] https://twitter.com/dan_abramov/status/984510107923963904
[0] https://twitter.com/dan_abramov/status/984510107923963904
Can you briefly describe what you mean by recompose? I'm a backend dev tasked with writing some react, and what I'm using currently is redux+react, but that's about it. More information would be appreciated so I can research :)
It's a library :) https://github.com/acdlite/recompose
Enzyme still needs to support it.
https://github.com/airbnb/enzyme/issues/1553
https://github.com/airbnb/enzyme/issues/1553
It's great these abstractions exist but for me I want a framework where I don't need to think about them. Vue comes closest to the original feeling I got when starting out with React.