251–260 of 444 posts
Also, composing asynchronous behavior with useEffect is also not a good idea. Don't abuse useEffect as an Event Handler (too much). Think about using Redux (+ thunks/saga) or something similar.
This article hits on something I've felt for a long time. The idea that "hooks are superior" to me is ridiculous. If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges! Solid is nice and _seems_ to fix the issues with hooks, but as another comment mentioned, the challenge is with building at scale…
Yes hooks are not great. They violate too many functional programming rules that the react team pretend to care about. I still like using them however. I had a few issues when trying to do more abstract code.
They are highly, deliberately, emphatically procedural.
The order they are called matters! The time of when they are called matters! The number of times they are called matters! You get a different result from calling the same hook with the same arguments at different times! You get different results if the call site for them is in different places!
They do enable you to do some things in JavaScript that are more easily enabled with higher ordered function stuff in functional languages, but there is nothing ‘functional’ about how hooks work or how they are used.
And that’s okay! ‘Functional’ doesn’t automatically mean ‘better’ and ‘procedural’ doesn’t mean ‘worse’. For what they do, hooks (considered as the entire hooks ecosystem including linting extensions that help enforce the rules as if they were syntax errors) are a very clever extension within JavaScript syntax that let you pull off some very neat separation of concerns in a reactive code model.
‘Functionalness’ has very little to do with whether hooks are good or bad.
I've used React for ~3 years, primarily with function components and hooks. I think that hooks were a wonderful addition and I think the framework has made smart choices with checking object equality to decided if components re-render. That said, I think that easily the most difficult aspects of react revolve around how re-renders are triggered. Maintaining referential equality to stop unnecessary renders gets tricky…
Earlier quoted context omitted.
Class components are fine for the simplest examples, but the moment they start increasing in complexity, they become a bit of a mess. Sharing functionality across multiple components becomes tricky with class components (with the only real option being HoCs / render props). You necessarily have to spread logic across different lifecycle methods. Hooks allow you to bundle code together by functionality, and consequent…
I think in the class world this is normally done by writing a service and injecting it on the constructor of the parent class. Since, React doesn't have DI built-in, it becomes problematic with the injection. hooks are essentially classes imo.
I just dove back into react after a while in vue and deep in some backend systems. I love the new ergonomics (hooks, useEffect, redux tools) but I definitely hit the exact issue OP mentions almost immediately. I don’t feel that the solution react provides is too out there, but agree it could be better. The react ecosystem still makes it worth the one or two “could be betters” for me.
In general I want to keep async logic out of my components as much as possible. I also don't want the component rendering to drive the async logic.
Earlier quoted context omitted.
When I started with classes, I hardly had to read the docs, few hours and was good to go. For many developers I worked with at the time this was the case. React was easy coming from jQuery, Backbone other frameworks at the time. With effects, i've read the docs many times. I still don't fully understand how it's supposed to work. I don't seem to get the feeling / abstract concept behind it and it still surprises me a…
Well if you do not want to read the docs, go with vanilla JS ;) Seriously, no matter what you use, read the docs. Arguing that a library should not require you to read the docs is just nonsense - cause any library makes decisions about abstractions for a reason. If you do not want/need those abstractions, do not use the library blindly. It is always the case that you should now and agree with those, that is why you u…
New JS frameworks always make for compelling hello world examples. Can you branch on state or use loops over data in Solid.js? The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty! As an example of this point, check out the "Simple Todos" example for So…
>…much like traditional templating languages, we get a construct like that reinvents a concept that's already in the language. I'm right there with you, but when React invents a whole markup language inside of JavaScript, it's not in much of a standing to make purity criticisms.
It has no intrinsic semantics, and maps pretty much directly to actual javascript (which you can write directly or use an alternative helper for — hyperscript being a common one).
I swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale. react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sug…
> All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sugar (vue has jsx support). Honestly, the boon of React is just how easy it is to create components, or at least how simple things were back in the day - it is exceedingly composable , moreso than AngularJS, Angular or Vue have been, at least in my experience.…
Furthermore, a lambda local to a function can be a full-blown component (visible in DevTools etc.).
So if you need a component that is used in only one other component, you can neatly encapsulate it and make it invisible from the outside, which can be useful on occasion.
This article hits on something I've felt for a long time. The idea that "hooks are superior" to me is ridiculous. If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges! Solid is nice and _seems_ to fix the issues with hooks, but as another comment mentioned, the challenge is with building at scale…
After working with React for years it is something I would not recommend and can only think of limited use cases to use. You can write really performant software in React, but ergonomic (beyond stockholm syndrome) I would not call it. It's also difficult to implement quality software engineering principles in a React application such that an application is maintainable, glacable and easy for someone new to a project…
New JS frameworks always make for compelling hello world examples. Can you branch on state or use loops over data in Solid.js? The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty! As an example of this point, check out the "Simple Todos" example for So…
>…much like traditional templating languages, we get a construct like that reinvents a concept that's already in the language. I'm right there with you, but when React invents a whole markup language inside of JavaScript, it's not in much of a standing to make purity criticisms.
It's about as pure as you can get while having any sort of html-ish 'templating' whatsoever.
So, I'd say it's exactly in the right place to be making purity criticisms. They've taken the only approach that preserves the integrity of the code and doesn't involve build time magic.