3 ms·

I empathize with your frustration of having to work with something you don’t like (or feel is unnecessary). I would much prefer that people who don’t like React

I empathize with your frustration of having to work with something you don’t like (or feel is unnecessary). I would much prefer that people who don’t like React aren’t forced to use it but that’s not how job market works. Sorry about this. I’d love to see what OOP solution you envision for these problems. It’s not like we’re unfamiliar with OOP. In fact the OOP version of Hooks is what we had before. It’s called mixins. Mixins, like other forms of multiple inheritance, suffer from the “diamond problem” described in the post, and many others: https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamo... https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html#why-mixins-are-broken https://reactjs.org/blog/2016/07/13/mixins-considered-harmfu... If you have an OOP solution that solves the same problems Hooks solve, but without the downsides of mixins, I’d love to hear it. You’re being vague in your proposed fix which makes it difficult to discuss. I also want to emphasize we’re not “FP purists”. (In my opinion some codebases take FP way too far making the code very difficult to follow.) In many ways, Hooks help replace those heavy-handed patterns. So I think you might actually like them if you spend some time using them.

asark 8y ago
I entirely share your "ew, gross, no" re: mixins generally. That their being added to React in the first place is part of this history is definitely interesting. Thing is, I don't even consider Hooks not OO. They're just a really limited in-JS partial re-implementation with bizarre syntax. React tracks your "this" for you so it can dispatch the calls correctly. Your constructor gets mushed around in your render function for some reason. But it's attaching properties and methods to an instance. It's going to require care and discipline to use it correctly, given its quirks, so just direct that same discipline toward composition-over-inheritance instead, is my thought, which you can do without yet another way to write things. The fix is quit hitting yourself, in short, but if you don't I guess we'll hand you another way to hit yourself, but differently? This is just one more layer of complication that everyone's now got to understand (or, more likely, not, but use anyway) to even read other people's React codebases.
- danabramov 8y ago
  Sorry but this is still pretty hand-wavy :-) I’d be happy to discuss a specific “before” and “after” code example. There’s neither methods nor properties in Hooks code. I think you might be doing the same thing you think we are doing — you’re projecting the API you see onto the metaphors that feel more familiar to you. But these metaphors don’t really match what the API is doing or what it represents. But again, this discussion is fruitless without specific code examples to anchor it.
  - asark 8y ago
    > There’s neither methods nor properties in Hooks code. I think you might be doing the same thing you think we are doing — you’re projecting the API you see onto the metaphors that feel more familiar to you. But these metaphors don’t really match what the API is doing or what it represents. I mean that Hooks implementation re-implements key elements of a typical implementation of methods and properties, and end up mimicking them in important ways, differing mainly in the parts of that it doesn't include. Not that it actually uses methods and properties (though it does, of course—the "current component" that React tracks is an object, and the Hooks code leans on that to determine its calling context). > you’re projecting the API you see onto the metaphors that feel more familiar to you. Place a typical OO implementation next to what Hooks are doing, and you don't even have to squint to see that they're quite close. The porcelain's super-weird, yes—magical in all the "wrong" places, explicit in all the "wrong" places, missing a ton of mostly-inheritance-related stuff—but even with all that a Render function using Hooks manages to look an awful lot like a class declaration, as if someone had implemented classes in a language but forgotten to add any of the syntax to support it. EDIT: I mean, seriously. The source is public. It's a really fun read. https://github.com/facebook/react/blob/master/packages/react/src/ReactHooks.js https://github.com/facebook/react/blob/master/packages/react...

asark 8y ago

I entirely share your "ew, gross, no" re: mixins generally. That their being added to React in the first place is part of this history is definitely interesting. Thing is, I don't even consider Hooks not OO. They're just a really limited in-JS partial re-implementation with bizarre syntax. React tracks your "this" for you so it can dispatch the calls correctly. Your constructor gets mushed around in your render function for some reason. But it's attaching properties and methods to an instance. It's going to require care and discipline to use it correctly, given its quirks, so just direct that same discipline toward composition-over-inheritance instead, is my thought, which you can do without yet another way to write things. The fix is quit hitting yourself, in short, but if you don't I guess we'll hand you another way to hit yourself, but differently? This is just one more layer of complication that everyone's now got to understand (or, more likely, not, but use anyway) to even read other people's React codebases.

danabramov 8y ago
Sorry but this is still pretty hand-wavy :-) I’d be happy to discuss a specific “before” and “after” code example. There’s neither methods nor properties in Hooks code. I think you might be doing the same thing you think we are doing — you’re projecting the API you see onto the metaphors that feel more familiar to you. But these metaphors don’t really match what the API is doing or what it represents. But again, this discussion is fruitless without specific code examples to anchor it.
- asark 8y ago
  > There’s neither methods nor properties in Hooks code. I think you might be doing the same thing you think we are doing — you’re projecting the API you see onto the metaphors that feel more familiar to you. But these metaphors don’t really match what the API is doing or what it represents. I mean that Hooks implementation re-implements key elements of a typical implementation of methods and properties, and end up mimicking them in important ways, differing mainly in the parts of that it doesn't include. Not that it actually uses methods and properties (though it does, of course—the "current component" that React tracks is an object, and the Hooks code leans on that to determine its calling context). > you’re projecting the API you see onto the metaphors that feel more familiar to you. Place a typical OO implementation next to what Hooks are doing, and you don't even have to squint to see that they're quite close. The porcelain's super-weird, yes—magical in all the "wrong" places, explicit in all the "wrong" places, missing a ton of mostly-inheritance-related stuff—but even with all that a Render function using Hooks manages to look an awful lot like a class declaration, as if someone had implemented classes in a language but forgotten to add any of the syntax to support it. EDIT: I mean, seriously. The source is public. It's a really fun read. https://github.com/facebook/react/blob/master/packages/react/src/ReactHooks.js https://github.com/facebook/react/blob/master/packages/react...