5 ms·

Almost 100% of this post is completely wrong. Don't use 3rd party libraries: NIH syndrome is plaguing our industry like a disease already. Can't wait until c

by dham 4y ago

Almost 100% of this post is completely wrong. 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.

hunterb123 4y ago
I disagree with most of what you said (as well as most of the opinions in the article) I'm sure you have your reasons for your opinions, but you didn't define them, you just said "no this, trust me" essentially. You did expand on usage of the Context API but I agree with your opinion already on that one.
- llanowarelves 4y ago
  I agree with him but if he wanted to go more in-depth it might spawn a whole article (which I'd read)
djbusby 4y ago
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?)
- deepsun 4y ago
  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.
fubbyy 4y ago
react-query vs React Toolkit Query?
- acemarke 4y ago
  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: - https://redux-toolkit.js.org/rtk-query/comparison#unique-capabilities https://redux-toolkit.js.org/rtk-query/comparison#unique-cap... (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.)
nkozyra 4y ago
> 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.
- acemarke 4y ago
  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: - https://redux.js.org/introduction/why-rtk-is-redux-today https://redux.js.org/introduction/why-rtk-is-redux-today - https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu... - https://blog.isquaredsoftware.com/2022/06/presentations-modern-redux-rtk/ https://blog.isquaredsoftware.com/2022/06/presentations-mode... 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.
  - dham 4y ago
    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.
    - acemarke 4y ago
      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: - https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff... 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: - https://github.com/markerikson/react-community-tools-practices-cheatsheet/discussions/1 https://github.com/markerikson/react-community-tools-practic... 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.
siquick 4y ago
Can’t say I disagree with any of this.
lmiller1990 4y ago
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).
- basicallybones 4y ago
  I'm not the original commenter, but see the 2019 update on this Dan Abramov article: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
  - lmiller1990 4y ago
    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?
chrisco255 4y ago
> 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.
- dham 4y ago
  Note, I didn't say all animations, I said page transition. Don't animate a page transition.

by dham 4y ago

hunterb123 4y ago

I disagree with most of what you said (as well as most of the opinions in the article) I'm sure you have your reasons for your opinions, but you didn't define them, you just said "no this, trust me" essentially. You did expand on usage of the Context API but I agree with your opinion already on that one.

llanowarelves 4y ago
I agree with him but if he wanted to go more in-depth it might spawn a whole article (which I'd read)

djbusby 4y ago

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?)

deepsun 4y ago
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.

fubbyy 4y ago

react-query vs React Toolkit Query?

acemarke 4y ago
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: - https://redux-toolkit.js.org/rtk-query/comparison#unique-capabilities https://redux-toolkit.js.org/rtk-query/comparison#unique-cap... (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.)

nkozyra 4y ago

> 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.

acemarke 4y ago
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: - https://redux.js.org/introduction/why-rtk-is-redux-today https://redux.js.org/introduction/why-rtk-is-redux-today - https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu... - https://blog.isquaredsoftware.com/2022/06/presentations-modern-redux-rtk/ https://blog.isquaredsoftware.com/2022/06/presentations-mode... 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.
- dham 4y ago
  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.
  - acemarke 4y ago
    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: - https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff... 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: - https://github.com/markerikson/react-community-tools-practices-cheatsheet/discussions/1 https://github.com/markerikson/react-community-tools-practic... 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.

siquick 4y ago

Can’t say I disagree with any of this.

lmiller1990 4y ago

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).

basicallybones 4y ago
I'm not the original commenter, but see the 2019 update on this Dan Abramov article: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
- lmiller1990 4y ago
  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?

chrisco255 4y ago

> 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.

dham 4y ago
Note, I didn't say all animations, I said page transition. Don't animate a page transition.