There is a page called Group Info and data is displayed based on the group. What would be the best way to handle a user toggling between Groups? If the user refreshes the page, the most recently selected group’s data should be displayed.
Example:
User 1 's default group is A
User 1 navigates to Group Info and sees the data for Group A
User 1 switches to Group B
User 1 refreshes page, should still see Group B until they toggle back to Group A
Is the best way to do this to just create a database record called current_group and set it?
Hi there, @bubble43… folks might disagree, but I usually store something like that directly on the User data type. So, you could have a selected group field, and just make changes to it when the user selects a new group.
Yeah, but it would have to be in addition to that because nothing about storing the groups to which a user belongs tells you which group the user has currently selected.
Right, but the starts adding more weight to the user table. Also wouldn’t that add some annoying admin to reset the the selected group back to the user’s default group?
@bubble43 Personally, I’d think to not store the selected group in the DB at all and just store it in a custom state. Avoids all DB writes and admin.
When a user changes the selected group, do a fake page refresh with the selected group in a url parameter, so if the user refreshes the page, you’re aware of his current selected group.
Yes, that would be a better way to do it, but I’m not sure if its worth such a sophisticated setup (relatively) just for this use. My understanding of the OP was that he didn’t have a SPA (page called Group) and in that case the benefits of your recommendation are limited and the setup is even more complicated.
It just happened to be my SPA explanation, however, I do tend to run the same setup on multi page apps with large groups like dashboards, admin panels, ecom stores, etc.
It preserves linking & prefer it over Params bc if you have 3rd party services that redirect and such you can break params.
The /path/path linking is also far more SEO friendly.
But yes for a quick integration states or params are good options.
Adding one field to the User data type is a perfectly reasonable way to go here, especially because OP wants the selection to persist, but I did say some folks might disagree.
Wouldn’t that just use an unreasonable amount of WU?
Pretty sure make changes to a thing actions on data tend to consume 1-3 WU. (I’m still on all legacy/dedicated plans so don’t pay much attention to WU)
If you have 20k page views in a month and each one navigates only a single time that’s almost guaranteed 20k WU usage then factor in multi navigation actions per user session.
If you have stats on your method I’d like to see the usage because I could be wrong. Just doesn’t seem cheap of efficient. Very easy setup though.
Params are free, all client side, and still an easy implementation. My preferred route is a bit overkill for only 3 groups.
Definitely reasonable. Was just pointing out some benefits of not adding the field. But the bigger issue to me is resetting the default group which can just introduce a whole bunch of annoying api wfs that I’d stay away from.
Hmm, I could easily be missing something, but I’m not following the resetting the default group thing. I think OP simply wants the selected group to persist across page refreshes and likely across sessions, but maybe I have that wrong.
Hmm, youre making me think maybe I read it wrong. My understanding was that default for user is Option A but when B is selected it should persist for this session including refreshes. However tomorrow when the user returns to the page the inital selected group should be A.
@bubble43 now I’m curious. What does default Options A mean?
Ah, I didn’t read it that way, and if that is the desired behavior, I would likely change my answer because as you pointed out, that would be a pain to manage… but maybe I would just add two fields on the User data type at that point.
@code-escapee, you are correct with how you interpreted it. Originally I was planning to have a default group. The selected group would persist with page refreshes and that session but if a user logged back in tomorrow, they would be defaulted to the default group.
However, after seeing @mikeloc’s first response, I thought about it a bit more and didn’t really think the default group was necessary. Based on how comparable apps function, the user can toggle between each group when they want to switch. Having a default would probably over complicate it from a configuration side but also user side.
Adding a current_group to the DB seems easy enough but I didn’t realize it was that WU intensive, especially if users are toggling between groups multiple times during a session.
I’ll test it out with page params as well and see which makes more sense for this use case.
