follow up on Collection Activity Tab // limit number of events in query

[daiagi]

to sum it up, left overs for next PR:

• display sensible data in the chart Missing things for Collection v2 #5362
• holder/flipper info on RMRK2
• use formatDistanceFromNow instead of timeAgo ✨ Collection Activity Tab #5345 (comment)

• ✨ Collection Activity Tab #5345

[exezbcz]

scroll position reset when switching tabs (items/activity)

from the bottom of this comment:
#5345 (comment)

• can we make it so the switch between items and activity does not reset the scroll position
• it's better when its seamless

[daiagi]

by @roiLeo : #5345 (review)

• I would remove import { set } from 'vue'
• make has-text-k-blue & has-text-k-grey global variables class
• query doesn't have limit on events
• put composable (useReplaceUrl) in composable folder
• relative path
• duplicate css code & some bad selector (.background-color??)

[yangwao]

Plus codeclimate review

• ✨ Collection Activity Tab #5345 (comment)
• https://codeclimate.com/github/kodadot/nft-gallery/pull/5345

[daiagi]

@roiLeo
About the point you've raised that there is no limit on events
I think it is necessary to get all events in order to have correct flippers info
I guess a way to reduce data is to get all buy events
And paginate the rest as user scrolls down the list

But I don't that will make much difference in query size

Wdyt?

[roiLeo]

@roiLeo About the point you've raised that there is no limit on events I think it is necessary to get all events in order to have correct flippers info I guess a way to reduce data is to get all buy events And paginate the rest as user scrolls down the list

Yes! Limit 20-50 and paginate the rest. (we had same stuff in #5038)

But I don't that will make much difference in query size

Wdyt?

Let's imagine I make 100k+ "LIST" event, client side won't be able to handle all this data.

[daiagi]

OK. Just to clarify...
You do agree that all buy events will still be needed to be fetched immediately, right?

Let's imagine I make 100k+ "LIST" event, client side won't be able to handle all this data.

Yes. Of course

@vikiival what is your take on this? What would be most efficient way?

[roiLeo]

OK. Just to clarify... You do agree that all buy events will still be needed to be fetched immediately, right?

for me not necessarily. Is it for the graph? this would be the events over a given period of time.

[daiagi]

The graph too I guess
But I was thinking about flippers tab, for that I need to know about every time an nft switch hands, so that means all buy events

@vikiival would it make sense to process holders and flippers on rubick and add these attributes to collection Entity? Especially flippers

By the way, on previous collection activity minters who sold their nft are also dubbed flippers, I disagree with that.
I think only someone who bought and sold is a flipper.
For now I kept this as it was before though

[daiagi]

by @roiLeo : #5345 (review)

* I would remove `import { set } from 'vue'`

* make `has-text-k-blue` & `has-text-k-grey` global [variables](https://bulma.io/documentation/customize/variables/) class     

* put composable (`useReplaceUrl`) in composable folder

* relative path

* duplicate css code & some bad selector (`.background-color`??)

all done.

outstanding issues:

• scroll position when switching between activity and items tabs follow up on Collection Activity Tab // limit number of events in query #5388 (comment)
• limit number of events in query, paginate events table

[daiagi]

scroll position reset when switching tabs (items/activity)

Fixed by #5416

[daiagi]

@vikiival @roiLeo I think creating a userEntity is the way forward
A userEntity will have all the data required for holders flippers tab and will take the load of calculating it off the front end.
Does that make sense?

Thank you

[roiLeo]

@vikiival @roiLeo I think creating a userEntity is the way forward A userEntity will have all the data required for holders flippers tab and will take the load of calculating it off the front end. Does that make sense?

Yes! kodadot/rubick#52 & kodadot/rubick#56 (maybe kodadot/rubick#157 for a start)
Feel free to try to write new schema, I can help you if you need to setup indexer project.

[daiagi]

it will take some time as I'm in vacation until 9th of April

If you are interested in getting it going feel free to, otherwise I will try my strength in it when I'm back

[vikiival]

9th of April

Will take that time to design new Schema 2.0 😅

[yangwao]

Yes! kodadot/rubick#52 & kodadot/rubick#56 (maybe kodadot/rubick#157 for a start)
limit number of events in query, paginate events table

Only this is left in this issue?

[roiLeo]

limit number of events in query, paginate events table

Only this is left in this issue?

Yes imo same stuff as #5540

[yangwao]

this is related I guess

• Super heavy loading on activity  #5540
• Too much graphql calls on activity tab #5574

Good for resolver?

[yangwao]

hey @daiagi can we look on this as we want to launch rmrk2 bug hunting

• Switch chain to rmrk2 on rmrk2.kodadot.xyz #5495
• Add whitelist for rmrk2.kodadot.xyz  #5536

[daiagi]

hey @yangwao
it is waiting on this:

• Design new 2.0 SubSquid schema loligo#5

once we can fetch holder/flippers info as part of new userEntity, the need to fetch all events on FE in order to calculate them will be eliminated. then we can paginate the events table in activity tab

That should resolve all heavy loading isuues in activity tab

[yangwao]

it is waiting on this:

and would be possible make lazy loading for that scroll table for now? I think that would save day till then? Because it's last thing we want to launch bug hunting for rmrk2 and it's quite issue for collection where are lot of owners, like >100.

[daiagi]

events table is already lazy loaded
I've lazy loaded holders/flippers tabs in #5608 and seeing performance improvement

[JustLuuuu]

@roiLeo can we close this?

[roiLeo]

@roiLeo can we close this?

Im not aware of current implementation, it was needed to limit number of events in query so user won't face potential bug where there is more than 1k events.

Feel free to close it.
If a bug occur on a big collection it could be related to that one

[vikiival]

Still an issue but we would need resolver