Hacker News Reader

Comment by ricardobeat | Hacker News Reader

> The only reason people use redux is that they want a sharable state across the app

No. You can do that with a global variable. Redux’s main features are serializable actions, serializable state, plus localized updates if you use immutable data. It gives you the ability to throw your state at localstorage, send actions over a websocket, easily traverse history (undo, time travel) and keep a log of changes. It’s ok to not need any of this, most projects don’t, but at least write off the library for the correct reasons.

> React is fast by default

Also not true. React does basically no optimization at all besides batching state updates. Your computer is just fast enough that you’ll think it doesn’t matter until it’s too late. Optimizing rendering is 100% on the application author.

View on HN

That doesn't entirely contradict the author's statement. Redux may do all of those things, but the proximate need of most people who use Redux is sharable state. Then they use something like Redux because it provides "structure" and has lots of stars on Github.

Incidentally, I have to agree with the author directionally on this point. Redux makes codebases such a pain in the ass to work with. Every new change you want to make to the store, you have to make about five changes across five different files. When you're working on a new feature you spend most of your time just wrestling with Redux, creating an action type, creating an action creator, creating a reducer, importing/exporting all this shit, blah blah blah. Then a new engineer who wants to figure out what the code is actually doing has to trace through the action, then the action creator, then the reducer, blah blah. This is before you throw in stuff like epics and run API calls through your action/reducer pipeline. It is no wonder productivity per capita in tech is so low.

Redux toolkit does exist.

I hated redux until I started using this.

> Every new change you want to make to the store, you have to make about five changes across five different files

This has never actually been a requirement to use Redux. Admittedly, having separate folders and files by type _was_ a pattern that was shown in the docs originally ( `reducers/todos.js`, `actions/todos.js`, `constants/todos.js`, etc), but even in the early days the "Ducks" pattern of "put all the logic for a feature in one file" was a thing that you could do.

Today, we specifically teach "slice/ducks files" as the standard approach [0] [1], and Redux Toolkit's `createSlice` API makes it trivial to do that - just write the reducers, export the matching auto-generated action creators, and you're done.

> throw in stuff like epics

We've actually been advising _against_ using both sagas and epics for side effects for years now, and especially against using them for basic data fetching.

Today, Redux Toolkit's "RTK Query" data fetching and caching API is a complete solution for caching server state on the client, and we also recently shipped a new "listener" middleware that is a simpler alternative to sagas and epics for other reactive side effects.

[0] https://redux.js.org/tutorials/essentials/part-2-app-structu...

[1] https://redux.js.org/style-guide/#structure-files-as-feature...

I'm not totally convinced this makes things better. To me, the problem with Redux is the whole act of having a ritual ceremony around every mutation you want to make to your state. To put things in perspective, I'm currently building an IDE from scratch "game development" style, in that I have a global "world" state that gets reflected in the rendered UI 144 times a second. So it's a similar paradigm to React -- except when I want to modify state, I just do it. Like I literally just mutate the variable by writing to it. Sometimes I do a particular mutation in many places and at that time I will pull it out into a function, but in general writing to state is not this enshrined procedure. I could not fathom developing this thing while having to create a new slice/duck for every state change I want to make.

I guess some people see the enshrined procedure as a feature and not a bug, and it is possible you could weigh the benefits of Redux's features against the cost in engineering time and decide it's worth it.. but it doesn't seem like this tradeoff is being consciously made and analyzed. It seems more like everyone just assumes they need something like Redux the moment they have global state.

The most interesting part: x people writing react for many years will have x completely different views on how things should be done.

Well, we knew there had to be a reason there was all this React code out there that doesn't abide by reasonable standards. I'd really be interested to hear why anyone prefers working with slow-to-recompile, globally-scoped CSS, or why people feel the urge to mix view and controller code. Can't you just have one component for view, and one component to handle state?

I think the author was trying to be brief.

There is too much know-it-all-ism in dev.

any tips or resources you seen good for optimizing react?

Generally:

- Use the React DevTools Profiler to identify components that are rendering more than expected, or taking too long to render

- Wrap key components in `React.memo()` to have React avoid recursing through those subtrees unless the component props have actually changed

- Avoid putting large state objects into a single context provider, as all components reading that context will re-render whenever it changes (and all of their children too)

- Use `useMemo` to cache any expensive transformations that happen during rendering

I've got an extensive post that covers how rendering works as a whole, and has a section on understanding React perf optimizations:

- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

Reply on news.ycombinator.com