4 ms·

The issues with useEffect come from a misunderstanding of how data is meant to flow in react, the fundamental concept on which the whole thing is based. It’s n

The issues with useEffect come from a misunderstanding of how data is meant to flow in react, the fundamental concept on which the whole thing is based. It’s not complicated at all.

mmis1000 1y ago
"It works when you do it correctly" isn't really a good argument when discussing UX/DX design in my opinion. Anything that isn't broken will also work when you use it correctly. The question is "how easy to do it correctly?". A poorly designed UX/DX takes user a lot of effort to use it correctly (macdonald's never fixed icecream machine). While a proper designed one allow the user to onboard easily withoud too much training.
- schwartzworld 1y ago
  > The question is "how easy to do it correctly?" It’s quite easy. The complaints people have about it are due to friction from using it wrong.
- skydhash 1y ago
  It’s very easy to do correctly. Hooks is a translation layer. Move everything that is not directly UI out of the component tree and let hooks bring it in. I’ve seen code where people dump the entire business logic into a component. Which is not good design.
  - mmis1000 1y ago
    I think the mvc era that business logic and view logics is separated completely has gone for a long time. No matter you like it or not. Or probably 'everyone' are using react wrong includes vercel...etc. But in latter case, it's still a giant dx issue. A framework that encourage you to use it incorrectly is not good. And keeps in mind, react hook until 18 (a long time since hook introduced) didn't offer a official way to connect component to external changing data. The only way you can do is by using useEffect incorrectly.
    - schwartzworld 1y ago
      > connect component to external changing data. The only way you can do is by using useEffect incorrectly. You mean correctly. That’s was what it was for. Syncing with external systems.
nemothekid 1y ago
I was around when React was released (I moved a large Angular app to React), and stopped doing frontend probably a year or two after React went all in on Hooks. I'm well aware of how React is meant to work and how data is supposed to flow in a React application. I agree isn't not complicated. You can understand it perfectly, but the language, API or framework does not make it conducive to easily writing correct code. Where this always ends up is in 3-4 years you end up with a codebase that is slow, complex and hard to reason but has no clear path to fix. If your large, complex, react app is slow - what is easier? Fixing the data architecture or adding a useMemo? Multiply by that by 1000 and you have a nightmare. The bad thing/escape hatch is vastly simpler than the proper thing, because something about language/framework/api makes doing the proper thing hard or unclear.
- schwartzworld 1y ago
  > but the language, API or framework does not make it conducive to easily writing correct code The language is sort of settled. The browser runs JS, so for most projects, it's the right choice. > If your large, complex, react app is slow - what is easier? Fixing the data architecture or adding a useMemo? It might be easy to add useMemo, but it doesn't work. People using a tool for the wrong thing because they don't understand it isn't a problem with the tool. It's unfortunate that a tool with a steep learning curve is the "default" for many devs now, but again that isn't a problem with the tool. I don't have any guardrails keeping me from using my saw as a hammer, it just doesn't work. > because something about language/framework/api makes doing the proper thing hard or unclear. It's unclear because it was built on functional programming concepts and most devs aren't taught that way. If you are familiar with those concepts, the whole thing is quite simple.
  - nemothekid 1y ago
    We simply have different boundaries on whats a tool problem vs a developer problem. If the tool is easily misused, the tool is wrong. i.e. "You're holding it wrong" is a problem with the phone, not the user. >The language is sort of settled. The browser runs JS, so for most projects, it's the right choice. TypeScript exists. Something could be made that compiles to JS that makes this easier.

The issues with useEffect come from a misunderstanding of how data is meant to flow in react, the fundamental concept on which the whole thing is based. It’s not complicated at all.

mmis1000 1y ago

"It works when you do it correctly" isn't really a good argument when discussing UX/DX design in my opinion. Anything that isn't broken will also work when you use it correctly. The question is "how easy to do it correctly?". A poorly designed UX/DX takes user a lot of effort to use it correctly (macdonald's never fixed icecream machine). While a proper designed one allow the user to onboard easily withoud too much training.

schwartzworld 1y ago
> The question is "how easy to do it correctly?" It’s quite easy. The complaints people have about it are due to friction from using it wrong.
skydhash 1y ago
It’s very easy to do correctly. Hooks is a translation layer. Move everything that is not directly UI out of the component tree and let hooks bring it in. I’ve seen code where people dump the entire business logic into a component. Which is not good design.
- mmis1000 1y ago
  I think the mvc era that business logic and view logics is separated completely has gone for a long time. No matter you like it or not. Or probably 'everyone' are using react wrong includes vercel...etc. But in latter case, it's still a giant dx issue. A framework that encourage you to use it incorrectly is not good. And keeps in mind, react hook until 18 (a long time since hook introduced) didn't offer a official way to connect component to external changing data. The only way you can do is by using useEffect incorrectly.
  - schwartzworld 1y ago
    > connect component to external changing data. The only way you can do is by using useEffect incorrectly. You mean correctly. That’s was what it was for. Syncing with external systems.

nemothekid 1y ago

I was around when React was released (I moved a large Angular app to React), and stopped doing frontend probably a year or two after React went all in on Hooks. I'm well aware of how React is meant to work and how data is supposed to flow in a React application. I agree isn't not complicated. You can understand it perfectly, but the language, API or framework does not make it conducive to easily writing correct code. Where this always ends up is in 3-4 years you end up with a codebase that is slow, complex and hard to reason but has no clear path to fix. If your large, complex, react app is slow - what is easier? Fixing the data architecture or adding a useMemo? Multiply by that by 1000 and you have a nightmare. The bad thing/escape hatch is vastly simpler than the proper thing, because something about language/framework/api makes doing the proper thing hard or unclear.

schwartzworld 1y ago
> but the language, API or framework does not make it conducive to easily writing correct code The language is sort of settled. The browser runs JS, so for most projects, it's the right choice. > If your large, complex, react app is slow - what is easier? Fixing the data architecture or adding a useMemo? It might be easy to add useMemo, but it doesn't work. People using a tool for the wrong thing because they don't understand it isn't a problem with the tool. It's unfortunate that a tool with a steep learning curve is the "default" for many devs now, but again that isn't a problem with the tool. I don't have any guardrails keeping me from using my saw as a hammer, it just doesn't work. > because something about language/framework/api makes doing the proper thing hard or unclear. It's unclear because it was built on functional programming concepts and most devs aren't taught that way. If you are familiar with those concepts, the whole thing is quite simple.
- nemothekid 1y ago
  We simply have different boundaries on whats a tool problem vs a developer problem. If the tool is easily misused, the tool is wrong. i.e. "You're holding it wrong" is a problem with the phone, not the user. >The language is sort of settled. The browser runs JS, so for most projects, it's the right choice. TypeScript exists. Something could be made that compiles to JS that makes this easier.