support contract 0.3.2 and reduce fetch records on the history page #134
Conversation
rueshyna
commented
Nov 2, 2023
rueshyna
commented
- support contract 0.3.2
- in the future, if we should spend time to enhance the way to support new version of contract. Now, it becomes a bit painful. the version change is everywhere.. polymorphism is our good friend.
- reduce fetch records on the history page to enhance loading performance
versioned/interface.ts
Outdated
| @@ -50,7 +51,7 @@ abstract class Versioned { | |||
| readonly version: version; | |||
| readonly contractAddress: string; | |||
|
|
|||
| public static FETCH_COUNT = 20; | |||
| public static FETCH_COUNT = 5; | |||
There was a problem hiding this comment.
Maybe 10 would be better? I think 5 by 5 may be a bit slow
| } else if (c.version === "0.3.2") { | ||
| return fetch( | ||
| `${TZKT_API_URL}/v1/bigmaps/${bigmapId}/keys?value.state.in=[{"executed":{}}, {"rejected":{}}, {"expired": {}}]${common}` | ||
| ).then(res => res.json()); | ||
| `${TZKT_API_URL}/v1/contracts/events?contract=${address}&tag=proof_of_event${common}` | ||
| ) | ||
| .then(res => res.json()) | ||
| .then((events: Array<proofOfEvent>) => | ||
| events.map(event => ({ | ||
| key: event.payload.challenge_id, | ||
| value: proposalSchema_0_3_2.Execute( | ||
| unpackDataBytes({ | ||
| bytes: event.payload.payload, | ||
| }) | ||
| ), | ||
| })) | ||
| ); | ||
| } else { |
There was a problem hiding this comment.
I think we can remove this and do a condition on the schema: (c.version === '0.3.1' ? proposalSchema_0_3_1 : proposalSchema_0_3_2)
There was a problem hiding this comment.
I prefer to split them as they are different cases. because:
- otherwise, next time if there is new version, the conditions will be complicated.
- also you will have to check condition multiple times.
In the future, I think we refactor "proposalType" to solve this kind of thing.
| version: "0.3.2", | ||
| }; | ||
| } | ||
| private static mapContent(content: content): proposalContent { |
There was a problem hiding this comment.
add_or_update_metadata is not handled at all, even if we don't handle it on the UI side, I think it should be handled here just in case
There was a problem hiding this comment.
no, it will throw error. as we don't have any unit test here, it's no way to know if you do it right or wrong. It will be better going with UI.
There was a problem hiding this comment.
So should we just ignore it for now?
There was a problem hiding this comment.
yes, for now, nothing will go wrong.
