5 ms·

The thing is that While react is against side effects, javascript is not. Which result in these impedance mismatch where what devs want is against react itself.

by rk06 5y ago

The thing is that While react is against side effects, javascript is not. Which result in these impedance mismatch where what devs want is against react itself. Vue/svelte/solid do not fight against js, hence they do not end up in similar situation

riwsky 5y ago
React lets you build DOM with normal JavaScript loops and .map; solid requires its own For element. How do you define “does not fight against js”? Because the above feels likes solid fighting against js.
- benatkin 5y ago
  Don't forget about having to pass key to each element in React. The simplicity of using map() is an illusion. SolidJS splits it between <For> and <Index>. <For> is equivalent to passing the object as the key and <Index> is equivalent to passing the index as the key. https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_index https://www.solidjs.com/tutorial/flow_index
  - ihateolives 5y ago
    > Don't forget about having to pass key to each element in React. The simplicity of using map() is an illusion. That's one of the design decisions I don't fully understand. It knows that there should be a key there so why just not put it there silently and let me override it when I need, instead of screaming at me when I omit it.
    - yazaddaruvala 5y ago
      It’s a performance pitfall. The warning is trying to make sure the dev correctly tells it how to and when not to re-render. Could it silence the warning? Yes. However, the React devs choose not to. I think it’s the correct default, but likely needs a more educational warning message.
    - wonnage 5y ago
      The purpose is well-documented here: https://reactjs.org/docs/reconciliation.html#recursing-on-children https://reactjs.org/docs/reconciliation.html#recursing-on-ch... And it also goes into why index is a poor key (it's basically the same behavior as with no key). Using object identity to detect inserts doesn't work either, because the map function is returning new React element objects on each render. Practically speaking if you know your items won't change, then omitting the key or using index is fine.
      - benatkin 5y ago
        So SolidJS has this solved elegantly? It lets you choose between object identity and index, and it doesn't have that caveat for object identity because it knows what's going into <For> and not just what's coming out of it. Don't omit the key in React unless you want warnings.
      - ihateolives 5y ago
        I know, I've read it. I'm still not convinced. React could just as well generate and insert missing key on build instead of asking me to do this: ... you can add a new ID property to your model or hash some parts of the content to generate a key. It is just plain wrong to ask me to change my data model because of this. This is part of the housekeeping that I expect the framework -- pardon, library -- to take care of for me.
        ryansolid 5y ago
        It can't. Not in a consistent manner. When diffing user provided immutable data you need a user provided key. Otherwise it can't tell the difference between a new list entry and a nested update. You could treat every nested update as a new item but that is incredibly wasteful as it throws away all descendants. This is something all non-fine-grained rendering libraries have to deal with be it React, Vue, Svelte, or Lit.
        mwcampbell 5y ago
        How does Solid avoid the need for user-provided keys? I thought it also had to diff the underlying array. Does it check object identity?
- peferron 5y ago
  Fully agree. With React, "plain JS" works just like I expect it to. If I have an event handler that does `x = foo` then I don't expect my component to re-render. Why should it? I'm just changing the value of a local variable. If I want to re-render, there's no way to express that in plain JS, so I'll use React's API and write `setX(foo)` instead. Now it's clear that it's not just changing the value of a local variable, but using React's API to do something else. With Svelte, writing `x = foo` doesn't just change the value of a local variable. Maybe it's going to run a bunch of magic to update a piece of the DOM instead. Or maybe I need to prefix it with `$: ` which in plain JS is a label for a continue or break statement, but here doesn't mean that at all and means reactivity instead. Oh, and to conditionally render an element, instead of writing idiomatic JS like `condition && <Element />`, I now have to write `{#if condition} <Element /> {/if}`. WTF. What looks like plain JS is now magic, and what should look like plain JS such as conditional rendering and lists are now some contrived templating constructs. And almost everyone here is telling me that I should find that simpler somehow. It makes zero sense.
  - egeozcan 5y ago
    Sorry for the "+1" chain but I want to express my agreement as well. Especially when I compare it to Svelte and Vue (not solid, solid.js is just... good), if I look at a component, with react it's way easier to say what's going to happen. Aren't there gotchas? Yes, but sometimes it's just stuff JS lacks, and so does React. I'm very excited about Records and Tuples in JS to help with the immutability, for example: https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple
intrnl 5y ago
i'm finding a hard time articulating what you said, if React is against side effects then useEffect wouldn't have existed and we wouldn't have data fetching. React is unique in that everything in the component is within the render path, while the rest of the frameworks (that you've mentioned) doesn't. you might be mistaking "side effects during render is bad" for "side effects is bad", the two statements are not the same.
- rk06 5y ago
  I mean side effects from a functional point of view. Let me explain in more details React’s philosophy is View = F(data) I.e. view is a pure function of data. By “pure”, we mean F() does not do console.log, ajax calls, date time and other stuff which is not consistent every where. This assumption is ingrained in React. You see it when you are told that react can overrender and your code should handle overrendering. And react works well when user code is pure. However, real world does not work that way. So, there is a need to handle side effects, so that “side effects” works well with pure function assumption of react. This “handling of side effects” is the over head introduced by react. Other js frameworks (svelte, solid, vue) do not assume full immutability or pure functions, hence User code does not need special handling for these cases
  - benatkin 5y ago
    > View = F(data) That's just how templates are meant to work. Underscore.js templates don't allow making an AJAX call before calling render() either. https://underscorejs.org/#template https://underscorejs.org/#template
    - rk06 5y ago
      Consider following scenario: User is entering an account register form. When the user has entered a value in nickname, your app must check if it is in use and display error message if the nickname is already in use. Sounds good, and ubiquitous right? Well, that also require an ajax call to server for validation, so it breaks the pure function assumption right there. Now, you what do you do?

by rk06 5y ago

riwsky 5y ago

React lets you build DOM with normal JavaScript loops and .map; solid requires its own For element. How do you define “does not fight against js”? Because the above feels likes solid fighting against js.

benatkin 5y ago
Don't forget about having to pass key to each element in React. The simplicity of using map() is an illusion. SolidJS splits it between <For> and <Index>. <For> is equivalent to passing the object as the key and <Index> is equivalent to passing the index as the key. https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_index https://www.solidjs.com/tutorial/flow_index
- ihateolives 5y ago
  > Don't forget about having to pass key to each element in React. The simplicity of using map() is an illusion. That's one of the design decisions I don't fully understand. It knows that there should be a key there so why just not put it there silently and let me override it when I need, instead of screaming at me when I omit it.
  - yazaddaruvala 5y ago
    It’s a performance pitfall. The warning is trying to make sure the dev correctly tells it how to and when not to re-render. Could it silence the warning? Yes. However, the React devs choose not to. I think it’s the correct default, but likely needs a more educational warning message.
  - wonnage 5y ago
    The purpose is well-documented here: https://reactjs.org/docs/reconciliation.html#recursing-on-children https://reactjs.org/docs/reconciliation.html#recursing-on-ch... And it also goes into why index is a poor key (it's basically the same behavior as with no key). Using object identity to detect inserts doesn't work either, because the map function is returning new React element objects on each render. Practically speaking if you know your items won't change, then omitting the key or using index is fine.
    - benatkin 5y ago
      So SolidJS has this solved elegantly? It lets you choose between object identity and index, and it doesn't have that caveat for object identity because it knows what's going into <For> and not just what's coming out of it. Don't omit the key in React unless you want warnings.
    - ihateolives 5y ago
      I know, I've read it. I'm still not convinced. React could just as well generate and insert missing key on build instead of asking me to do this: ... you can add a new ID property to your model or hash some parts of the content to generate a key. It is just plain wrong to ask me to change my data model because of this. This is part of the housekeeping that I expect the framework -- pardon, library -- to take care of for me.
      - ryansolid 5y ago
        It can't. Not in a consistent manner. When diffing user provided immutable data you need a user provided key. Otherwise it can't tell the difference between a new list entry and a nested update. You could treat every nested update as a new item but that is incredibly wasteful as it throws away all descendants. This is something all non-fine-grained rendering libraries have to deal with be it React, Vue, Svelte, or Lit.
        mwcampbell 5y ago
        How does Solid avoid the need for user-provided keys? I thought it also had to diff the underlying array. Does it check object identity?
peferron 5y ago
Fully agree. With React, "plain JS" works just like I expect it to. If I have an event handler that does `x = foo` then I don't expect my component to re-render. Why should it? I'm just changing the value of a local variable. If I want to re-render, there's no way to express that in plain JS, so I'll use React's API and write `setX(foo)` instead. Now it's clear that it's not just changing the value of a local variable, but using React's API to do something else. With Svelte, writing `x = foo` doesn't just change the value of a local variable. Maybe it's going to run a bunch of magic to update a piece of the DOM instead. Or maybe I need to prefix it with `$: ` which in plain JS is a label for a continue or break statement, but here doesn't mean that at all and means reactivity instead. Oh, and to conditionally render an element, instead of writing idiomatic JS like `condition && <Element />`, I now have to write `{#if condition} <Element /> {/if}`. WTF. What looks like plain JS is now magic, and what should look like plain JS such as conditional rendering and lists are now some contrived templating constructs. And almost everyone here is telling me that I should find that simpler somehow. It makes zero sense.
- egeozcan 5y ago
  Sorry for the "+1" chain but I want to express my agreement as well. Especially when I compare it to Svelte and Vue (not solid, solid.js is just... good), if I look at a component, with react it's way easier to say what's going to happen. Aren't there gotchas? Yes, but sometimes it's just stuff JS lacks, and so does React. I'm very excited about Records and Tuples in JS to help with the immutability, for example: https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple

intrnl 5y ago

i'm finding a hard time articulating what you said, if React is against side effects then useEffect wouldn't have existed and we wouldn't have data fetching. React is unique in that everything in the component is within the render path, while the rest of the frameworks (that you've mentioned) doesn't. you might be mistaking "side effects during render is bad" for "side effects is bad", the two statements are not the same.

rk06 5y ago
I mean side effects from a functional point of view. Let me explain in more details React’s philosophy is View = F(data) I.e. view is a pure function of data. By “pure”, we mean F() does not do console.log, ajax calls, date time and other stuff which is not consistent every where. This assumption is ingrained in React. You see it when you are told that react can overrender and your code should handle overrendering. And react works well when user code is pure. However, real world does not work that way. So, there is a need to handle side effects, so that “side effects” works well with pure function assumption of react. This “handling of side effects” is the over head introduced by react. Other js frameworks (svelte, solid, vue) do not assume full immutability or pure functions, hence User code does not need special handling for these cases
- benatkin 5y ago
  > View = F(data) That's just how templates are meant to work. Underscore.js templates don't allow making an AJAX call before calling render() either. https://underscorejs.org/#template https://underscorejs.org/#template
  - rk06 5y ago
    Consider following scenario: User is entering an account register form. When the user has entered a value in nickname, your app must check if it is in use and display error message if the nickname is already in use. Sounds good, and ubiquitous right? Well, that also require an ajax call to server for validation, so it breaks the pure function assumption right there. Now, you what do you do?