New Member Model

[brandonfancher]

Background

We've confusingly had two separate models for member info: EdenMember containing info from our contract and MemberData containing member profile info from AtomicHub NFTs. We often have to awkwardly combine this information in our UI.

Now that we're moving the subchain and deemphasizing NFTs, we have an opportunity to simplify this.

In this PR

In this PR, I create a new model/interface: Member. And I apply that interface to:

• the NavProfile component
• the member detail page
• inductions

Obviously, the old model has to co-exist until we can move our UI over to the new--and that will make it a bit messy until then.

Questions and observations

• I'm not seeing a way to query via subchain a member's encryption public key, rank or the account name of their direct representative. Are those exposed via subchain queries? If not, can I get some help exposing those?
• It seems subchain updates come in at a much shorter/faster interval when using ephemeral chain than when using the deployed box. Is that the case, and if so, how do we make this environment behave more like the deployed environment (with regard to interval of updates)?
• I notice that each update forces subscribed components to re-render. For example, the NavProfile component (when depending on ephemeral chain) re-renders multiple times per second. This is not gonna be great for performance. My guess is that it's because the subchain library's returning a new object with every update. I could wrap the box query hooks in another hook that does a deep compare of the result and only returns a new object if there were actual changes, but that's probably better done in the subchain library itself. Thoughts?

After this PR

I'll migrate other parts of the frontend codebase to the new Member model. Most immediately, this could be done for the Community page/Members List. That will involve updating member chips too...which are consumed by elections UI. And elections need a few more items added to subchain before I can fully move that over. I'll start navigating that tomorrow, and may recruit from @sparkplug0025 or @tbfleming getting the missing properties added.

[sparkplug0025]

Nit: Due to above comment maybe a better name could be participatingInElection -- a little ambiguous, but I think it fits better the description....

[brandonfancher]

Good call. Done.

[sparkplug0025]

It's looking great! I think as we talked a little before, having some levels of member data amount is better for having smaller queries and less data bloat, but since queries are running locally it seems like there's not much gain in splitting it for now!

I'm not seeing a way to query via subchain a member's encryption public key, rank or the account name of their direct representative. Are those exposed via subchain queries? If not, can I get some help exposing those?

It's not, we need to work on it.

It seems subchain updates come in at a much shorter/faster interval when using ephemeral chain than when using the deployed box. Is that the case, and if so, how do we make this environment behave more like the deployed environment (with regard to interval of updates)?

I think we have a couple options:

• have you tried inspect > network > simulate 3g/4g connections? Does it help?
• add some delay in the eden-box blocks propagation

Both suggestions would only apply to receiving new data. It does not help at all with querying local data (which I imagine does not happen to production anyway, since we are also querying local)

I notice that each update forces subscribed components to re-render. For example, the NavProfile component (when depending on ephemeral chain) re-renders multiple times per second.

OOps... this sounds bad. Yeah, I think the fix must be done in the subchain library level, that way we leverage this in new apps and also to other devs too.

[brandonfancher]

@sparkplug0025

I think we have a couple options:

• have you tried inspect > network > simulate 3g/4g connections? Does it help?
• add some delay in the eden-box blocks propagation

I chatted with Todd about this. The difference is that the production version with dfuse only sends blocks to connected clients when a relevant block is produced. The ship implementation doesn't do that filtering yet.

In that case, though, even the production version with dfuse will cause all components connected to any box query to rerender when an updated block comes in. So yeah, we'll definitely want to fix that in the subchain lib.

[brandonfancher]

Opened an issue for that in #617

[sparkplug0025]

LGTM!