SPA scrolling issues between visible groups

I created an SPA application with the main page having a menu on the left and several groups on the right that are visible/not visible based on the menu section on the left. This works great, however, when I’m viewing a group that is more than one page down and I switch to make a different group visible via the menu, the newly opened group will position the view at the bottom, instead of the top. Then if I scroll to the top in that group and return the the previous group it will reposition that group at the top and not where I was the last time it was visible. I understand, since this is a single page that this is probably normal behavior since they share the same page.

I would like to create custom states that just store the last position and locate back to that position when the menu item is clicked or when the group is visible but I’m not sure how to do that and get it to scroll properly to a repeating group or simply tell it to open the group and position at the top of the group. It looks like this is possible if the page contains unique elements and I can scroll to an element but in cases with repeating groups, I’m not sure how to locate to a specific record.

This issue is possibly compounded because I am using all reusable elements to simulate pages in the groups that are made visible by the menu. I guess the other option is to fix the page height on the main page and force the scrolling in the individual groups?

What’s the proper way to handle this in an SPA?

Should be that the group that contain your different ‘page’ views are not displayed on page load (so uncheck the box in layout settings) and have conditions based on whatever value set you are using to determine if a group should be visible to make the group visible when it needs to be…in layout tab make sure the ‘collapse when hidden’ is checked.

Here’s the solution I use for my own SPA:

Turn every “page” into a floating group.

Make sure the floating group is set to float to both the top and bottom of the screen.

Since my app uses a shit ton of vertical repeating groups, I have my floating groups set at fit height to content.

This method allows for your device to remember the scroll position naturally without having to use states and // or html to try and complicatedly achieve the same thing.

Using this method, I’ve found 2 drawbacks.

A. Layout Settings can be annoying. Insofaras you’ll have to “bring to front” any true floating groups that you’d want to float over your anchor page floating group.

Like a header for example would need to be told to bring to front.

B. No Scroll Detection. Since you’re using a floating group, it’s not possible to detect how far a user has scrolled down the screen.

There are plugins that can detect the scroll position of repeating groups, however i haven’t tried them

1 Like

Thank you for the assistance. I appears I have it already setup as you suggested. The issue isn’t with navigation or the pages showing properly, the issue is If I display in a visible page/group a list of users that is 2 pages long and for example I allow the user to click on one of the users to switch to view the profile page for that user selected and the user that was selected was near the bottom of the list of users, the menu will hide the list of users (with collapse while hidden) and then display the users profile. However, the users profile is a page and a half and instead of it opening the page at the top of the profile, it opens the page and locates the view to the bottom of the profile because the page was positioned from the previous users list at the bottom. Does that make sense?

my setup would effectively fix this. I will mention though that with my setup you would still have to scroll up if you were on a users profile, and then jumped to another users profile. Since you’re technically still on the same page, showing the same groups, bubble has no positioning to respect.

In this case, you would have to set up a “when page is loaded” workflow that conditionally triggers when get navigation from URL = Profile & Current Page’s User is not Current State’s User.

You would also need to create a Current Page User State that triggers after the aforementioned workflow. It’s basically my way of knowing whether you’re viewing a different user’s profile, and thus, knowing when to scroll up.

Does that make sense?

Yes, I understand the issue now. The simple effective fix that doesn’t require a user to scroll and gets your desired UX, I believe is when you have the actions to change the views, so hide user list and open profile, use a workflow action to scroll to element and the element be the actual page…this way, everytime the view changes, the page will automatically without the user needing to do so and in most cases quick enough it might be unrecognizable to the user, scroll to the top of the page, which would effectively be the top of the new view.

Also, if you have a header element on the page you could scroll to the bottom of the header instead of the top of the page.

This will work for all view changes if you implement the scroll action on each action for changing views (which should only be one anyway)