3 ms·
Minor aside, I really dig that there is a synchronous `signal.peek()`. Common accepted dogma is that an async value is ought only be accessible asynchronously,
by rektide 4y ago
Minor aside, I really dig that there is a synchronous `signal.peek()`. Common accepted dogma is that an async value is ought only be accessible asynchronously, but having the capability to do the "you probably shouldn't" thing (getting/seeing current state synchronously) is, imo, the sort of escape hatch that adds potential & makes greatness possibility.
There's a lot of reason we let fear govern language design & direction, but I really believe we also need to give a lot of credit to what we make possible (or not) in these decisions too. For a long time, keeping async & sync separate has been the law of the land. I hope someday we can see values & their changes with less of a everything-neatly-in-one-box-or-another view, & more integratively.
- esprehn 4y agoI don't think that's a sync vs async difference in the API. peek() is related to reading the value without creating a subscription on it: https://preactjs.com/guide/v10/signals#reading-signals-without-subscribing-to-them https://preactjs.com/guide/v10/signals#reading-signals-witho... In general signals looks like a synchronous but lazy system. I don't see anything that's actually async in there?
- rektide 4y agoNot sure how you are getting this conclusion? The example code is as follows: effectCount = effectCount.peek() + 1; That is definitely absolutely clearly 100% for sure sync code. Adding a numerical value +1 to the result of a function (with no wait on it) makes it clear that .peek() here is synchronously returning a value.
- esprehn 4y agoCorrect, .value does exactly the same thing. The only difference is .value subscribes to updates. The framework is all synchronous (but sometimes lazy).