Hacker News Reader

Comment by danielvaughn | Hacker News Reader

Agreed. Last year, for instance, I tried Svelte. I had a great time for a while, everything was fairly simple...but then I hit a specific scenario. I can't recall what it was, but it led to me digging as deep as I could into their docs to try and understand how Svelte was doing that whole $ thing. I nearly melted my brain trying to understand it.

That's not to say hooks are much better, but I find the overall mental model to be fairly simple to understand, and I don't often find myself bumping up against React's edges.

View on HN

I believe you're referring to $ not being fired when another $ below it updates the variable the first $ subscribes to. This is an expected behavior. In Svelte the order of $ matters to prevent infinite loops.

In this example the second $ won't trigger the first $:

    let a = 1;
    let b = 1;
    
    $: if (a > 0) { b += 1 }

    $: if (b > 0) { a += 1 }

With React's useEffect one can easily falls into the trap of an infinite re-rendering:

    let a = 1;
    let b = 1;
    
    useEffect(() => {
        b += 1;
    }, [a]);
    
    useEffect(() => {
        a += 1;
    }, [b]);

Great framework are supposed to prevent this kind of loophole.

I haven't done much playing around with Svelte so don't have any business injecting myself into this subthread, but your explanation piqued my curiosity.

https://github.com/sveltejs/svelte/issues/6730

https://github.com/sveltejs/svelte/issues/6732

So basically, reactive blocks are only allowed to run once per tick; if a dependency changes after a block has run, too bad, the block won't run again. That is really shocking to me. (I won't say more due to my inexperience with Svelte...)

This is all triggering my memory, I had forgotten how it actually worked so couldn't explain the issue I was having. But it was related to this exact behavior. I found it so unintuitive and difficult to grasp that I literally abandoned the project and decided to build it from scratch in React.

It's a shame because it's an otherwise lovely framework.

What happens if you do want effects to update each other's dependencies, but only conditionally? eg. A certain number of cascading updates?

Novice react developers reach for useEffect way too often, because they are still thinking in terms of state transitions instead of declarative states. I have spent a lot of time teaching people not to do that. They always end up very happy once they get it, because now they can build complex UIs and have a solid strategy for compartmentalization, which makes bug whack-a-mole go away.

It's not a fault in the framework, it's a fault in their understanding, where they don't know how to implement features in O(N) lines of code instead of O(N^2).

The hint is in the name: you're supposed to think in terms of formal functional Effects that mount and unmount independently and compose orthogonally.

The result will be a code base that remains maintainable even though you've kept on adding more nuanced features over months and months.

Also, your snippet doesn't cause an infinite loop at all because modifying local variables does not trigger a rerender. If you had written setA / setB, sure, it would... but I think this perfectly illustrates the explicit vs implicit distinction.

Great frameworks don't trap developers in local maxima.

> because they are still thinking in terms of state transitions instead of declarative states

Do you have any links where I could read more about this? Or examples?

I think what you are describing looks a lot like what the Svelte team is trying to achieve with the reactive assignments "$:"

A couple years ago, that feature used to work similar as useEffect, so I got used to use it for transitions, and now is biting my ass because the Svelte team are breaking my transition use-cases

$ has a looot of gotchas, under some conditions, the reactivity climps up the dependency tree. E.g. https://github.com/sveltejs/svelte/issues/4933

I used to use "$" like useEffect, but now I don't know how to use it anymore

And Svelte still bites my intuitions when dealing with complex objects, most of the times I've manage solve it by separating the code into multiple components, but it's not clear why that happens

I think there’s a strong argument to be made here that the actual code in this scenario is flawed.

What Svelte is doing is simply covering up the flaws in your code by short circuiting an infinite loop scenario which has been coded into your app. This will have unexpected side effects, however.

That being said, I think useEffects is far too overloaded in React, and is currently used for completely orthogonal purposes.

At he very least it’s used for the following completely unrelated purposes.

1. Component setup and graceful dismantling. 2. Syncing with external state. 3. Running code specific to a certain prop being changed.

I think the React team would be highly justified if they created a separate hook for #3 at least. Maybe a usePropsChanged hook that is called when one of the props change, and provides an isChanged function that you can pass a prop to, to check if it’s actually changed (I’m sure someone can come up with a better design than I have in the process of writing this comment).

That would be a semantic which would actually allow you to avoid the code flaw that your code above includes, as opposed to brute force papering it over like Svelte appears to do.

Hooks are much better. The only problem with hooks is that people don't get them. But once you get them, every other approach looks like a complicated pile of shit.

I think the dev community does really poorly with these kinds of abstractions that are very simple but completely unintuitive.

I place a lot of the blame on the React team too. When hooks came out, their docs were absolutely terrible. They probably still are. They were full of shitty editorialising like "we created hooks because we found classes were too difficult for people to understand!", which made every dev I worked with feel insecure for not immediately knowing how to write super awesome clean code.

I'm a big fan of hooks, but I'm still not completely sold on them. I like code that reads in logical sequence, like you're telling a story. When you use `useEffect` to coordinate side effects from prop changes, it makes me feel like I'm reading a story written by Quentin Tarantino.

That being said, it's a relatively small complaint.

>I'm a big fan of hooks, but I'm still not completely sold on them. I like code that reads in logical sequence, like you're telling a story. When you use `useEffect` to coordinate side effects from prop changes, it makes me feel like I'm reading a story written by Quentin Tarantino.

I actually read this as a compliment considering Tarantino himself spoke in an interview about how his non-linear storytelling style comes from the way novels he'd read were written.

> The only problem with hooks is that people don't get them. But once you get them, every other approach looks like a complicated pile of shit.

No, some people actually get them and there are way much better alternatives[1].

1. http://intelligiblebabble.com/compose-from-first-principles/

That's the thing about react, there basically are no edges or very very few edges left. There were edges in like 2018, but the team has made it relatively easy to do anything you want to do, while writing scalable and maintainable code.

Reply on news.ycombinator.com