[Issue #2479] Tie streams to hat

[Da-Colon]

Closes #2479

Alrighty, Goes with decentdao/decent-contracts#128 over in the contracts.

[netlify]

✅ Deploy Preview for decent-interface-dev ready!

Name	Link
🔨 Latest commit	cf7b133
🔍 Latest deploy log	https://app.netlify.com/sites/decent-interface-dev/deploys/67474800921c3c00084a9230
😎 Deploy Preview	https://deploy-preview-2562.app.dev.decentdao.org
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[DarksightKellar]

Whoops did not mean to approve just yet since "no QA yet". Meant to leave a comment

Didn't mean to approve

[adamgall]

@Da-Colon @fractal-framework/[email protected] is being published right now and should be available for consumption in ~3 mins from the time of this comment.

[adamgall]

Also @Da-Colon just to be clear

Until the contracts are published, did not commit the tempAbis and network addresses that I use for testing.

Why did you have new ABIs? The ABIs shouldn't have changed.

[Da-Colon]

Also @Da-Colon just to be clear

Until the contracts are published, did not commit the tempAbis and network addresses that I use for testing.

Why did you have new ABIs? The ABIs shouldn't have changed.

Because I'm sleep deprived

[DarksightKellar]

Cool lgtm

[adamgall]

In the latest commit, is there a race condition here? Seems like this code will only work correctly if and only if the KeyValuePairs data comes in (and gets stored in the map) before the updateRolesWithStreams function runs.

Is that a valid concern?

[Da-Colon]

In the latest commit, is there a race condition here? Seems like this code will only work correctly if and only if the KeyValuePairs data comes in (and gets stored in the map) before the updateRolesWithStreams function runs.

Is that a valid concern?

I don't think so? Since its coming in is being fetched at the same time as the hatTreeId which kicks off the retreival of that hats and setHatsTree is first called. I believe that these will correctly get set prior to setHatTree being called next.

I thought about update setHatTreeId into like setHatTreeEventData (The name is why I didn't) to set the loop first. In that I effect. I could just flip These like this for the same effect.

   setHatIdsToStreamIds(getHatIdsToStreamIds(safeEvents, sablierV2LockupLinear, chain.id));
        setHatsTreeId({
          contextChainId: chain.id,
          hatsTreeId: getHatsTreeId(safeEvents, chain.id),
        });

Since these are coming from the same getEvents called and extracted out.

I"ve done several refreshes and haven't seen any weird behavior so far. But I guess thats no saying much.

[Da-Colon]

In the latest commit, is there a race condition here? Seems like this code will only work correctly if and only if the KeyValuePairs data comes in (and gets stored in the map) before the updateRolesWithStreams function runs.
Is that a valid concern?

I don't think so? Since its coming in is being fetched at the same time as the hatTreeId which kicks off the retreival of that hats and setHatsTree is first called. I believe that these will correctly get set prior to setHatTree being called next.

I thought about update setHatTreeId into like setHatTreeEventData (The name is why I didn't) to set the loop first. In that I effect. I could just flip These like this for the same effect.

   setHatIdsToStreamIds(getHatIdsToStreamIds(safeEvents, sablierV2LockupLinear, chain.id));
        setHatsTreeId({
          contextChainId: chain.id,
          hatsTreeId: getHatsTreeId(safeEvents, chain.id),
        });

Since these are coming from the same getEvents called and extracted out.

I"ve done several refreshes and haven't seen any weird behavior so far. But I guess thats no saying much.

@DarksightKellar @mudrila Do either of you have any thoughts on this?

[mudrila]

In the latest commit, is there a race condition here? Seems like this code will only work correctly if and only if the KeyValuePairs data comes in (and gets stored in the map) before the updateRolesWithStreams function runs.
Is that a valid concern?

I don't think so? Since its coming in is being fetched at the same time as the hatTreeId which kicks off the retreival of that hats and setHatsTree is first called. I believe that these will correctly get set prior to setHatTree being called next.
I thought about update setHatTreeId into like setHatTreeEventData (The name is why I didn't) to set the loop first. In that I effect. I could just flip These like this for the same effect.

   setHatIdsToStreamIds(getHatIdsToStreamIds(safeEvents, sablierV2LockupLinear, chain.id));
        setHatsTreeId({
          contextChainId: chain.id,
          hatsTreeId: getHatsTreeId(safeEvents, chain.id),
        });

Since these are coming from the same getEvents called and extracted out.
I"ve done several refreshes and haven't seen any weird behavior so far. But I guess thats no saying much.

@DarksightKellar @mudrila Do either of you have any thoughts on this?

Yeah, I do see Adam's point - @Da-Colon did I get this right that you've changed implementation to what you suggested?

[Da-Colon]

yeah I'll go with the thing I suggested of just handling both of these via a single state setter.

[Da-Colon]

Check out latest commit @DarksightKellar || @mudrila. look good?