by samhuk on 8/12/23, 12:44 PM with 1 comments
by samhuk on 8/12/23, 12:44 PM
Not-so-TL;DR:
I posted a little (awful quality) GIF preview of it's chat app example here [0].
The more detailed motivation of this is that typical Javascript build toolchains that I've seen and used all have this tendency to use multiple watchers for code builds and app process(es), using tools like concurrency [1]. These often end up plagued with race conditions and funky workarounds like debouncing.
Ever noticed when you make file changes and your app/whatever restarts a zillion times or doesn't properly restart? That's the issue Sock State was originally made to solve! Example:
Process #1: Build watch process starts, rebuilding some source code when file(s) change.
Process #2: App watch process starts, restarting when output file(s) change.
Typical flow: Source code change occurs --> #1 triggers build --> output file(s) gradually created --> #2 triggers app restart
Common issues with that:
1. Multiple debounces often required
2. Multiple file system watchers
3. App process(es) have no idea when builds start/fail
So I created Sock State for some side-projects that have particularly complex build processes in order to ensure that:
1. Build processes can publish their status updates to a centralized state store
2. Other processes can subscribe to changes of, restarting at the exact correct time, once, with no workarounds or other weird goofiness.
It's now turned into a bit more than just a glorified build status message bus, and perhaps can be something a bit more in the future.
[0] https://twitter.com/thesamhuk/status/1690318953594114048?s=2...