4 ms·

>The posters here wondering why you can't name them are on to something Imprecise phrasing on my part, the discussion here has been around naming hooks with Sy

by asark 8y ago

>The posters here wondering why you can't name them are on to something Imprecise phrasing on my part, the discussion here has been around naming hooks with Symbols. > We had from 5 to 8 people on the team at different times. Maybe maintaining one of the most popular open source projects isn’t “hard work” for you but we find it challenging. I meant React Hooks specifically, not Redux, which I assume is what you mean here. > We try to solve problems that product engineers run into. If you have better ideas we’d love to hear them. Use the built-in OOP system instead of writing a worse new one? Reinventing methods and properties with poor, misleading syntax as a thin layer over the OOP system of the host language is... well, it's helping bloggers, I guess.

danabramov 8y ago
I’d love to hear about your solutions but maybe don’t be so quick to dismiss other people’s hard work as something to “help bloggers”. If we were chatting face to face would you also behave like this? We’re very open to good technical arguments but this isn’t one.
- asark 8y ago
  > If we were chatting face to face would you also behave like this? Maybe? I usually very much would not, of course, but JS "culture" creates significant irritation and wasted time for me daily, and has for years, especially in React-land, since that's where the money is lately so it's hard to avoid. The only other software that gets me this exasperated is anything Poettering thinks up, but at least I don't personally have to work closely with any of that daily (any more, and for now). I'm sure I'll have to deal with hooks when people around me start using them. It's less that I'm upset that they exist than I feel like I'm being gaslighted. I've read the docs, and the source, because, again, I have to know this stuff. After the initial disbelief wore off I had a good laugh, like, actual LOL. This thread is the first of many I at that moment predicted I'd see as people who really, really in their hearts and in their actual technical needs and in the language they're using, just needed OOP, but are on the JS-must-be-functional-at-all-costs hype train, expressing frustration and confusion over this feature and burning lots of time trying to sort out how OOP works when you're trying so hard to not type "this" and pretending it's something else. It's a less-useful and confusing replacement for OO that re-implements just enough of it that people will 100% for sure hang themselves with it, and omits enough that people will complain about it. It's a perfect device for generating confusion. It's going to be used for no benefit, or misused harmfully, a ton, and meanwhile everyone's gonna be very confused about it. Ditto Redux—which is at least not funny in itself the way React Hooks are, though the flailing and consternation around it are—which is dead simple if you don't use the wrong words to describe things, yet how many person-hours have been lost trying to decipher what's going on there? So, so many. On the one hand it's funny, and I do legitimately enjoy all the accidental humor in React land. On the other I have to console, counsel, and train the folks who run into difficulty with this stuff, and live with or fix software in which it's been misunderstood and misused.
  - danabramov 8y ago
    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.
      - 8y ago

by asark 8y ago

danabramov 8y ago

I’d love to hear about your solutions but maybe don’t be so quick to dismiss other people’s hard work as something to “help bloggers”. If we were chatting face to face would you also behave like this? We’re very open to good technical arguments but this isn’t one.

asark 8y ago
> If we were chatting face to face would you also behave like this? Maybe? I usually very much would not, of course, but JS "culture" creates significant irritation and wasted time for me daily, and has for years, especially in React-land, since that's where the money is lately so it's hard to avoid. The only other software that gets me this exasperated is anything Poettering thinks up, but at least I don't personally have to work closely with any of that daily (any more, and for now). I'm sure I'll have to deal with hooks when people around me start using them. It's less that I'm upset that they exist than I feel like I'm being gaslighted. I've read the docs, and the source, because, again, I have to know this stuff. After the initial disbelief wore off I had a good laugh, like, actual LOL. This thread is the first of many I at that moment predicted I'd see as people who really, really in their hearts and in their actual technical needs and in the language they're using, just needed OOP, but are on the JS-must-be-functional-at-all-costs hype train, expressing frustration and confusion over this feature and burning lots of time trying to sort out how OOP works when you're trying so hard to not type "this" and pretending it's something else. It's a less-useful and confusing replacement for OO that re-implements just enough of it that people will 100% for sure hang themselves with it, and omits enough that people will complain about it. It's a perfect device for generating confusion. It's going to be used for no benefit, or misused harmfully, a ton, and meanwhile everyone's gonna be very confused about it. Ditto Redux—which is at least not funny in itself the way React Hooks are, though the flailing and consternation around it are—which is dead simple if you don't use the wrong words to describe things, yet how many person-hours have been lost trying to decipher what's going on there? So, so many. On the one hand it's funny, and I do legitimately enjoy all the accidental humor in React land. On the other I have to console, counsel, and train the folks who run into difficulty with this stuff, and live with or fix software in which it's been misunderstood and misused.
- danabramov 8y ago
  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.
    - 8y ago