At the end of the day, components will always need a way to interface with state. Often times you want local component state because the cost of abstracting that tiny bit of state into some top level application state is disproportionately high - it just isn't a pragmatic choice. And for application state, ultimately if you have any interactivity in your application (which, if you have state, presumably you do), at _some point_ you're going to have to do something other than "map props to HTML".
> If you're doing anything other than that, your function components aren't really pure functions.
Nobody claims they are pure functions. They aren't - but that doesn't really matter. Its an API choice that encourages productivity while still having tools for the abstraction that you are advocating for.
State hooks can be seen as a sibling of props - both are inputs to the component, but whereas props "push" data into the component, hooks "pull" data from somewhere else. This _is_ separating concerns - when a component needs data that isn't inherently something the calling parent owns, then making it a prop would just be forcing that component's concerns up the tree. Often it is better for it to just be an impl detail.
I don't find the article here super compelling, and as a general practice it is often better to author your own custom hooks that encapsulate things like the underlying HTTP request away so that your component is only dealing with its own concerns, but functionally there's no difference and its just a matter of how you split up your code.
> If you're doing anything other than that, your function components aren't really pure functions.
Nobody claims they are pure functions. They aren't - but that doesn't really matter. Its an API choice that encourages productivity while still having tools for the abstraction that you are advocating for.
State hooks can be seen as a sibling of props - both are inputs to the component, but whereas props "push" data into the component, hooks "pull" data from somewhere else. This _is_ separating concerns - when a component needs data that isn't inherently something the calling parent owns, then making it a prop would just be forcing that component's concerns up the tree. Often it is better for it to just be an impl detail.
I don't find the article here super compelling, and as a general practice it is often better to author your own custom hooks that encapsulate things like the underlying HTTP request away so that your component is only dealing with its own concerns, but functionally there's no difference and its just a matter of how you split up your code.