About pages are broken during Join Phase
samajammin opened this issue · comments
https://eth2clrfund.netlify.app/#/about/layer-2
Console error:
TypeError: Cannot read properties of null (reading 'nativeTokenSymbol')
Our native token logic relies on a current round existing:
https://github.com/ethereum/clrfund/blob/develop/vue-app/src/views/AboutLayer2.vue#L240
We need to provide a fallback.
Same issue also affects this page: https://eth2clrfund.netlify.app/#/about/how-it-works
https://github.com/ethereum/clrfund/blob/develop/vue-app/src/views/AboutHowItWorks.vue#L168
Need to provide a fallback there as well.
This also affects maxRecipients:
https://github.com/ethereum/clrfund/blob/develop/vue-app/src/views/AboutHowItWorks.vue#L164
We need to sort out a fallback here as this is something we want to display on the JoinLanding page. Is it safe to fallback to 124, since that is the current limit for MACI?
Fixed the maxRecipients issue in #500 but the nativeTokenSymbol bug is still an issue.
Only concern to me here is: do we need to set a fallback (the 124)? I have the feeling that this should come directly from MACI and we should trust that. If that doesn't come from MACI, then I guess the deployment was not well done or something more important is not working. But at this level/scope we should trust that we will have this information.
However, if we agree that we need to set a hardcoded value just in case, I would set it in the api/round.ts file where we fetch the data for the round. To avoid repeating this logic in different places.
The problem here I think is that we are not waiting the data to load.
@samajammin let me know if you agree with this and I can tweak it a bit to try to avoid the hardcoded value.
Agreed. I'm good with querying this from MACI if that possible. If not I agree the api file is better to avoid duplication of logic.
Main issue I was trying to solve for is if a current round doesn't exist. Ultimately the max recipients shouldn't be set on the current round in my opinion, given it's a MACI constraint on all rounds.
Well, there is a MACI instance created for each new round, so it is a 1:1 relation, that is why this information is coming from the api/round.ts scope.
So, the max recipients data is something that is tied to the round (or more precisely, the maci instance that that round has). But in this case, we want to show a default max recipients for the case when no round exists.
When we have no round we have two options:
- we start reading this data from an upper level, the maci factory, but I don't know:
- If we can get this data from there
- If the MACI factory share the same maxRecipients across all the instances created by it
- or we set an env variable and we use that as the default
I think we can just go to the easy env variable approach or leave this as you did, I don't see too much problem leaving it like that.
I think we can just go to the easy env variable approach or leave this as you did, I don't see too much problem leaving it like that.
Ya I'm ok with that approach for now.
For a longer term solution, my take would be to query this from the MACIFactory contract if no round exists. Based on my understanding, this is where all the MACI params are set - i.e. when we create a new round with FundingRoundFactory.deployNewRound, it uses the params from the MACIFactory. The FundingRoundFactory CAN change these params (via setMaciParameters), but querying the MACIFactory should handle that case.
Exactly, looking into it looks like you are correct, we can get this from the factory. Will try to implement that if it doesn't take too much time.
To clarify,
- currentRound exists => use maxRecipients from that round
- currentRound not exists => use maxRecipients from MACI factory