search

sparkletown / sparkle

Building an open, community-owned hyperverse town
GNU Affero General Public License v3.0
33 stars 30 forks source link

Feasible to memoize entire state of the posterhall to come back to it? #1477

Open yarikoptic opened 3 years ago

yarikoptic commented 3 years ago

Initially thought about it in the context of randomizing the posters listing (https://github.com/sparkletown/sparkle/pull/1452#discussion_r641708753) but then realized that it would be generally very usefull: unless poster is opened in a new tab/window (#1447 wishlist) when I go to a poster and come back I end up in a fresh state -- search query is gone, my position in the list is gone etc. A general solution would be to somehow memoize the entire state of the page rendering and position at that point so when I get back to it from a poster, I end up in exactly the same state.

One way is to describe the entire state of cause (search query, and probably id of the top visible poster to add to #fragment? and then change url in the history before leaving to be that - so browser would get to it upon "back" and also make onClick to go to that state too).

I wonder if there is some reasonably easy way to accomplish that (attn @0xdevalias @soichih)?

0xdevalias commented 3 years ago

Off the top of my head, the more reacty way to solve this sort of a need (as I believe I described on the original smaller ‘need’ on the specific PR) is to make use of global state stored in redux. We already do this for a lot of things, but the search results, randomisation, etc you’re talking about are all handled in the hooks (basically local state) rather than global state. So by design, when you navigate away from the PosterHall to a PosterPage (a different venue), they are ‘cleaned up’ and ‘released from memory’.

An alternative pattern that could also potentially solve this need (that would allow us to continue using hook-based memorisation, etc) is to leverage react’s context provider pattern. This is used in a few places in the app, most recently/cleanly for the ‘useRelatedVenues’ performance refactor that made the env/ohbm environment actually usable again (the number of related venues and our older inefficient way of building the schedule was breaking things and making it load super slow). To use the context provider pattern, we would probably need to add the ‘provider’ in the TemplateWrapper component, but only have it wrap around PosterHall and PosterPage venues (both will need to be wrapped by the same provider). That way it would allow the memoised hook state to be maintained when navigating between PosterHall and PosterPage, but would still be cleaned up when navigating to any other venue type outside of them.