Hacker News new | ask | show | jobs
by SinParadise 1017 days ago
Not useEffect specifically, but wiring something very stateful like a map library into the React rendering paradigm while keeping the state management in React via useState etc. can be very difficult to do so in a performant way.

I recalling using a lot of useRef to manually tune when to re-render, and in an ideal world I shouldn't be this granular about it.

You can certainly use one of the many React map wrapper libraries to lessen the pain, the pain is still very real, just dealt with by someone else.

2 comments

But what’s better? In the end you need control over stuff, it’s almost like people want frontend to be magically easy but unfortunately there’s just the reality that either you have high abstraction but less control, or low abstraction and more control (more code, more gotchas, etc) until you get a smart optimizing compiler ofc.

Hooks imo are great, as they are pretty explicit and low level.

Nowadays signals are the new kid on the block, though mobx and similar have existed since forever in react land, but they have their own crazy edge cases like reactive loops and implicit behavior.

I like Svelte. It embraces the fact that UI is stateful and doesn't try to pretend it isn't.
I do too, I made this [0] 3 years before Svelte existed. But I don't think the "pretend it isn't" makes any sense, I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones.

[0] https://www.youtube.com/watch?v=HHTYHm6qLFY&t=11s

Thats a cool project.

>But I don't think the "pretend it isn't" makes any sense

Well, let me expand a bit more. React's pitch is that view is a function of state, and essentially designed around the idea of an immutable state which re-renders everything when changed. It then offered some APIs to allow fine-tuning of rendering via hooks which either ties with data changes or some rendering life-cycle. To me the API screams of stubborn refusal to let go of the "view as a function of state" mantra: When you encounter a scenario where it breaks the mantra, lets add another lever to handle it. This lever also has to be pulled by you the developer, and it is up to you to know when to do it.

>I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones.

I don't really have an issue with compilers. They are the accepted magic that bridges between language for people and language for machines. The ideal language might be something that is functional and immutable language that it is easy for us to read, but compiles to the optimized, imperative updates that machine can run well.

I'd probably like React better if it had a compile layer on top of its more functional parts?

As for templates, JSX is probably the one great thing that came out of React. It is no wonder that many other frameworks are embracing JSX, but none of them are really forking the idea of hooks.

I don't think React ever pitched view as a function of state actually. Many in the community latched onto that, and some React-inspired projects tried to make that a thing, but I'm positive that was never the pitch from the core team, in fact very certain of this.

Lifecycles existed since the first version, and they were always absolutely critical. Hooks just fixed many of their issues and made them more elegant, composable, and simple to write.

>I don't think React ever pitched view as a function of state actually. Many in the community latched onto that, and some React-inspired projects tried to make that a thing, but I'm positive that was never the pitch from the core team, in fact very certain of this.

If it quacks like a duck..

> and in an ideal world I shouldn't be this granular about it

Hm, could you give an example of this ideal performant state management world? Angular? Vue? Svelte? MobX?

Svelte is a good example. But you don't have to go that far; Solid and Preact have signals with auto-tracked dependencies.

As another commenter mentioned, yes it's less low level than managing your own dependencies, but then again, most React apps are already wrapped in layers and layers of abstractions/context providers/selectors and use Jest as their test runner (which injects the global namespace with functions) and does other black magic and weird metaprogramming, so I think most React devs are already OK with less lower level stuff.

I'm a bit surprised the poster was asking for something more magic not less.
I mean, I am OK with magic, but it has to remain magical to me. The moment I have to deal with the magic, I don't want it anymore.