I see :) I know that this makes sense from rendering PoV, however from developer PoV this is unexpected behavior. Many people see setCount(1) as count = 1. Being able to keep the value in sync with the updates could definitely improve DX.
Speaking of it, Im coming from Ember.js world where Glimmer tracking exactly does whats described. The memo, and the signal is changing, however the rendering is batched. I know Glimmer uses different concepts, but I think it would be still achievable in Solid.
The advantage of predictable code could have very positive impact and simplify a lot of problems.
It's interesting, to think we might be able to locally apply changes without committing them to the outside world even in this scenario. It does bring a little bit of complexity. Observing the past like React feels a lot more consistent on the other side. The problem with Async consistency/Concurrent Rendering is that outside of the processing scope you have to be witnessing the past because it hasn't happened yet..
Solid has a transition API for this which uses batching under the hood. This is probably a little bit out there unless you are super familiar with future React features.
console.log("1",signalThatTriggersAsyncFetch());// oldDatastartTransition(()=>{setSignalThatTriggersAsyncFetch(newData);console.log("2",signalThatTriggersAsyncFetch());// oldData? newData?});console.log("3",signalThatTriggersAsyncFetch());// has to be oldData;
Right now Solid will show oldData for all 3 in synchronous executation, but if we immediately updated in local scope .. we'd see:
1 oldData
2 newData
3 oldData
This is a bit confusing. Especially if something causes this transition to be cancelled and never complete. I'm not saying I can't be talked out of this behavior but it was a very safe position to take. And really only React seems to have really given this sort of thing consideration.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I see :) I know that this makes sense from rendering PoV, however from developer PoV this is unexpected behavior. Many people see
setCount(1)
ascount = 1
. Being able to keep the value in sync with the updates could definitely improve DX.Speaking of it, Im coming from Ember.js world where Glimmer tracking exactly does whats described. The memo, and the signal is changing, however the rendering is batched. I know Glimmer uses different concepts, but I think it would be still achievable in Solid.
The advantage of predictable code could have very positive impact and simplify a lot of problems.
It's interesting, to think we might be able to locally apply changes without committing them to the outside world even in this scenario. It does bring a little bit of complexity. Observing the past like React feels a lot more consistent on the other side. The problem with Async consistency/Concurrent Rendering is that outside of the processing scope you have to be witnessing the past because it hasn't happened yet..
Solid has a transition API for this which uses batching under the hood. This is probably a little bit out there unless you are super familiar with future React features.
Right now Solid will show oldData for all 3 in synchronous executation, but if we immediately updated in local scope .. we'd see:
This is a bit confusing. Especially if something causes this transition to be cancelled and never complete. I'm not saying I can't be talked out of this behavior but it was a very safe position to take. And really only React seems to have really given this sort of thing consideration.