This allows me to modify the client in-place and get immediate feedback
that it's working.
There's likely a better way to do this. I'm not a node developer.
Turns out I was doubling-up unnecessarily and had an event handler _and_
a hash change detection. This just made things complex. Now I use the
hash for both the mailbox and the email navigation.
I don't yet do anything with the email part.
This includes a bunch of new things. I've introduced "ensureEmail..." to
indicate that the UI would like some data to be populated, but if it is
already present we don't need to do anything.
I've also introduced a cache for emails that is keyed on the email ID. I
don't know if email IDs are unique. They look like they should be
globally unique within a given server, but I'm not sure and the standard
is unclear. It'll need some experimentation.
The goal here is to be able to augment the client with additional data
as we get it. At this point I'm now augmenting with the mailbox data
that the MailboxList is requesting and showing that.
That's progress.
There may be significant issues with making multiple requests in a
single round-trip because my client library appears to do things like
hard-coding the position of specific requests. I may have to work around
this.
This won't work, not in the long term, but it's a better direction.
I've created proxy classes for the classes coming from the JMAP client.
The issue here is that this client is likely to have a bunch of things
wrong. Specifically, the standard indicates that the client can be
extremely stateful, to the point where it's just getting a stream of
updates and keeping most of the structure in memory. The client, as
presently built, does not make it easy to honor this part of the
standard, so I'm going to have to structure the client interaction
differently.
However, what I've done here, while interesting, is not good.
The problem is that I am correctly telling the client "I need the list
of mailboxes" when I render the mailbox list, but I'm not able to
propogate that information back to the client since it's passed down
through props.
I'm going to need to separate out the client into its own class and have
an eventing system of some kind between it and the app.
This was surprisingly complex because I tried to use react-router and
found no easily and reasonable way to do it, so instead I hooked the
location change event myself and plumbed it through. This required me to
switch to a class-style component rather than a functional one, which
required translating a bunch of coding styles through React.
Overall I'm happy, it works pretty well and simply.
No real changes to it, and I'm avoiding the favicon and logos to avoid
burdening my git repository, but otherwise it's all here while I figure
out how to change things.
Eli Ribble