Off-topic, but but it’s getting very hard to keep track of things or know what I’m reading about with constant name churn and re-use of late. I’ve been in this game a lot longer than most, so to me:
I can go on and on with this, but it’s almost to the point where I have no idea what anyone is talking about without additional context since so many of the same names are used over and over and over again for completely different things.
Edit: I might add that as a Gopher partisan (the protocol than runs on port 70), seeing things like GopherCon and the general reappropriation of the “gopher” term to relate to the Go language rather than the Gopher protocol extremely mind-jarring.
Another one from recent lobste.rs headlines that got me :
Idris is a real-time UNIX operating system, not a functional programming language.
So I think I just comprehended something about Redux/Vuex and the like: They are the front-end version of a time series (see below) database, but without persistence, and in JS rather than on server side tech, and they proxy in front of actually persistent stores. That’s why they are singletons in the vast majority of cases (because the last thing a JS frontend needs is to be running a consensus protocol between the different components).
Is that a fair basic understanding?
I don’t think so. A TSDB is all about saving the history of changes over time. Systems like Redux or Vuex are about providing a structured way to mutate state in an asynchronous system. So at the end of it all, you will only have one version of the state.
Well, in order to enable time-travel debugging would require something akin to a time-series database (even if it’s just a array of functions that can be moved back/forth). Thanks for pointing that out.
The core thing that seemed interesting is that Redux/Vuex are tackling a similar problem to a database server. In a sense, both bits of tech are tackling similar problems: managing state when talking to multiple other pieces of code.
The reason that seems interesting to me is that it sheds light on a few things that never quite made sense. If you think of them as something akin to an in-memory SQLite/REDIS, then mutations become your API into said data store, and the state in question has a schema of sorts. And since that API is likely to be smaller than the sum total of code accessing it, that means that you have less code to look over when trying to deal with state change bugs.
I apologize if I’m stating the blindly obvious, but the comparisons here seem to be a way that one could relate the terminology in a way this currently server side focused dev groks a bit better.
Redux becomes an Event Log system with time travelling, event filtering and replaying, etc. when you plug the redux devtools to it. It is very useful in development.
Otherwise it is (as you said) about providing a structured way to mutate state and keep a consistent view to it.