10 tips for React Redux At Scale | Matters Meetup | Baptiste Manson

[@jasdn93bsad992]

Tip 1 : Planed 1 full day of training for each member 1:54 Tip 2 : Tooled our environment 3:26 Tip 3 : Used action creators 4:22 Tip 4 : Redux Ducks 6:26 Tip 5 : Write Unit tests 8:15 Tip 6 : Use payload-based actions 10:33 Tip 7 : Frontend development is all about side-effects 12:02 Tip 8 : Normalized the state like a db 14:08 Tip 9 : Selectors are helpful 16:26 Tip 10 : Flow and typescript helped 17:38

[@bernardleech5007]

Awesome talk! Also, props to the video editor for cutting out pauses. Maintaining flow helps me maintain concentration.

[@comp20B]

I love the editing!

[@djheru]

Great talk. Encouraging to see my thoughts on redux-sagas vs. redux-thunk validated by a heavy hitter.

[@Oswee]

Super great talk! Recognized the problem i have with module responsibility. What i decided recently is to try think in Features and not in domains or entities. For now it seems valid idea to me. Will see how it goes.

[@kamranayub]

Great talk. Using redux-thunk now but definitely can see moving to sagas soon! Thankfully doing that with much more maintainable structure shouldn't be a scary proposition!

[@jgraves4532]

over my head, but I kept up. love that thank you.

[@CoreyWofford]

Great talk - interesting note on payload-based actions. Agree with it in principle, but in practice seems like it would make your reducers much less expressive. I.e. for someone not familiar with the codebase, a switch-type (on action type) reducer single-handedly explains its slice of state (what we do and don't do with it), but if everything's just a payload object merge, now you have to look elsewhere.

[@kaizun]

true, but he addresses this issue by suggesting the use of typescript or flow to explicitly show the payload structure.

[@Danielo515]

Sorry, I don't understand your point. Could you please expand?

[@Danielo515]

Grouping thins by feature instead of by color (yes, having things organized by reducers, containers etc is the same as using jut colors) is the best advise by far

[@tommychan72738]

very useful information, these practices are also good for useReducer react hooks, I think

[@sagaruv]

You have not included the time to identify and fix bugs in your TDD comparison chart. That will dramatically change your view towards TDD. One more thing, that maintenance is the core of TDD. That's where you actullay catch bugs and fix them. Nice talk BTW.

[@thomasviaud]

Interesting video, thanks!

[@mohamedyoussef8835]

Awesome +++++++++++++++++++++

[@santosharakere]

Excellent thanks

[@justfly1984]

Keeping action-types in single separate file, has great advantage: eslint highlights if somebody repeat same action.type twice in different reducers

[@osquigene]

I really don't understand what Redux is actually doing. What I mean by that is, what is the difference between Redux and a shared (immutable) state that you would normally use? I just feel like Redux is a design pattern, I'd like to see a use case in which Redux is compared to something in plain ecmascript. Is the Redux version shorter, simpler to code or does it just forces you to code properly (enforcing the design pattern). Or maybe it's a standard that will help sharing pieces of code or creating debugging tools.

[@osquigene]

For example, immutable-js is just enforcing immutability, it doesn't offer any performance improvement, nor it reduce the amount of code you'll have to write. I'm not saying that this makes immutable-js useless, I'm just saying we need to take it for what it is, a tool that help you not having to remember not to mutate objects. I was wondering if Redux was similar to immutable-js in that sense. Cheers

[@batmansmk]

Redux is a few design patterns bundled together, yes. Total lib is less than 1k lines. It helped settling a common vocabulary and sharing tools and best practices.

[@kesais]

Nice !

[@batmansmk]

For those who cannot play the video at work, there is also a medium article: blog.matters.tech/10-redux-tips-from-the-trenches-55e06ed1c0a8

[@vincentdesmares]

Here is the related medium article: blog.matters.tech/10-redux-tips-from-the-trenches-55e06ed1c0a8

[@ionutcirja7121]

Unfortunately, I don't believe in your statement about unit testing. Otherwise, great talk!

[@batmansmk]

Hey thanks for the feedback! It is definitely controversial. You disagree that tests are worth it with React, or disagree that ROI on the frontend of 100% coverage is debatable. Dan tweeted about the feeling way better than my long explanation : twitter.com/dan_abramov/status/807621725772881920

[@ionutcirja7121]

Hi, definitely about the ROI I'm talking about. Dan is talking mainly about testing public api vs library internals and I completely agree the public api is the one which should be tested in the case of a library. But in the case of a project, I would test 100% of the code, because as a dev I have to make sure that my code is 100% correct before running the end to end tests. End to end tests execution usually takes time and I need feedback instantly. As a dev I want to insure my ass, so to say. :D

[@GrantMcLean]

Really great talk, thanks for the insights. In responding to the question at the end about testing (about 26:45), you mentioned a tool that you use for testing, but I didn't catch the name of it.

[@batmansmk]

Puppeteer!

[@GrantMcLean]

Thanks!

[@developerfriendly]

use redux-toolkit