Replies: 3 comments 11 replies
-
|
Related discussions I opened: #116, #70 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
You might want to add "doesn't trigger onRecoverableError" which is a new type of callback to catch deopts and bad cases. For example imagine this case: function Parent() {
let someData = useSomeThingExternal(...);
if (someData === null) {
return someData;
}
}
function Child() {
let [show, setState] = useState(false);
function onClick() {
setState(true); // sync update
}
if (show) {
return <GrandChild />;
}
}
function GrandChild() {
let someData = useSomeThingExternal(...);
if (someData === null) {
throw new Error('did not expect to render null');
}
...
}function removeThing() {
myStore.value = null;
startTransition(() => update());
}At the same time the onClick happens. The issue is when a new thing, that shouldn't have been rendered at all, ends up showing up due to a sync update. React has some recovery in place to deal with this but it's a deopt and triggers "onRecoverableError". Hydration is another dimension to consider. |
Beta Was this translation helpful? Give feedback.
-
|
From prior discussions with Andrew, my understanding is that you can't really make use of external state libraries and transitions. That seemed to be the stated limitation of |
Beta Was this translation helpful? Give feedback.
-
|
Honestly, this feels like a pretty major impedance mismatch, and it's one of the reasons why external state stores exist in the first place.
Like, this borders on being a version of the classic "we want you to draw red lines with blue ink" sketch. From my perspective: context propagation improvements and context selectors are something the community has been eagerly awaiting for years, and I can't wait for those to be released. At the same time, that does nothing to address the other reasons why people use external state stores. It doesn't give you Redux's middleware or DevTools, Mobx's computed values and dependency tracking, etc. While I totally get the reasons why external state can't be handled the same way by React at the technical level, at the same time do I worry that we're sort of heading towards an example of the " |
Beta Was this translation helpful? Give feedback.
-
|
One argument I hear for not having the state in React is simply to decouple it from React so that you're not tying yourself to React. That was an easy thing to get for free before but is no longer for free. So I wonder how much of that is actually the value vs just something theoretical. (Like building on a DB agnostic ORM but then in practice you can't ever change the DB until you do a major rewrite anyway.) There's a version of "external" state where we could provide a "React store" that could be rooted externally. Like its lifetime lives in an external store but it's current value is managed by React. It's a React built-in feature. Very likely it might also be coupled to a single React root and can't be used outside of it by other React roots. If it had the ability to do middleware, DevTools, dependency tracking etc. would it still be a deal breaker that it was tied to React? I don't know how to get all of it at once in the issue. This obviously wouldn't work with interop to built-in things like the "subscribing to mediaqueries" use case which would still have to useSyncExternalStore. |
Beta Was this translation helpful? Give feedback.
-
How it would be different from? const [state, setState] = useState(store.getState)
useEffect(() => {
return store.subscribe(setState)
}, [])
return <StateProvider value={state}>{children}</StateProvider>I get that with a builtin API we wouldn't have to perhaps maintain a manual subscription, we wouldn't have to propagate the change manually through a provider etc. But those are somewhat implementation details - my question is though: how different this would be on a fundamental level? I guess this kinda just resurfaces my question from my previous post but since that has not been answered directly - so I'm trying again. |
Beta Was this translation helpful? Give feedback.
-
|
The main thing is that it would maintain multiple versions of the state at once and React would know which one to read. So instead of one mutable fields it would contain multiple mutable fields. To more directly answer your original question. The problem generally only occurs when you render a new component, that accesses a value that was mutated in the store as part of the same "transaction" (conceptual or actual) as was updated in a different transition. For example, if my store contains However, we then get a synchronous update (or something like a hover) that renders a new component. That component tries to read If instead it was like |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if I follow or if we are simply not on the same page. In my previous code snippet, I'm showcasing the classic propagation of state through context. So if we use that with your example then React only ever sees Here we don't allow arbitrary reads through manual subscriptions, we just immediately pass a state value to React, through state and context. Therefore it feels like React should be able to make as many copies of that state as it needs. |
Beta Was this translation helpful? Give feedback.
-
|
WARNING DEEP DIVE BELOW Where is this all going? This isn't just a React thing, it's the same as how in Rust for something to be thread-safe it has to comply to the Send and Sync protocols. If you pass something to like a multi-threaded HTTP server in Rust, that data has to be Send and Sync compatible - which basically means deep immutable or at least transferring ownership of a single copy of it. There are many features that concurrency enables but the final frontier is to allow for true parallel rendering across multiple cores once the runtimes we run in allows it. This means that everything in render have to be "thread safe" at a minimum - in other words it has to be Send/Sync. This doesn't necessarily mean that they have to be fully immutable. For example you can use a Mutex. A Mutex in Rust (or C++) is not very idiomatic. It is a complicated thing to work with. You have to deal with possible "poisoning" and deadlocks. Once you enter this world, you're in "advanced mode". However, it is possible with a Mutex to have mutable data that is also thread-safe. However, just because the data is thread-safe doesn't mean that it's logically consistent. If you read the same or related data at two different times, it might yield logically inconsistent results. This is the same as if you read from a database twice outside a transaction. That might then cause an error path because it's logically inconsistent (even though it's memory safe), which then needs recovery. E.g. sometimes transactions solve this by reexecuting which is also what we do, which is why things mostly work anyway. It has a tradeoff between using a Mutex and the risk that you sometimes has to double the work under the wrong condition. Sometimes you have to resolve the conflict by blocking the main thread. Mostly this will only affect performance though. That's the tradeoff. That's the computer science stuff that underpins all these annoying things. It's not something we made up. If you want to deep dive, I'd recommend just learning concurrent Rust. However, there is also one small thing that we did "make up". In addition to those things, what can happen is that if you use synchronous rendering |
Beta Was this translation helpful? Give feedback.
-
according to this article by @dai-shi it's still spotty: https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-rendering
what are the steps that react-redux recoil zustand et al, whose state is outside of react, have to take in order to opt into startTransitions?
Test scenario
Results
Raw Output
Beta Was this translation helpful? Give feedback.
All reactions