Managing State with Signals
tonsky.me
Managing State with Signals
1–10 of 126 posts
Re: Managing State with Signals
#2The previous article in the series is also a very interesting read: https://tonsky.me/blog/humble-state/
Re: Managing State with Signals
#3It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation.
But the implementations are rarely extracted out for general purpose usage and rarely have a rich API.
I've been thinking a lot about a general purpose "epoll" which be registered on objects that change. I want to be able to register a reaction to a sequence of actions on arbitrary objects with an epoll style API.
One of my ideas is GUI thunking. The idea that every interaction with the GUI raises a new type that can be interacted with, to queue up behaviours on the GUI. This is essentially Future that are typed and the system reacts to the new type based on what you did and presents a GUI that is as if the operation you queued up was completed. (You can interact with the future because any action on something that isn't done yet, is queued up)
It's a bit like terraform plan and apply, but applied to general purpose GUIs.
For example, you can click download file, then queue up installation and then using the application, ALL BEFORE it is installed. Because the actual computation is separate from the type information that was queued up.
Imagine using AWS Console to set up an entire infrastructure and wire everything together but not actually execute anything until the very end when you click "Run".
https://github.com/samsquire/gui-thunks
I feel we are still early days with regard how to build computer user interfaces that are easy to build, maintain and understand the code for.
I used knockout and angularjs 1 and I enjoyed Knockout especially. ko.observables and the map plugin makes creating reactive code very straightforward.
Re: Managing State with Signals
#4This looks really interesting but the colour scheme makes it impossible to read.
Re: Managing State with Signals
#5This looks really interesting but the colour scheme makes it impossible to read.
Have you tried the dark mode? I thought my browser was broken when I turned it on.
Re: Managing State with Signals
#6Re: Managing State with Signals
#7It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation. But the implementations are rarely extracted out for general purpose usage and rarely have a rich API. I've been thinking a lot about a general purpose "epoll" which be registered on objects that change. I want to be able to register a reaction to a seq…
> It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation.
Angular relied on RxJS.
Re: Managing State with Signals
#8It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation. But the implementations are rarely extracted out for general purpose usage and rarely have a rich API. I've been thinking a lot about a general purpose "epoll" which be registered on objects that change. I want to be able to register a reaction to a seq…
"It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation."
This rings so true to me.
I've recently realized how every single non trivial part of my app is in fact a workflow problem : it could be ideally written as a pipe of asynchronous steps, glued together. It's true both for the frontend part and the backend.
I believe that's the point of reactive frameworks, but somehow those frameworks are usually designed around continuous streams of incoming events. Which isn't what i've noticed is the most widespread case. One-shot instanciation of pre-designed workflows would be really ideal.
Re: Managing State with Signals
#9Earlier quoted context omitted.
Have you tried the dark mode? I thought my browser was broken when I turned it on.
Wow, truly night mode. Hilarious!
Should really call it spotlight mode!
On a side note, if you do want a normal darkmode, the Darkreader extension works very well including on this site.
Re: Managing State with Signals
#10It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation. But the implementations are rarely extracted out for general purpose usage and rarely have a rich API. I've been thinking a lot about a general purpose "epoll" which be registered on objects that change. I want to be able to register a reaction to a seq…
"It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation." This rings so true to me. I've recently realized how every single non trivial part of my app is in fact a workflow problem : it could be ideally written as a pipe of asynchronous steps, glued together. It's true both for the frontend part and the back…
Thanks for this thoughtful and insightful comment.
Many problems can be workflow problems, sometimes even pulling in a rule engine, or require a job queue to do things that can fail.
Then you have software such as https://temporal.io/ which is really powerful for resilient workflows.
Imagine coordinating the user with a workflow with asynchronous data collection steps.
Imagine programming "reaction to user behaviour as a workflow engine". Can coordinate global user behaviour with a resilient workflow script.
await user.login();
if (user.showTutorial()) {
await user.tutorial();
}
await user.checkout();
await user.submitOrder();