4 ms·

> The library should be doing more than rendering twice to protect developers from side effects Like what?

bryanrasmussen 2y ago
probably the parent poster does not use React so it would seem a heavy demand on a human to make, given the already stated limited cognitive energy and time. I suppose I would think not rendering twice and some sort of warning about side effects would be beneficial, rendering twice means that you get a misleading view of what your application behavior is, I can see how people would - from an architectural perspective - consider it bad without necessarily using the framework.
- kaoD 2y ago
  > some sort of warning about side effects would be beneficial Rendering twice is exactly what allows you to detect that. How would you detect a side effect if not by calling the function twice? React's contract is that your component should be allowed to render twice without any changes so this is just upholding the invariant in dev mode.
  - spion 2y ago
    You can use a language / compiler / static analyzer that restricts side-effects.
    - kaoD 2y ago
      Funny you mention that https://react.dev/learn/react-compiler https://react.dev/learn/react-compiler
      - deleted 2y ago
        [deleted]
- hu3 2y ago
  I do also use React, unfortunately.
  - bryanrasmussen 2y ago
    my mistake, I feel your pain.
hu3 2y ago
If you have to ask. Learn Elm and you'll see React's shortcomings clearer. They don't render twice but that is just the tip of the iceberg. Be warned though, exiting the cave is painful.
- jemmyw 2y ago
  I've used elm. It's not that great. In many ways it has the same shortcomings as react but far worse. That is you find yourself wanting to do something as yet unsupported (which we often do because otherwise why write new software in the first place) you have to break out of it's abstraction. Except doing so is 10x harder with elm, and the community around it is so much smaller you can't find the answers. Also, after I personally had moved on, there was something of a tension between the community and the authors. Maybe that's resolved, although I'd suspect for some the resolution was to no longer be part of it.
Daishiman 2y ago
Things like validating or limiting possible React code you can write such that these effects are impossible, in the same manner that abstract data types in programming languages attempt to define data structures that are correct by construction, or the same way that reactive programming enforces a programming paradigm that attempts to minimize unwanted interaction glitches.

probably the parent poster does not use React so it would seem a heavy demand on a human to make, given the already stated limited cognitive energy and time. I suppose I would think not rendering twice and some sort of warning about side effects would be beneficial, rendering twice means that you get a misleading view of what your application behavior is, I can see how people would - from an architectural perspective - consider it bad without necessarily using the framework.

kaoD 2y ago
> some sort of warning about side effects would be beneficial Rendering twice is exactly what allows you to detect that. How would you detect a side effect if not by calling the function twice? React's contract is that your component should be allowed to render twice without any changes so this is just upholding the invariant in dev mode.
- spion 2y ago
  You can use a language / compiler / static analyzer that restricts side-effects.
  - kaoD 2y ago
    Funny you mention that https://react.dev/learn/react-compiler https://react.dev/learn/react-compiler
    - deleted 2y ago
      [deleted]
hu3 2y ago
I do also use React, unfortunately.
- bryanrasmussen 2y ago
  my mistake, I feel your pain.

hu3 2y ago

If you have to ask. Learn Elm and you'll see React's shortcomings clearer. They don't render twice but that is just the tip of the iceberg. Be warned though, exiting the cave is painful.

jemmyw 2y ago
I've used elm. It's not that great. In many ways it has the same shortcomings as react but far worse. That is you find yourself wanting to do something as yet unsupported (which we often do because otherwise why write new software in the first place) you have to break out of it's abstraction. Except doing so is 10x harder with elm, and the community around it is so much smaller you can't find the answers. Also, after I personally had moved on, there was something of a tension between the community and the authors. Maybe that's resolved, although I'd suspect for some the resolution was to no longer be part of it.

Daishiman 2y ago

Things like validating or limiting possible React code you can write such that these effects are impossible, in the same manner that abstract data types in programming languages attempt to define data structures that are correct by construction, or the same way that reactive programming enforces a programming paradigm that attempts to minimize unwanted interaction glitches.