Don't use 3rd party libraries: NIH syndrome is plaguing our industry like a disease already. Can't wait until companies realize they need half the devs they do now. Our industry needs a wake up call, especially for immature developers who waste company money
Forms don’t have to suck: Just use hook form, or use uncontrolled forms. Or better yet if you have a simple form don't use a frontend library at all.
Any component that expects a state has a hook: Please God no. Write code. When you write it 3 times abstract it.
CSS: Use styled components: No
Components: No, use flat file structure. Don't use the whole Folder/index mess. It's a nightmare. Just do Button.tsx, UserFeed.txt / etc. Put components next to feature unless they're generic. Just use tailwind.
Split the routes using loadable components or the equivalent in Next: Ok.
Folder Structures: No
Decoupling logic from components: 100% never do this. Ever.
Native like Page Transition: No. Don't use animations for page transitions on web or PWA's. Those are reserved for actual native apps.
Context’s: Don't use Context, unless it's literally for if the user is logged in. Everything else should use some kind of 3rd party library (Mobx, Redux, Recoil, Zustand) that uses subscriptions to circumvent React's extremely slow and outdated way of rendering. Alternative: Use react-query for most date fetching / global state.
At least the original article has some reasoning. You just say "no". This is not very useful. You also assert it's "completely wrong" without any evidence. Reading between the lines, it's more like "I disagree with almost 100% of this post, the author's opinions differ from mine".
> Decoupling logic from components: 100% never do this. Ever.
Care to elaborate? I much prefer to decouple my business logic from my components - mixing logic with the view layer doesn't seem like a great idea, at least ime.
I've also had a good experience with a single folder containing all the relevant code for a component (types, style, test, etc).
I'm still not really sold; obviously not good to be overly dogmatic, but MVC taught us the value in putting business (M) in a separate module to the view (V) and hooking them up via a controller (C). Why does all this knowledge suddenly get throw out the window?
> Don't use Context, unless it's literally for if the user is logged in. Everything else should use some kind of 3rd party library (Mobx, Redux, Recoil, Zustand) that uses subscriptions to circumvent React's extremely slow and outdated way of rendering. Alternative: Use react-query for most date fetching / global state.
Most rendering is outside the scope of state management and it doesn't matter whether you use providers or redux to manage it.
Personally I find the hooks for context a MILLION times easier to work with than redux was. Redux has introduced a lot of unnecessary complexity to several apps I've worked with. There was a time when it was the best choice but no longer, in my opinion.
> Decoupling logic from components: 100% never do this. Ever.
Disagree. "Dumb" components are often ideal and work great with testing libraries.
Just to check, have you had a chance to try out Redux Toolkit? We specifically designed it to eliminate the previous "boilerplate" concerns with legacy Redux patterns:
If other options do work better for you, great! I've just seen that many people's opinions of Redux are based on outdated info that doesn't match how "modern Redux" looks and is used today.
Acemarke, I know you're fighting the good fight with Redux Toolkit. I personally use it for truly global state with React Native. It's unfortunate the Redux name has a bad connotation for some as RTK is really good. And for some reason Context became something that developers thought was actually usable. Not sure what happened.
Eh, there was entirely valid reasons for the backlash :)
Redux _was_ overused in the first couple years. The original patterns _were_ very boilerplate-y. There _are_ a lot of other good tools for varying use cases that overlap with things that people have used Redux for: Context for prop drilling, React Query / Apollo for data fetching, Zustand/Jotai/Mobx/five-million-other-libs for state management.
Redux will never be the "must use this" lib again the way it was there for a couple years.
And that's a _good_ thing, because folks should take time to think about what problems they actually need to solve in their apps and pick the tools that work best for those problems.
But it's also true that Redux _is_ still a useful tool, and that RTK has addressed the pain points in using Redux. So, still very much a viable choice today, and the positive feedback we get on RTK daily shows that.
Really, the bigger issue today is that a lot of folks don't seem to understand the technical differences, tradeoffs, and intended use cases between a lot of these tools.
I wrote an extensive post describing the differences between Context and Redux to try to help with that:
I've also been trying to start up a community-driven site to list common tools for various use cases (state management, styling, build tools, data fetching, etc), to act as a resource to help clarify this sort of confusion:
Sadly I haven't had time to push it forward myself due to all the other responsibilities and tasks on my todo list, but hopefully at some point we can get enough info filled in for it to be a real resources that we can point people to.
No, RTK is a wrapper around just Redux patterns, not React.
- store setup: `configureStore` creates a store with a good default config in one function call
- Reducers: `createSlice` lets you define case reducers as functions in an object, write "mutating" syntax for immutable updates with Immer, and auto-generates the action creators for each reducer
- Data fetching: `createAsyncThunk` abstracts the standard "dispatch actions before and after an async request" pattern
- RTK Query: completely abstracts the _entire_ data fetching and caching process, adds cache entry lifecycles, auto-generates React hooks for use in components
The only React-related bits in RTK are the auto-generated React hooks for RTK Query endpoints. Everything else is "here's all the same kinds of logic you've always written for Redux, but with 1/4 the code and good default behaviors".
> Most rendering is outside the scope of state management and it doesn't matter whether you use providers or redux to manage it.
It does matter - a Context at the top of your app will trigger a full re-render on every change. Redux and other state management solutions specifically avoid using Context, and the new React 18 useSyncExternalStore hook was added for this very reason.
As I understand it, only components that read from context render when state changes. If you want/need more granular control, you have Memo at your fingertips.
Further, the entire point of global state is you only put the stuff in there that might actually require child components get re rendered. If you're shoving everything into global state or using context when you don't need it you're doing a lot of things wrong and it's likely you'd abuse redux as well.
People use context as a global data store which is fine if you limit global data to "things that a lot of components need to read, but very few get to write to" which is what it should be. Dark mode preferences are the canonical example.
Global state is the road to insanity in ant react app. Prefer props in all cases.
Holup. React is slow and outdated for rendering? I thought one of the big selling points was VDOM and it improves rendering speed. (Can you tell I don't use react?)
Improves compared to redrawing the whole component on every render(), as render() returns the whole component. But there's no improvement over redrawing only what's needed to be redrawn, plus VDOM overhead. I don't have enough to experience with Svelte, but I believe it's what it's doing.
> Native like Page Transition: No. Don't use animations for page transitions on web or PWA's. Those are reserved for actual native apps.
Lol, they are not reserved for actual native apps. Web can do animations just fine, at 60 fps, in 2D or 3D. If it adds to the user experience in a meaningful or delightful way, go ham.
Assuming you meant Redux Toolkit (RTK) Query there.
FWIW, the stance of both the Redux maintainers (myself and Lenz) and the React/TanStack Query maintainers (Tanner and Dominik) is:
- If you're using Redux at all, prefer using RTK Query
- If you're using just plain React, prefer using React Query
but don't write data fetching and caching logic by hand :)
There _are_ some API and philosophy differences between RQ and RTKQ. RTKQ emphasizes defining "endpoints" up front, and generates React hooks based on those endpoint definitions. That approach also helps enable codegen from OpenAPI and GraphQL schemas. RTKQ also has some unique capabilities around cache lifecycles that enable use cases like streaming updates:
(I'll also note that we have an `<ApiProvider>` that automatically sets up a Redux store for you internally, so you _can_ use RTKQ if you're not already using Redux in an app.)
Don't use 3rd party libraries: NIH syndrome is plaguing our industry like a disease already. Can't wait until companies realize they need half the devs they do now. Our industry needs a wake up call, especially for immature developers who waste company money
Forms don’t have to suck: Just use hook form, or use uncontrolled forms. Or better yet if you have a simple form don't use a frontend library at all.
Any component that expects a state has a hook: Please God no. Write code. When you write it 3 times abstract it.
CSS: Use styled components: No
Components: No, use flat file structure. Don't use the whole Folder/index mess. It's a nightmare. Just do Button.tsx, UserFeed.txt / etc. Put components next to feature unless they're generic. Just use tailwind.
Split the routes using loadable components or the equivalent in Next: Ok.
Folder Structures: No
Decoupling logic from components: 100% never do this. Ever.
Native like Page Transition: No. Don't use animations for page transitions on web or PWA's. Those are reserved for actual native apps.
Context’s: Don't use Context, unless it's literally for if the user is logged in. Everything else should use some kind of 3rd party library (Mobx, Redux, Recoil, Zustand) that uses subscriptions to circumvent React's extremely slow and outdated way of rendering. Alternative: Use react-query for most date fetching / global state.