I’m having a hard time understanding what problems this (and hooks in general) really solve. Why should I use the axios hooks over just using axios directly?
The problem isn't using axios, it's making sure your React components interact with axios appropriately. You will want the request to (1) fire when the component mounts, (2) cancel if it's going to unmount, and (3) re-render with the result/error once the request is finished. This is a pattern you will do over and over again. This gets really messy when one component needs to be able to make two or three different calls. The usual approach is to wrap that component with two or three different "container" components that each handle a different call. That keeps the view simple, but now the problem is insanely deep nesting of components.
Part of the goal with hooks is to give a way to abstract away the details of how you must interact with the React, without resorting to burying your view-components under 10 layers of controller-components.
And that is sort of solving a language verbosity problem with classes and inheritance and the fact that to mixin behaviors classically one would use inheritance but it doesnt compose well and had problems passing things up to different constructors.
Functions work better if you can call them because you can more easily select and add them ala carte and pass individual different specific parameters to each one whereas with inheritance you get one call to super (and advanced react components already extend a class further complicating super calls).
So it is best for one behavior having to only add something in one place to use that behavior. The class model fails because some behavior goes into ComponentDidMount and others go into ComponentWillUnmount and so on.
Hooks solve that. Everything required can be trvially bundled into one thing in one function call.
At first glance the biggest weakness I see for them is that they a bit too magical and that they operate at bit more dynamically than I think would be ideal. They rely on functions being called in the same order and waiting until functions are called for the first time, which seems like the opposite of “declarative”.
Having said that I’ve used them a bit and really like how much they cut down in boilerplate I just wish we had a something that felt a bit more like first class language supported (even if that support requires patching in something like jsx) I just don’t know how that would look or if it would look any different. It just feels like this is scratching deeper itch than just a react only problem but I can’t quite explain how (and maybe I am mistaken for that hunch). Maybe a more expressive language like a lisp would offer a hint at the solution.
Do you have thoughts regarding testing components that use hooks? I have not seen that addressed and not sure what the right approach should be. For hooks like state I imagine it just works, but if your hooks have more elaborate side effects... Do you mock the hooks? Their dependencies? Have hooks use context to do DI and take advantage of that in tests?
Ah interesting and makes a lot of sense. I’m used to using redux with some other middleware to solve this problem and honestly I’ve never been happy with it. Thanks for the response!
Your welcome! I've been playing with a class-based alternative to hooks that solves the same problems. We're using it in prod for a few spots at work and are considering publicizing it in the future. Personally, I find the API more natural.
Many front-end developers keep building the same thing over and over again with minor variations. To make the work feel more meaningful, it’s regularly reprojected onto a new pattern. Then you can go give a conference talk about “I did old thing X using new thing Y” and get away from the office for a day.
If you haven't yet, I'd encourage you to seriously read through the hooks docs [0], as well as Dan Abramov's recent post discussing why they settled on this API design [1].
I’ll dig into them. I skimmed them when hooks were first announced and felt like it was just a way to bolt on state to functional components. I should really revisit the intent of hooks.
The hooks docs are complete garbage. They don't explain anything properly and they use dumbed down language that ambiguates important details, in an attempt to make them more "accessible" to beginners (that somehow are too stupid to understand classes but can magically grasp these far more advanced concepts?).
Dan's blog post is much better, in comparison. Start with that maybe.
Why bother? There's no way a PR is going to get through on this. The entire Facebook team seems to fundamentally disagree that web developers should understand code rather than just write it.
Reusability, which software folks generally consider to be a good thing.
Let's say you used Axios directly in your components. That means every component needs to (1) set up its own state to track the request status (like whether it's loading, errored, the latest payload, etc.) and (2) set up its lifecycle hooks to kick off the request at the appropriate times, update the component's state, etc.
Do this a few times and you'll notice things becoming very repetitive. So naturally you look for a way to factor that out.
A higher-order component (basically a function that generates a component with all that boilerplate) is one option. Another option is what you see here – Hooks.
Yeah I’ve dealt with the repetition and boilerplate, but maybe I’m not working in react apps of significant size. I should really revisit hooks and understand them better.
Part of the goal with hooks is to give a way to abstract away the details of how you must interact with the React, without resorting to burying your view-components under 10 layers of controller-components.