You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current display is a placeholder that doesn't pull on-chain data, and doesn't look great.
UI
Here's a suggestion of how it might look like. Open to more suggestions.
Nevertheless, the picture illustrates the essential features we need:
List decks and deck contents
List cards staked in inventory
List all cards owned (optionally also those in inventory, should be present by default, and inventory card should be marked with a small icon overlayed on the card)
We probably don't need a checkbox at first.
Search box to search in the current category.
Data Architecture
We'll also need to think about the data architecture for this. Fetching the data is easy enough, we already have a function for fetching the content of a deck, as well as the list of decks (though they don't have names at present).
It's not hard to get all cards, but soon players' collections might be a little bit too big for that to be efficient or even possible.
It wouldn't be hard to add a paginated way to get cards. However the list of owned cards is not sorted, and that's probably not how we would like to display cards on the UI. We could do the sorting in the RPC call, but when collections get large that would be a helluvah lot of storage access. At this point, the only solution would be indexing (which we currently don't have).
I think for now we just get the full collections, do the sorting locally, and we will add indexing later (which can support pagination).
Then the question is how to deal with changes in the collection. It doesn't cost much to listen to events while the page (or even app?) is loaded. Then simply refresh when the page itself refresh (we need to investigate what happens if the client goes offline for a while, but this probably requires a similar refresh).
The text was updated successfully, but these errors were encountered:
The current display is a placeholder that doesn't pull on-chain data, and doesn't look great.
UI
Here's a suggestion of how it might look like. Open to more suggestions.
Nevertheless, the picture illustrates the essential features we need:
Data Architecture
We'll also need to think about the data architecture for this. Fetching the data is easy enough, we already have a function for fetching the content of a deck, as well as the list of decks (though they don't have names at present).
It's not hard to get all cards, but soon players' collections might be a little bit too big for that to be efficient or even possible.
It wouldn't be hard to add a paginated way to get cards. However the list of owned cards is not sorted, and that's probably not how we would like to display cards on the UI. We could do the sorting in the RPC call, but when collections get large that would be a helluvah lot of storage access. At this point, the only solution would be indexing (which we currently don't have).
I think for now we just get the full collections, do the sorting locally, and we will add indexing later (which can support pagination).
Then the question is how to deal with changes in the collection. It doesn't cost much to listen to events while the page (or even app?) is loaded. Then simply refresh when the page itself refresh (we need to investigate what happens if the client goes offline for a while, but this probably requires a similar refresh).
The text was updated successfully, but these errors were encountered: