7 ms·

I have to say stuff like this is why I'm not a big fan of the component approach to frontend dev. Reasoning about when and why something gets updated is not ver

I have to say stuff like this is why I'm not a big fan of the component approach to frontend dev. Reasoning about when and why something gets updated is not very intuitive. The other thing that tends to happen is that components become god objects. People stuff all their business logic in there, and suddenly most files in the project have a tsx or jsx extension. It's winforms code behind all over again. "React is a library not a framework" starts sounding pretty hollow. It's possible to not do this, so I can't strictly blame react for this - but it's happened in every react project I've seen.

ricardobeat 5y ago
That’s more a consequence of hooks & context in React specifically , rather than the component model. There are other frameworks where it’s much easier to reason about updates.
- LAC-Tech 5y ago
  What I meant by 'component' was the idea of state + templates being in the same thing. I prefer dumb views, but no issue with those dumb views being split up into sub views. But not 100% sure what you mean - could you expand?
  - ricardobeat 5y ago
    React encourages you to push state down, into components low in the tree, as seen in this article, which leads to "state and templates being in the same thing". But that is not a property of the component model; you can keep most of your components pure if you'd like, and keep the state and logic at a higher level. At that point there is little distinction between components and "sub views" in a template system. It would just be quite painful to work with. I do agree with your other point - it's almost impossible to use React as 'just a view library', it ends up permeating everything. I believe the hooks API aggravates both of these problems: the former by making it easier than the alternative patterns, the latter by creating function 'colors' that are contagious.
coding123 5y ago
This is confusing because before component models, everything was a global. I do agree about one thing though, before hooks, the standard recommendation was redux (or similar) I kept SCREAMING that it was a giant global anti-pattern. I don't think anyone understood that for the first 5 years of React. It seems like that whole thing is corrected now.
- dvt 5y ago
  > This is confusing because before component models, everything was a global. Hot take: I'd argue this is confusing because (almost) everything should be a global in UI development. Plenty of websites were built in PHP and basic Javascript with (gasp) globals! I guess some folks don't understand that people have been making pretty complex web apps since before 2013. It's monumentally counterproductive having to deal with state management in like 40 nested components because you just want the username and user email to trickle down. So people re-invented global state but we call it Redux now. It's a parody of a parody.
  - onion2k 5y ago
    Redux doesn't really have anything to do with passing data around in an app. Redux is only a state manager and reducer. Accessing that state manager in components is usually done using a React context provider (in a React app... Redux can be used with any library). Recent versions of Redux include a useSelector hook that manages that context provider for you, which is probably where some of the confusion comes from.
    - dvt 5y ago
      > Recent versions of Redux include a useSelector hook that manages that context provider for you, which is probably where some of the confusion comes from. There's no confusion, Redux absolutely does deal with passing around data in your app, that's why there's literally an FAQ dedicated to how to do it[1][2] -- and whether or not it should be done via setState or the Redux store. It's a stupid solution to a stupid problem, but now we're stuck here until TikTok will inevitably come up with their own "ground-breaking" React replacement in 5 or so years and we'll start the whole cycle again. [1] https://redux.js.org/faq/organizing-state#how-do-i-organize-nested-or-duplicate-data-in-my-state https://redux.js.org/faq/organizing-state#how-do-i-organize-... [2] https://stackoverflow.com/questions/37264415/how-to-optimize-small-updates-to-props-of-nested-component-in-react-redux https://stackoverflow.com/questions/37264415/how-to-optimize...
eyelidlessness 5y ago
You may want to look at SolidJS, and read some of the articles by its creator. The component model of dev doesn't imply any of this, even if the rendering approaches might learn from each other. Specifically: Solid has a component dev approach, but components vanish at runtime and it's just your reactive calls and the DOM from then on.
wonnage 5y ago
The alternative is manually hooking up a bunch of views that update by subscribing to some event bus, which quickly becomes unmanageable. I don't want to learn about all the custom events in the system to know how things update. And god help you if you have cascading/recursive events. Your mental model for updates can be shared across all apps that use React and it's a huge blessing for getting up and running with an unfamiliar codebase.
Cthulhu_ 5y ago
It's because while React offers a decent standard for declaring components, there is no standard for building an application with React as the rendering layer. I mean I've got an `api.ts` file somewhere with a TODO that says "I should probably split up API requests and business logic", but that's all handcrafted guesswork. Angular, for all its flaws and the major mistake that was announcing Angular 2 to be a rewrite etc causing a big exodus, at least had an Opinion on how to build an application end to end.
- thirdvect0r 5y ago
  Yep, Angular 2+ is so much better than React and Vue precisely because it's so opinionated. In 4 years of using it I've only really had issues with serverside rendering and even that got resolved on the repo pretty quickly
hardwaresofton 5y ago
Please: - Try Vue[0], Lit[1] (it's a bit cutting edge but I really like it), or the other entries in the component-building library space - Don't use redux/vuex all of that, and just write plain javascript objects that make fetch() calls - Don't use hooks (yet) If you do these things, you should find the component approach refreshing compared to copying and pasting HTML and managing event handlers/spaghetti and making your own structure. For all but the simplest of pages there should be an improvement over vanilla HTML+JS. If it makes you feel better, if you squint React looks exactly like Backbone views, which had a reason for existing back when they did, and if you go even further back it's like COM[2]. [0]: https://vuejs.org/ https://vuejs.org/ [1]: https://lit.dev/ https://lit.dev/ [2]: https://www.bitquabit.com/post/the-more-things-change/ https://www.bitquabit.com/post/the-more-things-change/
- iaml 5y ago
  >Don't use redux This is a puzzling advice to give to someone who wants to offload business logic away from components, as redux with sagas for example is a great place to put it. That way if you use selectors (preferably memoized as well) your components will only update when needed and you can organize business logic however you want.
  - hardwaresofton 5y ago
    It didn’t seem like the commenter didn’t know what Redux was, but more that they in using it as prescribed they still ran into the same issues. I was suggesting not using/needing redux mostly to reduce the starting level of complexity
    - iaml 5y ago
      I mean gp mentions they don't like the god components, and in my experience the kind of project where this becomes a problem is likely not using redux. Nowadays, redux is pretty well documented and there are ways to reduce boilerplate (for example, redux-toolkit) so I feel like it's a pretty good option to consider.
    - deleted 5y ago
tenaciousDaniel 5y ago
Every project I've inherited has done this, and every time I go through the tedious process of separating UI logic from business logic. If done the right way, a component-oriented approach can be very nice. But yes, if a dev thinks that React or Vue or whatever is somehow going to automatically create good architecture for them, then they're in for a bad time.
- loftyal 5y ago
  This is why you need to ask everyone who interviews "What is Container vs Presentational, and why is it good/bad". If you cannot give you a good answer don't hire them.
flowerlad 5y ago
To solve this problem you can use React with an MVC framework. See https://github.com/wisercoder/mvc-router https://github.com/wisercoder/mvc-router

ricardobeat 5y ago

That’s more a consequence of hooks & context in React specifically , rather than the component model. There are other frameworks where it’s much easier to reason about updates.

LAC-Tech 5y ago
What I meant by 'component' was the idea of state + templates being in the same thing. I prefer dumb views, but no issue with those dumb views being split up into sub views. But not 100% sure what you mean - could you expand?
- ricardobeat 5y ago
  React encourages you to push state down, into components low in the tree, as seen in this article, which leads to "state and templates being in the same thing". But that is not a property of the component model; you can keep most of your components pure if you'd like, and keep the state and logic at a higher level. At that point there is little distinction between components and "sub views" in a template system. It would just be quite painful to work with. I do agree with your other point - it's almost impossible to use React as 'just a view library', it ends up permeating everything. I believe the hooks API aggravates both of these problems: the former by making it easier than the alternative patterns, the latter by creating function 'colors' that are contagious.

coding123 5y ago

This is confusing because before component models, everything was a global. I do agree about one thing though, before hooks, the standard recommendation was redux (or similar) I kept SCREAMING that it was a giant global anti-pattern. I don't think anyone understood that for the first 5 years of React. It seems like that whole thing is corrected now.

dvt 5y ago
> This is confusing because before component models, everything was a global. Hot take: I'd argue this is confusing because (almost) everything should be a global in UI development. Plenty of websites were built in PHP and basic Javascript with (gasp) globals! I guess some folks don't understand that people have been making pretty complex web apps since before 2013. It's monumentally counterproductive having to deal with state management in like 40 nested components because you just want the username and user email to trickle down. So people re-invented global state but we call it Redux now. It's a parody of a parody.
- onion2k 5y ago
  Redux doesn't really have anything to do with passing data around in an app. Redux is only a state manager and reducer. Accessing that state manager in components is usually done using a React context provider (in a React app... Redux can be used with any library). Recent versions of Redux include a useSelector hook that manages that context provider for you, which is probably where some of the confusion comes from.
  - dvt 5y ago
    > Recent versions of Redux include a useSelector hook that manages that context provider for you, which is probably where some of the confusion comes from. There's no confusion, Redux absolutely does deal with passing around data in your app, that's why there's literally an FAQ dedicated to how to do it[1][2] -- and whether or not it should be done via setState or the Redux store. It's a stupid solution to a stupid problem, but now we're stuck here until TikTok will inevitably come up with their own "ground-breaking" React replacement in 5 or so years and we'll start the whole cycle again. [1] https://redux.js.org/faq/organizing-state#how-do-i-organize-nested-or-duplicate-data-in-my-state https://redux.js.org/faq/organizing-state#how-do-i-organize-... [2] https://stackoverflow.com/questions/37264415/how-to-optimize-small-updates-to-props-of-nested-component-in-react-redux https://stackoverflow.com/questions/37264415/how-to-optimize...

eyelidlessness 5y ago

You may want to look at SolidJS, and read some of the articles by its creator. The component model of dev doesn't imply any of this, even if the rendering approaches might learn from each other. Specifically: Solid has a component dev approach, but components vanish at runtime and it's just your reactive calls and the DOM from then on.

wonnage 5y ago

The alternative is manually hooking up a bunch of views that update by subscribing to some event bus, which quickly becomes unmanageable. I don't want to learn about all the custom events in the system to know how things update. And god help you if you have cascading/recursive events. Your mental model for updates can be shared across all apps that use React and it's a huge blessing for getting up and running with an unfamiliar codebase.

Cthulhu_ 5y ago

It's because while React offers a decent standard for declaring components, there is no standard for building an application with React as the rendering layer. I mean I've got an `api.ts` file somewhere with a TODO that says "I should probably split up API requests and business logic", but that's all handcrafted guesswork. Angular, for all its flaws and the major mistake that was announcing Angular 2 to be a rewrite etc causing a big exodus, at least had an Opinion on how to build an application end to end.

thirdvect0r 5y ago
Yep, Angular 2+ is so much better than React and Vue precisely because it's so opinionated. In 4 years of using it I've only really had issues with serverside rendering and even that got resolved on the repo pretty quickly

hardwaresofton 5y ago

Please: - Try Vue[0], Lit[1] (it's a bit cutting edge but I really like it), or the other entries in the component-building library space - Don't use redux/vuex all of that, and just write plain javascript objects that make fetch() calls - Don't use hooks (yet) If you do these things, you should find the component approach refreshing compared to copying and pasting HTML and managing event handlers/spaghetti and making your own structure. For all but the simplest of pages there should be an improvement over vanilla HTML+JS. If it makes you feel better, if you squint React looks exactly like Backbone views, which had a reason for existing back when they did, and if you go even further back it's like COM[2]. [0]: https://vuejs.org/ https://vuejs.org/ [1]: https://lit.dev/ https://lit.dev/ [2]: https://www.bitquabit.com/post/the-more-things-change/ https://www.bitquabit.com/post/the-more-things-change/

iaml 5y ago
>Don't use redux This is a puzzling advice to give to someone who wants to offload business logic away from components, as redux with sagas for example is a great place to put it. That way if you use selectors (preferably memoized as well) your components will only update when needed and you can organize business logic however you want.
- hardwaresofton 5y ago
  It didn’t seem like the commenter didn’t know what Redux was, but more that they in using it as prescribed they still ran into the same issues. I was suggesting not using/needing redux mostly to reduce the starting level of complexity
  - iaml 5y ago
    I mean gp mentions they don't like the god components, and in my experience the kind of project where this becomes a problem is likely not using redux. Nowadays, redux is pretty well documented and there are ways to reduce boilerplate (for example, redux-toolkit) so I feel like it's a pretty good option to consider.
  - deleted 5y ago

tenaciousDaniel 5y ago

Every project I've inherited has done this, and every time I go through the tedious process of separating UI logic from business logic. If done the right way, a component-oriented approach can be very nice. But yes, if a dev thinks that React or Vue or whatever is somehow going to automatically create good architecture for them, then they're in for a bad time.

loftyal 5y ago
This is why you need to ask everyone who interviews "What is Container vs Presentational, and why is it good/bad". If you cannot give you a good answer don't hire them.

flowerlad 5y ago

To solve this problem you can use React with an MVC framework. See https://github.com/wisercoder/mvc-router https://github.com/wisercoder/mvc-router