Great article, I agree with most of these points. Not too sure about using reducers for just arrays, since they also add a bit of complexity and boilerplate themself. I would say it helps if you can identify unique actions in your component tree that affect multiple parts of state.
One thing I noticed is that people try to come up with their own solutions while React has a somewhat opinionated solution for that problem. This mostly boils down to them trying to optimize prematurely or storing calculated values in state (leading to the problems you describe) - they think a rerender would be too expensive based on their gut feeling instead of actually measuring it.
I'm not a great fan of unit testing React related code (the internal state of your app), but for specific business logic it could make sense. I think Kent C. Dodds is on to something with his testing trophy - mostly write integration tests so you can verify the most important use cases of your app and try to avoid testing the internals.
Also, using testing library (with Cypress) was an eye-opener for me. Multiple times I tried writing a test using querying methods that test the interface based on what the user sees (aria role, form label, aria label, text, etc), but noticed I couldn't because there were no proper labels on my elements. By writing the test, the accessibility of my app improved as well! Win win!
Thanks Edwin. When I say "using reducers for arrays", I primarily am referring to the "I have an array of objects and the user can edit each object" use case. For a simple array of IDs, reducer is not really necessary.
I also love the testing trophy so I agree with you there!
@testing-library/cypress is an interesting topic... I have used React Testing Library and Cypress, just not together 😉
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.
Great article, I agree with most of these points. Not too sure about using reducers for just arrays, since they also add a bit of complexity and boilerplate themself. I would say it helps if you can identify unique actions in your component tree that affect multiple parts of state.
One thing I noticed is that people try to come up with their own solutions while React has a somewhat opinionated solution for that problem. This mostly boils down to them trying to optimize prematurely or storing calculated values in state (leading to the problems you describe) - they think a rerender would be too expensive based on their gut feeling instead of actually measuring it.
I'm not a great fan of unit testing React related code (the internal state of your app), but for specific business logic it could make sense. I think Kent C. Dodds is on to something with his testing trophy - mostly write integration tests so you can verify the most important use cases of your app and try to avoid testing the internals.
Also, using testing library (with Cypress) was an eye-opener for me. Multiple times I tried writing a test using querying methods that test the interface based on what the user sees (aria role, form label, aria label, text, etc), but noticed I couldn't because there were no proper labels on my elements. By writing the test, the accessibility of my app improved as well! Win win!
Thanks Edwin. When I say "using reducers for arrays", I primarily am referring to the "I have an array of objects and the user can edit each object" use case. For a simple array of IDs, reducer is not really necessary.
I also love the testing trophy so I agree with you there!
@testing-library/cypressis an interesting topic... I have used React Testing Library and Cypress, just not together 😉