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 React from "react";
|
|
|
|
import Container from "react-bootstrap/Container";
|
|
|
|
import Row from "react-bootstrap/Row";
|
|
|
|
import Col from "react-bootstrap/Col";
|
|
|
|
|
2024-08-27 22:49:48 -07:00
|
|
|
import AccountList from "./AccountList";
|
2024-08-27 23:22:11 -07:00
|
|
|
import EmailList from "./EmailList";
|
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 MailboxList from "./MailboxList";
|
2024-08-27 22:49:48 -07:00
|
|
|
import Client from "./client/Client";
|
2024-08-27 23:22:11 -07:00
|
|
|
import { AccountIdMap, IAccount, IMailbox } from "./client/types";
|
2024-08-27 22:49:48 -07:00
|
|
|
|
|
|
|
type TopProps = {
|
|
|
|
account: IAccount | null;
|
|
|
|
accounts: AccountIdMap;
|
|
|
|
client: Client;
|
2024-08-27 23:22:11 -07:00
|
|
|
mailbox: IMailbox | null;
|
|
|
|
onMailboxSelect: (mailboxId: string) => void;
|
2024-08-27 22:49:48 -07:00
|
|
|
};
|
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
|
|
|
|
|
|
|
const AppLayout: React.FC<TopProps> = (props) => {
|
|
|
|
return (
|
2024-08-28 09:38:50 -07:00
|
|
|
<Container fluid>
|
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
|
|
|
<Row>
|
|
|
|
<Col>
|
2024-08-27 22:49:48 -07:00
|
|
|
<AccountList account={props.account} accounts={props.accounts} />
|
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
|
|
|
</Col>
|
|
|
|
<Col></Col>
|
|
|
|
<Col></Col>
|
|
|
|
</Row>
|
|
|
|
<Row>
|
2024-08-27 23:22:11 -07:00
|
|
|
<Col lg="1">
|
|
|
|
<MailboxList
|
|
|
|
account={props.account}
|
|
|
|
client={props.client}
|
|
|
|
onMailboxSelect={props.onMailboxSelect}
|
|
|
|
/>
|
|
|
|
</Col>
|
|
|
|
<Col lg="11">
|
|
|
|
<EmailList
|
|
|
|
account={props.account}
|
|
|
|
client={props.client}
|
|
|
|
mailbox={props.mailbox}
|
|
|
|
/>
|
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
|
|
|
</Col>
|
|
|
|
</Row>
|
|
|
|
</Container>
|
|
|
|
);
|
|
|
|
};
|
|
|
|
export default AppLayout;
|