All the examples are fetching data from a server, and in such cases I think tanstack query already does all the hard part. I feel like people under-use react query and put too much state in their FE. This might be relevant if your app has some really complicated interactions, but for most apps they should really be a function of server , not client, state. Of course this exact reasoning is why I moved off react altog…
Yeah, fetching data from a server in useEffect is a widely acknowledged and documented antipattern.
You can do this pretty simply with hooks and reducers, where the reducer/dispatch are the model/controller. Class components have their own pitfalls when you start messing around with componentDidUpdate, which was part of the motivation behind functional components IIRC.
Not everyone likes hooks. Class components may have issues, but if hooks are the solution I'll stay with class components, thank you very much!
I will say that I used to really not like hooks and that’s because I think the migration documentation and messaging was handled pretty poorly.
That being said, if you’ve worked with state management like Redux, I would argue that hooks are pretty similar to how you hook up that kind of data store.
All the examples are fetching data from a server, and in such cases I think tanstack query already does all the hard part. I feel like people under-use react query and put too much state in their FE. This might be relevant if your app has some really complicated interactions, but for most apps they should really be a function of server , not client, state. Of course this exact reasoning is why I moved off react altog…
Yeah, fetching data from a server in useEffect is a widely acknowledged and documented antipattern.
It's a widely documented anti-pattern, while also not giving a convenient alternative.
Sorry for being pedantic, but the first example could be rewritten to extract the pattern into a higher level hook, eg useNotifications. One way to simplify components before reaching for store libraries. The reusable hook now contains all the state and effects and logic, and the component is more tidy. function Dashboard() { const { user } = useAuth(); const {loading, error, notifications, undreadCount, markAsRead}…
I was wondering if I was crazy for thinking "how is what he's suggesting different than just putting that 'class' into a hook function?" I'm glad to see someone already wrote it up, kudos.
Not everyone likes hooks. Class components may have issues, but if hooks are the solution I'll stay with class components, thank you very much!
I will say that I used to really not like hooks and that’s because I think the migration documentation and messaging was handled pretty poorly. That being said, if you’ve worked with state management like Redux, I would argue that hooks are pretty similar to how you hook up that kind of data store.
Yeah, Redux is another big mistake I stayed away from. "Line after line of throat clearing and pseduostructure", as one developer put it [1]
Javascript and classes go together like toothpaste and orange juice. All good JS programmers I know essentially pretend that classes don't exist in the language (or if they use them, they only do so rarely, for very niche cases). JS does not have classical OOP built in! It has Brandon Eich's prototypal inheritance system (which has some key differences), along with a 2015 addition to the language to pretend it has OO…
Encapsulation, inheritance and polymorphism all work fine with JavaScript classes. OOP works just fine. What doesn't work in JavaScript is functional programming.
JS is primarily a functional language, it is built around functions as first class objects and closures.
The issue is the bar has been raised for what people call "functional" now. Everyone is picky "OMG not pure so it isn't really functional!!"
The problems OP tries to address are unfortunately a deep design flaw in mainstream frameworks like React and Vue. This is due to 2 properties they have: 1. They marry view hierarchy to state hierarchy 2. They make it very ergonomic to put state in components I've been through this endless times. There are significant ways to reduce this friction, but in the end there's a tight ceiling. This is why this kind of work…
Vue provides a computed feature that acts as a buffer layer between the view and the state, so the view and the state are not necessarily strictly bound
All the examples are fetching data from a server, and in such cases I think tanstack query already does all the hard part. I feel like people under-use react query and put too much state in their FE. This might be relevant if your app has some really complicated interactions, but for most apps they should really be a function of server , not client, state. Of course this exact reasoning is why I moved off react altog…
Yeah, fetching data from a server in useEffect is a widely acknowledged and documented antipattern.
Is it? I have never had any issues doing it this way.
Sorry for being pedantic, but the first example could be rewritten to extract the pattern into a higher level hook, eg useNotifications. One way to simplify components before reaching for store libraries. The reusable hook now contains all the state and effects and logic, and the component is more tidy. function Dashboard() { const { user } = useAuth(); const {loading, error, notifications, undreadCount, markAsRead}…
Working with multiple teams in a large project, hooks can be a nightmare to maintain. I see 7x layers deep of hooks, with no test cases to support them. Some of the side effects are not properly tested, and mocks that abstract away the whole implementation means the test case only works for certain scenarios. FWIW this scenario might be an outlier in large projects, considering how some developers prefer to "just wra…
That's a valid concern. I've seen some hard to grok hooks with polling, async stuff, hard to follow logic, etc. Like with anything, need to have taste, it's easy to dump too much into one hook and like you mention, it gets hard to follow what gets triggered when.