A couple people have commented saying that this is not the proper way to do this, and you're correct! I am going to record a new video that I'll pin and put in the description this next week with a better alternative. Thanks for calling me out folks. :)
The best way to do this, is with teleport. Where you have a div, that gets all the pictures appended to it and the intersect as you had it in the video.
There’s a deeper issue here though Josh. You are querying your model every time you hit this function and pulling more and more records from the db. What happens if you “infinitely” scroll to the point where you are loading 1k records, 5k records etc. The user experience will get more and more laggy/janky.
Since you are just updating "page size" (perPage variable), does this mean that each load will again load all images from start to current page? So if you are on page 1 with 9 per page you load 9 images, but if you are on page 2, will you load/fetch 18 images or will it just append 9 images to existing list you have? If it's loading everything from the start it seems really inefficient to do it that way.
I’ll have to record another video with a better solution because even as an alternative you can use a Computed method which will cache the items and only load the new items.
I don't think so. Livewire morphs the HTML so the browser has to parse only the section that has changed. Why would the browser fetch the images already loaded?
@@TheKennyWorld it's not about the browser, it's the logic that runs on the server. If only perPage variable changes, I'd guess backend will fetch all images from first one again instead of just fetching the next page and appending them to existing images
I am developing a hotel booking website, and in the API response, I received more than 3,000 results. When I tried to render them using a for each loop, i got error that the memory exceeded its limit. And causing the page to freeze. I decided to implement infinite scrolling using Laravel's perPage helper function to load and display hotel detail cards progressively like the way this video. It works fine initially, but once it reaches 1,000 cards, the webpage starts freezing. Can you suggest any optimized solutions to handle this better? I would be grateful if you could share your thoughts on this comment.
Codecourse has a solution using chunks: Article::latest()->pluck('id')->chunk(10) etc. Than updating those chunks using the observer API with alpine.js
The best way to optimize this is to never load that many stuff in memory at any single time. How? If it renders 1000 cards fine then i would keep at a max 1000 cards loaded in memory at any time, the last shown.
Hey! I would recommend to you throw livewire and alpine into trash for that exact page (for that page part where cards). And implement virtual infinite scroll using pure ts/js. Or if you lazy as fuck (eg. as me 😂) you can on exact that part mount react/vue app (don't forget to split react/vue bundle and include only on pages where it needed) and use ready to go solutions to make virtualized infinite scroll. With that approach you can scroll any amount of cards (theoretically you can make loading for both directions (up and down) and in that case you really can without any lags and freezes scroll infinitely (or at least to the end of the data)). By default it loads up new stuff and appends to the end (unless like what have been shown here, where you load all the stuff again. Like first load will take nine, second eighteen cards (while first nine we already have on page), so it will grow until one request will take >10mb which causes lags and freezes). Ps. here little tips: 1. You can left loader for that part until your js app mounts. 2. You can left first cards as data attr or script that assigns it to windows to prevent refetching it again in react/vue app. 3. If this part is publicly available and you want to include this cards into seo, you have a few options. First if to left first cards markup instead of loader (in that case you need to take in sync two exact same html in both js app and in blade.php). Or you can put your cards into json+ld header and thats it.
@@just_old_memories I understand throwing livewire out as this won't help, but why alpine and add another layer of complexity as react or vue, you make no sense.
@@TheKennyWorld There are a couple of ways you can achieve this. With Alpine you can just call a livewire function that loads only a specific page and keep data in an array so you use the browser memory not the server memory. Also the query is only for the data that is missing so it is always fast. Another thing you can do is ( i only speculate this, idk if this is possible ) make a livewire component that only renders the data needed and only needs the current page, i would then create a loop that goes from 0 to current page - 1 and instantiate those components and give them a wire:key equal to the page, so even if the page changes they should never re-render as livewire doesn't touch child components and leaves them as is, so they will only do a query when they are first added in the dom and not afterwards.
@@eptic-c Yeah, I think that nesting is the way to do this in Livewire. If I understand correctly how Livewire rendering works it should only render the children once, so by having the images in the child components you are only dealing with that chunk of data once. (This is what I understand by reading Livewire docs, I should test this out to be sure.)
A couple people have commented saying that this is not the proper way to do this, and you're correct! I am going to record a new video that I'll pin and put in the description this next week with a better alternative. Thanks for calling me out folks. :)
The best way to do this, is with teleport. Where you have a div, that gets all the pictures appended to it and the intersect as you had it in the video.
Interesting. I'd love to hear about this way of doing it.
Thank you. Maybe, if I implement it, it will laggy later. However, it give me more clue to create infinite scroll.
Hey, what software/ tool are you using for video, so it have. layout like yours?
There’s a deeper issue here though Josh. You are querying your model every time you hit this function and pulling more and more records from the db. What happens if you “infinitely” scroll to the point where you are loading 1k records, 5k records etc. The user experience will get more and more laggy/janky.
Since you are just updating "page size" (perPage variable), does this mean that each load will again load all images from start to current page? So if you are on page 1 with 9 per page you load 9 images, but if you are on page 2, will you load/fetch 18 images or will it just append 9 images to existing list you have?
If it's loading everything from the start it seems really inefficient to do it that way.
Yes it does. So this is not a solution that scales well, imho.
Yep. You’re correct. I should have clarified that and touched on a better way to do it with chunking.
I apologize!
I’ll have to record another video with a better solution because even as an alternative you can use a Computed method which will cache the items and only load the new items.
I don't think so. Livewire morphs the HTML so the browser has to parse only the section that has changed. Why would the browser fetch the images already loaded?
@@TheKennyWorld it's not about the browser, it's the logic that runs on the server. If only perPage variable changes, I'd guess backend will fetch all images from first one again instead of just fetching the next page and appending them to existing images
Thanks
Thanks, This was helpful
I am developing a hotel booking website, and in the API response, I received more than 3,000 results. When I tried to render them using a for each loop, i got error that the memory exceeded its limit. And causing the page to freeze. I decided to implement infinite scrolling using Laravel's perPage helper function to load and display hotel detail cards progressively like the way this video. It works fine initially, but once it reaches 1,000 cards, the webpage starts freezing. Can you suggest any optimized solutions to handle this better? I would be grateful if you could share your thoughts on this comment.
Codecourse has a solution using chunks: Article::latest()->pluck('id')->chunk(10) etc. Than updating those chunks using the observer API with alpine.js
The best way to optimize this is to never load that many stuff in memory at any single time. How? If it renders 1000 cards fine then i would keep at a max 1000 cards loaded in memory at any time, the last shown.
Use virtualisation (virtual scroll)
Hey! I would recommend to you throw livewire and alpine into trash for that exact page (for that page part where cards). And implement virtual infinite scroll using pure ts/js. Or if you lazy as fuck (eg. as me 😂) you can on exact that part mount react/vue app (don't forget to split react/vue bundle and include only on pages where it needed) and use ready to go solutions to make virtualized infinite scroll. With that approach you can scroll any amount of cards (theoretically you can make loading for both directions (up and down) and in that case you really can without any lags and freezes scroll infinitely (or at least to the end of the data)).
By default it loads up new stuff and appends to the end (unless like what have been shown here, where you load all the stuff again. Like first load will take nine, second eighteen cards (while first nine we already have on page), so it will grow until one request will take >10mb which causes lags and freezes).
Ps. here little tips:
1. You can left loader for that part until your js app mounts.
2. You can left first cards as data attr or script that assigns it to windows to prevent refetching it again in react/vue app.
3. If this part is publicly available and you want to include this cards into seo, you have a few options. First if to left first cards markup instead of loader (in that case you need to take in sync two exact same html in both js app and in blade.php). Or you can put your cards into json+ld header and thats it.
@@just_old_memories I understand throwing livewire out as this won't help, but why alpine and add another layer of complexity as react or vue, you make no sense.
This is huge🙌🙌
Nice tip!!
guys i have a problem with laravel and vite when i create a new project with breeze and then npm run dev hole of the css is broken any one knows why?
Whats 'with' function
I believe it got recently added to avoid using Temple literals in blade templates and creating a clutter.
This is a very very bad example, you will get a memory exception in no time with this approach also a query slower on each scroll.
You’re right. This isn’t perfect. I’m going to record a new video. ☺️
How would you solve the potential memory issue?
@@TheKennyWorld There are a couple of ways you can achieve this.
With Alpine you can just call a livewire function that loads only a specific page and keep data in an array so you use the browser memory not the server memory. Also the query is only for the data that is missing so it is always fast.
Another thing you can do is ( i only speculate this, idk if this is possible ) make a livewire component that only renders the data needed and only needs the current page, i would then create a loop that goes from 0 to current page - 1 and instantiate those components and give them a wire:key equal to the page, so even if the page changes they should never re-render as livewire doesn't touch child components and leaves them as is, so they will only do a query when they are first added in the dom and not afterwards.
@@eptic-c Yeah, I think that nesting is the way to do this in Livewire. If I understand correctly how Livewire rendering works it should only render the children once, so by having the images in the child components you are only dealing with that chunk of data once. (This is what I understand by reading Livewire docs, I should test this out to be sure.)
@@joshcirre Esperando el video, la verdad si me interesa que este bien implementado, hay casos en el que la paginación no es buena...