> I think it will be good for everyone to separate the API and state management. It
both creates a library that others can use to create applications but
it also makes
good dog food — that is to say that we can use more predictable patterns when
getting data and updating state. It also cleans up the logic so we’re
not mutating state
in what appears to just be an API call.
I agree, but it's important to note there are two kinds of APIs here.
The first kind, which I believe you're referring to, is simply the
write interface to the gall apps as exposed by eyre (pokes, watches
etc.). I absolutely agree that these should be kept out of the state
management. However, there is a second kind of API and that is the API
as an interface for manipulating the state. This is implicitly tied to
how we represent the state. This API should absolutely depend on the
first one in order to dogfood correctly, but I don't think it can be
meaningfully prised away from the state management. Here is a demo of
what this could look like with Zustand.
>I like Redux because it’s popular and has the benefits that come with that.
It does seem like it might be too complex for our needs.
Yeah I very much think redux is in the too complex basket.
>Zustand seems quite eloquent and poised to facilitate hook adoption.
But being less popular I would hate to invest much time just to learn
that it doesn’t
support a critical use case. (This is the speculation of an amateur)
FWIW, Zustand is very small (<500 LoC) and supports middleware. It
seems hyperfocused on just state management and nothing else. I very
much doubt there's a critical use case that we can't get it to
support, given that it doesn't really do that much.
>MobX’s search result snippet says that it’s not pubsub and we all know what /precepts
says (ok, I was just reading it when this email came in). But it just
doesn’t smell right.
Yes absolutely, I was more including it for the sake of completeness