Blocks auto-update?

[CriesofCarrots]

Our designs for transactions include a row to provide auto-update functionality:

I think we should implement this on blocks as well

[manuel-calavera]

@sunnygleason do we have this kind of api?

[sunnygleason]

@manuel-calavera I was thinking of this as a front-end implementation:

• v2/store classes implement a refresh() function
• components register themselves (and their stores) with the dropdown box
• the dropdown box implements a timer function that fires/triggers the refresh() function

Would you like to take a pass at implementing this? I'm happy to -- I just
wanted to make sure the design fits your vision for how components fit
together. Any design tips you have are most welcome!

[sunnygleason]

(moving to blocked since this is pending feedback)

[manuel-calavera]

@sunnygleason i will check on it in coming days. thx!

[manuel-calavera]

@sunnygleason i suggest to change design. instead of pulling txs on ui part and comparing them with already stored in store i suggest to have an additional api call to return count of new transaction happened after provided tx id.

basically ui triggers api by timeout with providing most recent tx id and gets counter of new transactions happened after most recent in ui store. lmk what you think.

[sunnygleason]

@manuel-calavera that makes sense - so maybe modify like this?

• Add a component called: <ResultSetInfo info=... /> or something like that (initially empty/hidden)

Split out 2 responsibilities: refreshView(), and refreshInfo()

• refreshInfo() is triggered by the dropdown component timer and informs the info view, that "info row" doesn't show initially
• refreshView() is triggered from the "info row" click handler (or something like that)

If there's a better name(s) for "info row" and "current view", I'm
definitely open to suggestions. Thank you again, let me know what
you think!

[manuel-calavera]

@sunnygleason sounds good, we need similar component for blocks table. i think we may need to show it only on 1st page of table. actually i am still not sure if we want pages vs load more on scroll. design mockups do not show next-prev pages selectors. you can make an api as i proposed or api + components if you want. I am ok to make components after you finish api. up to you.