Get to where I'm querying for mailboxes
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.
2024-08-27 18:24:20 -07:00
|
|
|
import client from "jmap-client-ts/lib/types";
|
2024-08-27 23:22:11 -07:00
|
|
|
|
|
|
|
|
export interface IMailbox extends client.IMailboxProperties {
|
|
|
|
|
emails: Array<client.IEmailProperties>;
|
|
|
|
|
}
|
|
|
|
|
|
Get to where I'm querying for mailboxes
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.
2024-08-27 18:24:20 -07:00
|
|
|
export interface IAccount extends client.IAccount {
|
|
|
|
|
id: string;
|
2024-08-27 23:22:11 -07:00
|
|
|
mailboxes: Array<IMailbox>;
|
Get to where I'm querying for mailboxes
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.
2024-08-27 18:24:20 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
export type AccountIdMap = { [accountId: string]: IAccount };
|
|
|
|
|
|
|
|
|
|
export interface ISession extends client.ISession {
|
|
|
|
|
accounts: AccountIdMap;
|
|
|
|
|
}
|