State management in landscape

[Liam Fitzgerald]

Hi dev,
I'm currently somewhat unhappy with the way that Landscape handles its
state. Here are some of the issues that I'm currently running into.
- Insane prop drilling: Some of the components that we have use
significant swathes of the state (looking at you InviteSearch). This
is necessary, but creating an InviteSearch field deep in the component
tree generally requires adding several props to every single one of
its ancestors. This is a solved problem in React and there's no reason
we have to clutter up our components with a million props.
- State updates are in-place: This is for one a performance issue, as
we could in theory use PureComponent everywhere if we discarded
mutability. For two, it hampers adoption of hooks, as hook
dependencies are generally compared with reference equality.
- Waiting for state to load is a bit odd in places, and oftentimes
abuses the elvis operator heavily in order to account for unloaded
data.
- Poor namespacing and modularisation of updates/api requests/reducers

The canonical solution to all of our problems here is some kind of
state container, such that we could ''teleport''' chunks of state deep
into the component tree. There are a significant number of state
containers for react, so I'll just go over the pros and cons of some
of the ones I'm familiar with. I had a look at recoil, but it looks
too immature for our purposes.

Redux:
Pros:
- Reducer pattern maps quite nicely to the way we get cages over a
subscription
- Tried, tested, not flavor-of-the-month
- Composes well
- Well supported with third-party middleware
Cons:
- Async middleware is strange and complex
- Reducer pattern can be quite verbose for simpler local state
that we don't get from our ship

Zustand:
Pros:
- Colocates the state, write requests and requests in a way that
is very conducive to modularisation
- Actions can be async
- Small, simple, doesn't really add any concepts over and above
vanilla react
- Doesn't need to be used with any particular webframework
Cons:
- Hooks are the only means of consuming state

MobX:
Pros:
- Less boilerplate than redux
- Allows mutable state
- Very usable out of box
- Widely used
- Kinda OOP esque
Cons:
- Kinda OOP esque
- Not very vanilla

Interested to hear everyone's thoughts. Let me know what you think.
——
~hastuc-dibtux

https://urbit.org

[Tyler Shuster]

Thanks for bringing up these concerns. I agree that the project has accrued significant
technical debt in this area and is beginning to rear its head in tangible ways. You’ve
addressed my primary concerns and I don’t have any arguments.

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.

As for the suggestions you’ve mentioned, I like Redux and 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.

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)

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.

I think we want to become more principled and head toward higher purity
and immutability, and whatever framework helps us do that is the right one.

> --
> To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.
>

[Liam Fitzgerald]

> 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.
https://gist.github.com/liam-fitzgerald/50f66d7d62dd225fe7087e25dd53a4e6

>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
——
~hastuc-dibtux

https://urbit.org

[Logan Allen]

React Context is an option as well.

> On Oct 5, 2020, at 4:41 PM, Liam Fitzgerald <liam.fi...@tlon.io> wrote:
>
>