Комментарии:
Code has to mutate sooner or later. The only constant in life is change. The main thing is to be in control of the changes.
Ответитьso tl dr?
(I have my attention span f up)
The ”mutable.count ++” vs ”setState(prev => prev + 1)” is a very unfair way of comparing immutability vs mutability.
setState is React's magic, not functional programming per-say.
```
const changed = {
…immutable,
count: immutable.count + 1
}
```
Is a much more fair representation.
That being said Javascript doesn't have persistant data structures built in so it's more performant to just mutate.. sadly 😕
Honestly I've come to feel that the frontend framework choice has way less of an impact than the other decisions of the app. For all the shit it gets, react is pretty great, I'd take it over the chaos of JQuery any day. I work out of react because I love remix right now, I can imagine switching over to solid / preact eventually, probably not svelte because I'm not a huge fan of compiler magic-ey things.
ОтветитьYou should check valtio state management, since were talking about proxy. Valtio use proxy behind the scene
Ответитьin React everything is a state , useState and UseReducer are asynchronous.Other state changing is synchronous. You can take advantage of that.With proxy you can accumulate data without any render , use this fresh data in event handlers for example and rerender when your condition is satisfied.
ОтветитьWhat extension shows the TS errors inline?
EDIT: never mind, just found it in the description. Error lens
I am having a very hard time trying to recreate your app without the MVC approach… I am stuck and the MVC approach is so hard for me to understand and follow.
ОтветитьVery good on proxies. Please, never do this in prod. React is immutable by design, better use util libraries for better usability
ОтветитьThis guy is skyrocketing my knowledge in software engineering…
ОтветитьYou inspire me to write better code lol
ОтветитьImmutable code has been consistently easier for me to work with and test across the board at scale, especially if you're dealing with any kind of concurrency. The benefits for me have been far from small and pretty much the only times I bother with mutable approaches is when there are specific performance considerations I need to contend with. I actually started with mostly mutable code professionally, but got tired of tracking down side effects across the application and worrying about breaking something if I changed a value. For me, there's no real going back to preferring mutable code except for certain edge cases.
ОтветитьMutable code bugs are so hard to find, i seriously advise viewers to not start mutating objects after after watching this. Thanks for the proxy info though.
ОтветитьIt's true that immutable data helps prevent bugs, but the benefit is very small. It's not as big of a benefit as it is touted to be. I think the bigger driving force behind React choosing to use immutable state is because companies like FB collect advanced analytics from it. I imagine that is very valuable data for them. For the average developer, this probably isn't something we will ever use. So it is kind of funny that the majority of react devs are doing this extra busy work for a benefit they we don't even use.
ОтветитьI think part of the issue with React is that the immutability is so on the nose. For example setState; why is it designed in a way where you have to return copies every time when that's already what it's supposed to do? Why does it not already give you a value copy of the current state that you can modify and return? It's just a bunch of busywork.
ОтветитьAs far as I'm aware, every JS framework uses proxies to a lesser or greater extent. I use them in the projects I work on frequently as well. They are convenient basically for the simple reason that you can listen to changes, you can validate data, you can send update requests to a backend or localStorage/sessionStorage, etc. It's an incredibly powerful tool.
ОтветитьVue 3 uses Proxy for reactive object ex: const reactiveData = reactive({ foo: "bar"});
When dealing with plain refs ex: const foo = ref("bar"), Vue 3 uses object getters and setters.
Vue 2 used only getters and setters due to browser support limitations at the time.
Have you looked into valtio? It's a state management library that is front end/framework agnostic. Also uses the proxy pattern to get and set state like this.
ОтветитьGood job babe!
Ответить"I don't know man.." "I was talking about..." "and then I went on a rant..."
My life on 3 sentences.