Hi @lukeshiru , I appreciate your comment and the effort you put into your rework, this is really cool 🙂
Unfortunately, you "cheated" a little bit. One of the initial constrain in the example is that we're using the "CountriesSelect" component as-is, with all of its performance flaws. And you refactored that part 🙂. If you replace the countries select in your example with the original one, it will be as slow as the initial form example without context, which is exactly as you implemented - a bunch of stateless components with the state managed at the top.
This situation is specially designed to imitate the real life scenarios, when a developer needs to use an external library or just another team's component, which turns out to be very slow, but on which they have no influence and can only use them as a black box.
As for reducer in the provider - this is needed to remove direct dependency on state for the API part of the provider. Otherwise it will still re-render on every state change. And the similar pattern is actually described in React docs: beta.reactjs.org/learn/scaling-up-...
And finally, the main purpose of the article is to demystify how Context works and give developers confidence when using it. This form surely can be implemented in a million way, including Redux-based solution linked in the article as well 🙂
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi @lukeshiru , I appreciate your comment and the effort you put into your rework, this is really cool 🙂
Unfortunately, you "cheated" a little bit. One of the initial constrain in the example is that we're using the "CountriesSelect" component as-is, with all of its performance flaws. And you refactored that part 🙂. If you replace the countries select in your example with the original one, it will be as slow as the initial form example without context, which is exactly as you implemented - a bunch of stateless components with the state managed at the top.
This situation is specially designed to imitate the real life scenarios, when a developer needs to use an external library or just another team's component, which turns out to be very slow, but on which they have no influence and can only use them as a black box.
As for reducer in the provider - this is needed to remove direct dependency on state for the API part of the provider. Otherwise it will still re-render on every state change. And the similar pattern is actually described in React docs: beta.reactjs.org/learn/scaling-up-...
And finally, the main purpose of the article is to demystify how Context works and give developers confidence when using it. This form surely can be implemented in a million way, including Redux-based solution linked in the article as well 🙂