7 ms·

Suspense is a pretty weird step into "magic" for a library that has been a pretty damn thin layer on top of JS for so long, I fully agree with that. Using it is

by nawgz 5y ago

Suspense is a pretty weird step into "magic" for a library that has been a pretty damn thin layer on top of JS for so long, I fully agree with that. Using it is somewhat pleasant in terms of terseness, but very unpleasant for the fact I do not have a good understanding of how the lifecycles of the async resource(s) influence the render schedule, which is really the core of React from my perspective

deckard1 5y ago
> weird step into "magic" for a library that has been a pretty damn thin layer on top of JS I mean, hooks are totally this. They fundamentally break the concept of a "function" despite calling them "functional components." They use this weird notion of state (i.e. magic). The best way I can describe it is a cousin of dynamic scoping from the bad old LISP days. Back before lexical scoping was invented. So you end up with all these caveats and gotchas. Go look up useRef with useEffect and useCallback. It's all a total clusterfuck. The lifecycle methods weren't perfect. But at least you could understand them. But I lost a lot of respect for React way back when they started fussing with the lifecycle API, a year or two before hooks. Their vDOM abstraction was starting to leak heavily and they were struggling to make sense of it. When people say they like React, I really suspect they mean they like JSX. React, itself, is a mess. Always has been.
- ironmagma 5y ago
  They’re called “function components,” not “functional”, because they reside within a JS `function` as opposed to a class. The word you’re looking for is side effect. The `use*` family of functions operate as hooks from the component into the renderer, so the renderer can easily see what dependencies a component has. This is accomplished by producing side effects. The lifecycle methods are all well and good but there was an ergonomic problem with them with shouldComponentUpdate. No one wants to implement that function by hand when it involves whitelisting all props you want to produce a rerender, which is most of them. People would always write bugs. It’s much easier to create a list of dependencies a la second argument to useEffect.
  - dragonwriter 5y ago
    > It’s much easier to create a list of dependencies a la second argument to useEffect. Even easier to just not do that, either, as in Solid’s version of hooks.
    - ironmagma 5y ago
      Honest question, is what you’re referring to this[1] or something else? I’d be interested to see how hooks could work without side effects. [1] https://github.com/ryansolid/component-register-hooks https://github.com/ryansolid/component-register-hooks
      - dragonwriter 5y ago
        > Honest question, is what you’re referring to this[1] or something else? I’m talking about Solid, the web framework, which has hooks (they call them “effects”) similar to those in React, but which do not require explicit dependency lists when specifying them. https://www.solidjs.com/tutorial/introduction_effects https://www.solidjs.com/tutorial/introduction_effects
        ironmagma 5y ago
        Thanks. I don't understand how it's better though, wouldn't you need to start following the Rules of Hooks for this data retrieval (`count()`) as well, lest the renderer not know what all your dependencies are?
  - deckard1 5y ago
    > They’re called “function components,” not “functional” They've been calling them functional components forever. https://github.com/facebook/react/blob/main/packages/react/index.js#L11 https://github.com/facebook/react/blob/main/packages/react/i... I'm not sure why you're being a language nazi here. It's beside the points I was making anyway. > The word you’re looking for is side effect. Enough with your patronizing. Obviously it is using side-effects. That's the entire point I was making. Functions (as in the term from "functional programming") do not produce side-effects. Functions do not contain state. You know what is good at containing state? Objects. The whole paradigm of an "object" is exactly what React is trying to do with functions. It's nonsense. You can't call a hook function outside of React's apparatus. When React calls one of these hook functions, it has to dynamically switch out the context. Which is where my analogy to dynamic scoping comes from. > an ergonomic problem with them with shouldComponentUpdate. No one wants to implement that function Yes, well, as I said React has always been a mess and there are just as many problems with useEffect. Throwing out the entire API is just dumb. Libraries are no longer universal. You have to consider whether it's using hooks or not. Especially since they never formally deprecated lifecycle methods. They just shrugged their shoulders and went "here's hooks, use them if you like them."
- nawgz 5y ago
  > I mean, hooks are totally this. They fundamentally break the concept of a "function" despite calling them "functional components." They use this weird notion of state State and React have always been fundamentally intertwined, so I'm going to heavily disagree with the claim that hooks are a new magic wrt React. Personally, as someone who has used React for a long time, hooks have been a very intuitive and terse new syntax to use the lifecycle hooks & provides a far superior way to deal with state machine transitions. > Go look up useRef with useEffect and useCallback I must say, as a pro web developer who has built loads of applications, including model editors, charts with React views on top of D3 math, interactive 3D renderings, graphs, you name it, I don't know why I would have anything to do with "useRef with useEffect and useCallback". I've never encountered any issue with these things. What use case are you trying to solve that requires those hooks and what issue with those hooks exists that is blocking you? > I really suspect they mean they like JSX. React, itself, is a mess. Always has been Oh, you just hated React all along, so you probably never understood it. Easy to see why you don't like it then.
  - deckard1 5y ago
    > why I would have anything to do with "useRef with useEffect and useCallback". I've never encountered any issue with these things. The fact that you are asking and haven't hit the issue suggests you haven't actually used useRef before. > Oh, you just hated React all along, so you probably never understood it. Sure, asshole. I've only been using React for 6 years now. But whatever.
    - nawgz 5y ago
      > The fact that you are asking and haven't hit the issue suggests you haven't actually used useRef before. Or that you are doing questionable things with it? My guess from your tone and general confusion around React is that you expect useRef to have lifecycle hooks when the `current` value changing does not have any lifecycle hooks at all, and somehow your problem with that has made you rail against these hooks. Feel free to enlighten me - I have useRef and useEffect all over my codebases, I have never used useCallback though > Sure, asshole. I've only been using React for 6 years now Your own words: "React, itself, is a mess. Always has been". That's a comical statement to make if you're not emotionally biased against a library. Especially when that library is well-organized, with strong lifecycle guarantees, and gives you the strongest out-of-the-box composability of any comparable web framework. But no, it's you that's right, React sucks and doesn't work, it's the top JS library because JS developers are idiots right? Edit: it additionally appears you downvoted my entire thread contribution, so I'm going to take it as you don't understand the point of useRef at all. :)
- steve_adams_86 5y ago
  I think this is a case of to each their own. I find hooks provide a far more declarative, testable, predictable developer experience. The simplicity of useEffect, useCallback, useRef, etc. makes it so I know exactly what I need to reach for when I need to accomplish certain things. It can get complex, but I find that usually means you need to back off and rethink things.
recursive 5y ago
Pretty damn thin layer? The language with its own syntax and build tools? The one with JSX? React is one of the thicker layers I've seen.
- nawgz 5y ago
  Oh no, JSX that compiles down to the exact set of `new Object` calls you would expect in a tree structure, how can I understand such complexity!? Really, you're kidding yourself if you think React isn't far simpler than Angular or Vue or any of these other frameworks. If you have some different direction in mind, fine, but I doubt it scales
  - recursive 5y ago
    Don't misunderstand. I like JSX. However, that doesn't compel me to call it thin.
    - nawgz 5y ago
      I find that strange. For example, I would call Angular or Vue "thick" with their extra templating files and DSLs and two-way binding. I would call React thin because the JSX components you build are transparently just objects, they interact with types super gracefully because components are just classes with a method that returns nested objects, and your code is just invoking JS and producing JS until the React library itself performs the side effect of rendering. I understand that React has abstractions and a heavy scheduling engine and all sorts of complexity, but a React component - the core concept of React - reuses directly JS concepts in place of introducing its own in most situations. That is thin. I admit that if you are just thinking of libraries in general, of course a frontend framework is not "thin", but for a library which enables true composability and reuse, React is so thin compared to is competitors. Which seems a reasonable de facto context for a conversation about React.
      - recursive 5y ago
        I don't think it's thin even in that context. For example, invoking a hook comes with a bunch of rules beyond "just javascript". You shouldn't invoke a hook conditionally. You shouldn't invoke a hook in a loop. I've run into state/props mismatches due to the diff resolving differently than I thought it should. It's possible to solve this, but it further breaks the illusion of a thin layer. Maybe it's a different way of thinking, but I don't think two-way binding is inherently thicker. To me, thickness is related to the amount of "mechanism". A handlebars-type templating system seems much thinner to me.

by nawgz 5y ago

deckard1 5y ago

> weird step into "magic" for a library that has been a pretty damn thin layer on top of JS I mean, hooks are totally this. They fundamentally break the concept of a "function" despite calling them "functional components." They use this weird notion of state (i.e. magic). The best way I can describe it is a cousin of dynamic scoping from the bad old LISP days. Back before lexical scoping was invented. So you end up with all these caveats and gotchas. Go look up useRef with useEffect and useCallback. It's all a total clusterfuck. The lifecycle methods weren't perfect. But at least you could understand them. But I lost a lot of respect for React way back when they started fussing with the lifecycle API, a year or two before hooks. Their vDOM abstraction was starting to leak heavily and they were struggling to make sense of it. When people say they like React, I really suspect they mean they like JSX. React, itself, is a mess. Always has been.

ironmagma 5y ago
They’re called “function components,” not “functional”, because they reside within a JS `function` as opposed to a class. The word you’re looking for is side effect. The `use*` family of functions operate as hooks from the component into the renderer, so the renderer can easily see what dependencies a component has. This is accomplished by producing side effects. The lifecycle methods are all well and good but there was an ergonomic problem with them with shouldComponentUpdate. No one wants to implement that function by hand when it involves whitelisting all props you want to produce a rerender, which is most of them. People would always write bugs. It’s much easier to create a list of dependencies a la second argument to useEffect.
- dragonwriter 5y ago
  > It’s much easier to create a list of dependencies a la second argument to useEffect. Even easier to just not do that, either, as in Solid’s version of hooks.
  - ironmagma 5y ago
    Honest question, is what you’re referring to this[1] or something else? I’d be interested to see how hooks could work without side effects. [1] https://github.com/ryansolid/component-register-hooks https://github.com/ryansolid/component-register-hooks
    - dragonwriter 5y ago
      > Honest question, is what you’re referring to this[1] or something else? I’m talking about Solid, the web framework, which has hooks (they call them “effects”) similar to those in React, but which do not require explicit dependency lists when specifying them. https://www.solidjs.com/tutorial/introduction_effects https://www.solidjs.com/tutorial/introduction_effects
      - ironmagma 5y ago
        Thanks. I don't understand how it's better though, wouldn't you need to start following the Rules of Hooks for this data retrieval (`count()`) as well, lest the renderer not know what all your dependencies are?
- deckard1 5y ago
  > They’re called “function components,” not “functional” They've been calling them functional components forever. https://github.com/facebook/react/blob/main/packages/react/index.js#L11 https://github.com/facebook/react/blob/main/packages/react/i... I'm not sure why you're being a language nazi here. It's beside the points I was making anyway. > The word you’re looking for is side effect. Enough with your patronizing. Obviously it is using side-effects. That's the entire point I was making. Functions (as in the term from "functional programming") do not produce side-effects. Functions do not contain state. You know what is good at containing state? Objects. The whole paradigm of an "object" is exactly what React is trying to do with functions. It's nonsense. You can't call a hook function outside of React's apparatus. When React calls one of these hook functions, it has to dynamically switch out the context. Which is where my analogy to dynamic scoping comes from. > an ergonomic problem with them with shouldComponentUpdate. No one wants to implement that function Yes, well, as I said React has always been a mess and there are just as many problems with useEffect. Throwing out the entire API is just dumb. Libraries are no longer universal. You have to consider whether it's using hooks or not. Especially since they never formally deprecated lifecycle methods. They just shrugged their shoulders and went "here's hooks, use them if you like them."
nawgz 5y ago
> I mean, hooks are totally this. They fundamentally break the concept of a "function" despite calling them "functional components." They use this weird notion of state State and React have always been fundamentally intertwined, so I'm going to heavily disagree with the claim that hooks are a new magic wrt React. Personally, as someone who has used React for a long time, hooks have been a very intuitive and terse new syntax to use the lifecycle hooks & provides a far superior way to deal with state machine transitions. > Go look up useRef with useEffect and useCallback I must say, as a pro web developer who has built loads of applications, including model editors, charts with React views on top of D3 math, interactive 3D renderings, graphs, you name it, I don't know why I would have anything to do with "useRef with useEffect and useCallback". I've never encountered any issue with these things. What use case are you trying to solve that requires those hooks and what issue with those hooks exists that is blocking you? > I really suspect they mean they like JSX. React, itself, is a mess. Always has been Oh, you just hated React all along, so you probably never understood it. Easy to see why you don't like it then.
- deckard1 5y ago
  > why I would have anything to do with "useRef with useEffect and useCallback". I've never encountered any issue with these things. The fact that you are asking and haven't hit the issue suggests you haven't actually used useRef before. > Oh, you just hated React all along, so you probably never understood it. Sure, asshole. I've only been using React for 6 years now. But whatever.
  - nawgz 5y ago
    > The fact that you are asking and haven't hit the issue suggests you haven't actually used useRef before. Or that you are doing questionable things with it? My guess from your tone and general confusion around React is that you expect useRef to have lifecycle hooks when the `current` value changing does not have any lifecycle hooks at all, and somehow your problem with that has made you rail against these hooks. Feel free to enlighten me - I have useRef and useEffect all over my codebases, I have never used useCallback though > Sure, asshole. I've only been using React for 6 years now Your own words: "React, itself, is a mess. Always has been". That's a comical statement to make if you're not emotionally biased against a library. Especially when that library is well-organized, with strong lifecycle guarantees, and gives you the strongest out-of-the-box composability of any comparable web framework. But no, it's you that's right, React sucks and doesn't work, it's the top JS library because JS developers are idiots right? Edit: it additionally appears you downvoted my entire thread contribution, so I'm going to take it as you don't understand the point of useRef at all. :)
steve_adams_86 5y ago
I think this is a case of to each their own. I find hooks provide a far more declarative, testable, predictable developer experience. The simplicity of useEffect, useCallback, useRef, etc. makes it so I know exactly what I need to reach for when I need to accomplish certain things. It can get complex, but I find that usually means you need to back off and rethink things.

recursive 5y ago

Pretty damn thin layer? The language with its own syntax and build tools? The one with JSX? React is one of the thicker layers I've seen.

nawgz 5y ago
Oh no, JSX that compiles down to the exact set of `new Object` calls you would expect in a tree structure, how can I understand such complexity!? Really, you're kidding yourself if you think React isn't far simpler than Angular or Vue or any of these other frameworks. If you have some different direction in mind, fine, but I doubt it scales
- recursive 5y ago
  Don't misunderstand. I like JSX. However, that doesn't compel me to call it thin.
  - nawgz 5y ago
    I find that strange. For example, I would call Angular or Vue "thick" with their extra templating files and DSLs and two-way binding. I would call React thin because the JSX components you build are transparently just objects, they interact with types super gracefully because components are just classes with a method that returns nested objects, and your code is just invoking JS and producing JS until the React library itself performs the side effect of rendering. I understand that React has abstractions and a heavy scheduling engine and all sorts of complexity, but a React component - the core concept of React - reuses directly JS concepts in place of introducing its own in most situations. That is thin. I admit that if you are just thinking of libraries in general, of course a frontend framework is not "thin", but for a library which enables true composability and reuse, React is so thin compared to is competitors. Which seems a reasonable de facto context for a conversation about React.
    - recursive 5y ago
      I don't think it's thin even in that context. For example, invoking a hook comes with a bunch of rules beyond "just javascript". You shouldn't invoke a hook conditionally. You shouldn't invoke a hook in a loop. I've run into state/props mismatches due to the diff resolving differently than I thought it should. It's possible to solve this, but it further breaks the illusion of a thin layer. Maybe it's a different way of thinking, but I don't think two-way binding is inherently thicker. To me, thickness is related to the amount of "mechanism". A handlebars-type templating system seems much thinner to me.