DEV Community

Discussion on: You don't have to use Redux

Collapse
 
seif_ghezala profile image
Seif Ghezala ๐Ÿ‡ฉ๐Ÿ‡ฟ

I'm very curious about how Redux provides a better testing environment. I feel like React evolved enough so that you can achieve anything you do with Redux, without it. Could you provide more details or examples?

Collapse
 
javaguirre profile image
Javier Aguirre

Hello Seif! :-)

I don't think I said Redux provides a better testing environment. I cannot compare because I don't have the same experience using the Redux/Redux-Saga stack than using React Context API.

What I like about Redux and Saga is:

  • Data flow completely isolated from React components, so those are mainly presentational, and someone could only be working on those without needing to know anything from the data flow in the app. Using storybook for example.
  • Sagas takes care of all the impure actions, such as API calls, caching, etc. We can easily test it and it's completely isolated from anything else. You could develop that functionality using TDD, and It wouldn't affect anybody on the team.
  • We can use middlewares to validate data before going to the sagas, or for some logic not belonging on sagas or the React components. Easy to test too.

Maybe I misspoke when I said the best possible testing environment. I didn't mean mine, what I meant is testing is usually overlooked, and having a not optimal testing environment would lead to technical debt pretty quickly.

I'd like to know more about React Context API, useEffect and the rest of the new React magic โœจ, but what I've read didn't give me what I was looking for, do you have any examples regarding testing with React Context API so I could have a look?

Thanks! ๐Ÿ’ฏ

Thread Thread
 
seif_ghezala profile image
Seif Ghezala ๐Ÿ‡ฉ๐Ÿ‡ฟ
  • 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.

Thread Thread
 
misterhtmlcss profile image
Roger K.

Hi Seif,
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.