131–140 of 181 posts
Earlier quoted context omitted.
True. I used ExtJS and Ember for years and React just operates on another level.
I would say the same for Elm architecture and type system that guarantees no runtime exceptions. There is nothing similar in frontend languages and frameworks.
But last time I looked, the JavaScript integration did feel quite a bit more cumbersome than with Reason.
Hooks seem to be a drastic change in how we're going to write React components in the future. I'm quite satisfied with the current way of writing components which is to me is very explicit (with no magic). With Hooks React is taking a different direction from their original motto of explicit design patterns. From the looks of it, Hooks seems like a counter-intuitive design pattern but traditionally that's how most of…
Earlier quoted context omitted.
But that’s not how it works. They don’t run during initialization, they run on every render. That’s their whole point and what makes them dynamic. I tried to explain this here: https://overreacted.io/why-do-hooks-rely-on-call-order/#flaw...
Do you find it concerning that many software engineers with extensive professional React experience have such a difficult time understanding hooks?
Earlier quoted context omitted.
What's wrong with setstate? I have used it without problem.
There's nothing wrong with `setState`, in my opinion. However, it does do magic. Although it might feel like it immediately sets the state to be what you provide it as argument, it actually schedules a state update to be performed later when React feels like it. That's why it's best practice to provide an updated function rather than a plain object: if the new state depends on the previous one, and you read the previ…
Earlier quoted context omitted.
Glad to read that as the top comment, because when they came out, I expressed strong doubts about this new features, and I mostly received mad comments in return. The alienated react fans stated that I didn't understand what modern code was, what a great idea those were and how from now on, everything will be better. Now hooks are certainly a technically interesting pattern. I can see why it can be desirable by some.…
> Glad to read that as the top comment, because when they came out, I expressed strong doubts about this new features, and I mostly received mad comments in return. The alienated react fans stated that I didn't understand what modern code was, what a great idea those were and how from now on, everything will be better. Your post boils down to "Seems like it might be nice, but there might be bad sides, too" which seem…
Are hooks being accepted as a good design by the community? It seems to me that the lack of a parameter explicitly indicating the component and the reliance on hook ordering to match them across calls of the component function make them a bad design, but I might very well wrong and would be happy to be convinced otherwise.
I think time will tell. It's basically the magic vs explicit discussion all over again. Like usually in this discussion, the magic approach is really appealing until it doesn't work, and then the pro-explicit people will go all "told you so" on you. I personally really prefer explicit, having cut my fingers on magic one time too often. Instead, I'll gladly create classes if the thing I'm making has its own state (of…
Are hooks being accepted as a good design by the community? It seems to me that the lack of a parameter explicitly indicating the component and the reliance on hook ordering to match them across calls of the component function make them a bad design, but I might very well wrong and would be happy to be convinced otherwise.
I think time will tell. It's basically the magic vs explicit discussion all over again. Like usually in this discussion, the magic approach is really appealing until it doesn't work, and then the pro-explicit people will go all "told you so" on you. I personally really prefer explicit, having cut my fingers on magic one time too often. Instead, I'll gladly create classes if the thing I'm making has its own state (of…
Create a data loader hook that loads your data in a one-shot effect (you pass it the identities array), and which returns either a valid view (an error or loading view) and no data, or no view and valid data of type T. Then you can just do:
const loader = useDataLoader(async () => {
const a = await getDataA();
const b = await getDataB(a);
return b.data;
});
return loader.view ||
Never a boring day being a frontend developer. Looking forward to add hooks to my React project. The next frontier would probably be functional strongly typed languages, like Reason or some variation on Elm?
Earlier quoted context omitted.
My litmus test for technology is whether it results in a) fewer lines of code b) simpler code and c) does it make me more productive. My experience with using hooks is that I rip out lots of cruft and it is easier for me to get my head around how to write things so I am more productive. The cost is learning a new paradigm, but the benefit for me was very high.
I strongly recommend you temper your criterion `a` by how much the abstractions help or impede your understanding of the code later on, especially when trying to diagnose a bug.