personally I'm not a fan of that. it means that we don't have a reference to this information in the server (because the server only gets the path and query paramter, not hash values)
ruaok
what does the number in the bar mean?
ishaanshah
Number of listens
ruaok
oh, I see the hover text says listens.
that is also unclear. I thought it meant I listened to that album 72 times last month.
alastairp
I understand that client-side routing libraries like react-router will enable us to do routing/back/forward button with a query parameter or a URL, is that right?
ishaanshah
I didnt put listens on the bar as it would overflow on smaller devices
ruaok
ergo, twice a day for a month. ehrm, no.
ishaanshah
ruaok: I didnt get you
alastairp
is the only way of doing this with the URL to use a routing library? (I understand that you switched to the hash in this case because it's easy to do without having to include another library and rewrite a bunch of code, is that right?)
ishaanshah
alastairp: Even before we were not using the query params to get data from server
All the data is obtained through API
the server only saw till the history part
alastairp
this now means that the way that we load data on the listens page is completely different from the way that we load data on the history/stats page
ishaanshah
Yes
The page loading in recent listens is kinda inefficient
alastairp
as I discussed with Mr_Monkey yesterday, I think it'd be good if we took a step back and decided how we wanted to do this, and make sure we do it the same in all places
what do you mean inefficient?
Mr_Monkey: maybe you and I could sit down this week and decide how we think that this should work, so that we know what pattern to use from now-on?
oh right, I think we're talking about slightly different things here. this is why I want to clarify it
yes, to go to another page on the listens page will load the whole page again, but in the grand scheme of things, I don't think that this is inefficient
it's true that we can improve the usability of this page by using an API query from the frontend to request the next or previous page
however in this case we should also make sure that the back/forward buttons work as expected
ishaanshah
The back button works in hash routing solution
alastairp
to be blunt here: I don't like hash routing
it's using the wrong tool
ruaok
+100
alastairp
personally I would prefer that we continue to use query parameters, or nicely structured URLs
which means that we need to find a solution to do this. I don't know about frontend libraries, so I have no idea what the solution to this is. I understand that react-router can help here but I don't know if that is the correct tool to use
Mr_Monkey also needs to investigate
Mr_Monkey: maybe thursday we could spend some time on it?
