5 ms·

Svelte. Rather than const [name, setName] = useState('blastonico') ... setName('nailer') You do: let name = 'blastonico' ... name = 'nai

• efields 2y ago
  Vue is also nice.
  • nailer 2y ago
    Yep. Svelte's SFC was inspired by Vue. If you like Vue you'll like Svelte which is familiar but adds a compiler for simpler syntax.
    • spoiler 2y ago
      I honestly don't feel like Svelte makes things simpler. And I'm saying this as a "fan" of Svelte and think its compiler is very cool. It just feels a bit weird that there's special .svelte specific rules. Runes kinda fix this, but it's still a bit weird. I think Solid or Vue are much simpler (but only did small projects in them) and have a simpler mental model. I've not yet used Preact, but heard good things about it
      • sensanaty 2y ago
        Yeah I like Svelte a lot, but I can't help but feel Rich feels the need to be different, and not necessarily always in a good way. SvelteKit routing[1] is an example that pops out at me as being genuinely bafflingly bad to the point of comedy. [1] https://svelte.dev/docs/kit/routing https://svelte.dev/docs/kit/routing
• ptrwis 2y ago
  let name = $state('blastonico')
  • namrog84 2y ago
    I know some people didn't like this change. I think it works well to help make it clear and obvious to reactive vs non reaction changes.
• phailhaus 2y ago
  `setName` makes sure that state changes are queued up for the next render, allowing you to treat all state and props as constant within the current render. If you are just assigning variables directly, then your state is changing within the same render cycle, which can lead to all sorts of nasty bugs that are difficult to replicate. I get that assigning variables is easier to understand, but it's way, way harder to actually scale and maintain. Check out flux architecture.
  • ww520 2y ago
    Just curious. How does that work on changes between depending states within a cycle? E.g. [foo, setFoo] = useState(1); [bar, setBar] = useState(); setFoo(10); setBar(foo * 2); // Is bar 2 or 20 at this point?
    • aidos 2y ago
      It’s 2. We’re just running a js function here with nothing magical going on. It might seem that there’s a chance that people will be confused about what bar is, but in practice all the changes are happening in handlers and bar will be a const anyway so you have no plans to mutate it directly.
      • ww520 2y ago
        Thanks for the clarification. I'm trying to understand the rationals behind React's design decision. Why state changes within the same render cycle would lead to all sorts of bugs? And why is it not a problem with other frameworks like Vue or Svelte? Just a follow up. If foo and bar are expected to be constant in the rendering code, what's the point of the setXXX() functions? Why not just make them constant explicitly and say mutating them elsewhere like in the handlers/controllers?
        • phailhaus 2y ago
          If you have state changes within your render cycle, then you can't write pure functions anymore, you have a stateful class. And if you have a stateful class, then React can't control when you render, because it can't know when you update a variable. So the onus is on you to decide when your component needs to re-render. This is extremely easy to screw up. You will end up in scenarios where the UI does not match the underlying state, just because the two have gone out of sync. React inverts the MVC paradigm and says "no, you don't get to decide when to render." So if you want to update state, React will manage that for you and queue up the render. With React, your UI and state literally cannot go out of sync (except for refs), and all the data dependencies are managed for you. Facebook gave a great talk on Flux architecture vs MVC ten years ago that you should check out here: https://www.youtube.com/watch?v=nYkdrAPrdcw https://www.youtube.com/watch?v=nYkdrAPrdcw > what's the point of the setXXX() functions? Why not just make them constant explicitly Look at the code again: it is explicitly constant! `const [myState, setMyState] = useState(0)`. `myState` is a const, and will literally not change its value for the entire render cycle. There is no mutable state to manage, no race conditions. You just tell React what to render based on what the value is now, and React injects the current value for you. The first time, `myState` is 0 since that's the initial value. Every subsequent render, React will give you the latest value. You can pretend everything is constant, because it is.
• lucsky 2y ago
  Overriding standard language constructs with magic behaviors is a giant no-no and a recipe for disaster.