Store scroll position

Hi all,

how do you tackle the following issue: when scrolling in a list managed by Livewire the list jumps to the top after changes have been made.

Here comes an example:

Situation:

(Hm, as a new user I can only post one image, so I’m gonna try to use words…)

What I want when clicking an item (e.g. “Diplomat”):
Show details right below the title; don’t change scroll position

What actually happens:
The list “scrolls” to the top and I have to scroll down to get to the item.

Here comes a video: https://www.dropbox.com/s/i1hqlcj4j8ew5y5/Scroll%20position.mov?dl=0

The reason is clear - but how could I prevent such a behavior?

Thanks for any help!
Sebastian

It depends on how your code is setup to render this list. If you have a livewire component rendering a list of livewire components, I would think that the front end would behave how you want it to behave. For example, if you have a livewire list component and a livewire list-item component, you can have the action take place in the list-item component. Then when you click that list-item, the only thing in the DOM that would have to change is that specific list item which wouldn’t require the whole list to re-render. On top of achieving your desired effect, it should be a little more efficient in calling down data.

Thanks, that sound reasonable! Will go this way.

Are there any issues with having lots of Livewire components on a site? What happens e.g. in a filterable list with like 5.000 items?

@Sebastian
There are some options that it is possible to add to “wire:click”, one of the option is “wire:click.prevent” that will prevent to do other actions on click (e.g. follow href="#"). Try to search for “prevent” in documentation.

1 Like

I believe syntax to prevent bubbling up for wire:click is wire:click.stop.

@shortbrownman

I believe syntax to prevent bubbling up for wire:click is wire:click.stop.

No it is “.prevent”

Actually both should work…

@Dimonka2, .prevent doesn’t stop wire:click from bubbling up. Try it yourself. The proper call is .stop.

You might be confusing it with Alpine’s .prevent that prevents default javascript behavior.

@shortbrownman
Hmm. I was using .prevent all the time not even knowing about .stop It works for me…
Basically what .prevent is doing for me: stopping reaction on href tag

@Dimonka2

Different applications. If you’re looking to prevent the default action of the element, it’s .prevent. If you’re looking to stop livewire from bubbling up and possibly causing your parent component to refresh, use .stop.

Both of these methods would likely not help in keeping the component from losing scroll position, though because the whole list is re-rendered causing the jump back to the top. Separating the components would achieve that as the individual component would be the only one that’s swapped.

@Sebastian,
As for performance on 5,000 items. I’m unsure how livewire would perform at that level. You may have to do some testing to find out if this is the right approach for you. You may also want to think about chunking or pagination for this component if you’re anticipating large payload.

You are right that list elements need to be components.
But loading 5,000 elements is not recommended and does not make any sense. There are paginators, categories, search functions and other methods to manage such huge lists.

Sure, 5,000 elements in a list doesn’t make any sense. It was more a general question what the circumstances are that cause problems to the Livewire concept. But I’m kindnapping my own thread…

Will give a list with 5,000 components a try, just for fun.

I don’t think Livewire would be MORE susceptible than other frameworks regarding massive amounts of elements in the DOM if that’s what you’re asking. It might be good to experiment with the limitations, though.