| This is not a very good article. > The reason people started embracing functional languages was that, for the most part, they did away with state in favor of just passing functions everywhere. No no no. They did not 'do away with state'. Handling state became _explicit_ rather than implicit. Haskell, for example, has _tons_ of different ways of handling state depending on the specific situation. State is a key feature of React, and the question is not whether to have it or not, but how to support it. > OK, I just spent several paragraphs explaining why SOLID principles apply No, you didn't. You explained to someone that already cares about SOLID that they can apply that thinking here. But didn't explain why I, someone that doesn't care about that acronym, should care in this or any other case. > People complain about all the boilerplate in Redux mapStateToProps/mapDispatchToProps, but what that boilerplate does is give you a specific place to put the dependencies that is outside the View, so that the View can focus on rendering the Model and capturing user input, without worrying about saving user input back to the Model or exactly where in the Model the data to display lives. A react component is a view function with some effects + local state. Whether you represent that with a class or a function + hooks doesn't change that. It's just a different set of tools. The principles don't change. You can architect your view function however you like. > But you don’t gain anything from that hiding, because you have to read the code of the hook to understand what arguments to pass it and what it returns. This is...just how programming works? Functions typically have documentation describing inputs and outputs. > Now, let’s implement isAnyOf like a component with hooks You're taking a simple function and turning it into a...component? What does that even mean? What dependencies are you talking about? What is the point of all this? It's just a higher order function. > There’s a direct dependency running from App -> useDataApi, because App is directly reaching out and grabbing that dependency. There is no way to swap that out for a different implementation. The component is a function. You can pass things into a function! You learn this in your first week of programming. What is the insight here? Why make this sound so complicated? > And hooks set people up to create problems for themselves, in part because they encourage violation of those principles. You haven't shown this at all. How do functions discourage abstraction? It's a choice by the programmer! |