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.
Hooks are interesting. We are reading about it and evaluating it.
However, I have a hard time in understanding why I should use all these tiny ‘use’ libraries? Hooks are already simple to implement such small snippets yourself in your codebase.
I disagree. That something is reusable is not enough for it to become a library. There should be other benefits, because, using an external library has its own drawbacks.
As someone who works for a popular consultancy that helps out developers at big companies and reviews their code: ANY library you can point people to and say "do it this way" is an absolute godsend.
You really do not want large numbers of developers, with varying levels of experience, trying to figure out how to do something that has already been solved, and making the same avoidable mistakes in the process – unless you are deliberately trying to teach them something at that moment (whereas most of the time they are just trying to get things done on a tight schedule).
The job of a developer is only secondarily to write code. The primary job is to fulfill the actual real-world needs of their business or organization. Customers don't want code, they just want their needs met. Unfortunately sometimes this involves barfing out a lot of code – which is more likely a liability, not an asset to the company. The more new code we can avoid bringing into the world, the better.
I agree that “do it this way” can be godsend. However, suggesting a library is only one of the ways. By suggesting all these tiny libraries, I don’t think we will mentor the less experienced community in the right direction.
Quick aside about Dan Abramov. The guy is like Superman when it comes to answering React questions and untangling tricky misconceptions. He shows up at the right time, on HN, Reddit, Medium, and random blog posts His dedication to React, the library, and the web community at large, is staggering to me. Thank you!
