Using the context API doesn't necessarily go against separating data. Redux & the Context make it both possible to solve that issue by making it possible to create both providers and consumers of data. So afaik whatever you do with Redux to separate "data flow", you can do it without Redux as well.
I found that the example in this article already shows a clear case where you can implement things without sacrificing a separation between the components and the data flow.
The reason I asked for examples is that I haven't yet seen a single concrete example that showed me something that only Redux can solve better 🤷♂️.
So if you do, please share it. Otherwise, I'm curious about what were you looking for in the new React features and that you didn't find? Examples of testing features?
Implementing isolated reusable components (e.g. a design system that you can showcase with storybook) can also be solved without using an external
state management library such as Redux.
It's important to test features, and not test for testing. Testing API calls or tiny pure functions that update the state will give you more green checks on the terminal for sure. However, it's a false sense of achievement. I believe that good tests focus on testing features and not implementation details such as API calls, sagas or event a React context. Testing features shouldn't rely on such implementation details.
At the end of the day, the user of our app doesn't care about how much "testing coverage" we have or whether we used Redux or React Context. The user only cares about how many bugs occur while using our application.
I'm at risk here as a new new dev (I didn't stutter), however I do think that your comment about testing appears to take a position that I'm not sure I understand from what I've learned and been told, nor did I get from the person you have responded too as well.
I believe that those tiny checks aren't necessarily about displacing the user from the center as it seems you have assumed. As I've learned it's about making it easier for a developer to reason around the tests. I'm assuming unit tests and not integration tests. That's a reasonable assumption I think, right?
I find it easier to read small tests and grasp what's being tested. This in turn means when I add code it's easier to either add tests, see a need for a tweak to a test or what have you. It's true that this may lead to an error ultimately, but I don't think one set of testing displaces the other. Do you think that?
Personally I enjoy testing and find unit tests to greatly assist me in solving the problem better when I write my code (I do TDD mainly), however I also do functional testing both with and without the UI rendered. Is this not the best practice? I thought it was and if I'm right I don't think it's reasonable your last point as it takes a point of view that one form or type of testing has hegemony over another.
I do love your other points btw. I'm trying to determine if I need to use Redux anymore or can I move to the new Context API as my first choice.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.