Data property size awareness

[Adrian-Sanchez]

I just ran into this issue where the onclick action that was running took 6ms, but the page took 1.5 seconds to run. It turns out that when the action is fired, cbwire/livewire will send all the data that is in the data variable to the browser whether it needs it or not. The browser takes time to evaluate all the data that is being processed. To summarize, i was using pagination but i was storing all the records in the cbwire data scope and I was also storing a subset of the records thinking that it should be much quicker; but it wasn't

So until this framework is "smarter" about how data is replaced in the DOM, this is something that should be kept in mind.
DONT CLUTTER THE DATA VARIABLE

[mrigsby]

Yep, overloading the data property like that will slow down the entire process.

Part of the issue is that the entire wire payload (which includes the data property) has to be passed back and forth. CBWire includes checksum validation for security, and due to its nature the wire component is re-instantiated and populated on every request so it needs all of the data properties to do this. Perhaps we can add a hint/warning about overloading the data property added to the docs. What do you think @grantcopley ?

FWIW, livewire does only send updates for changed data properties, however it still needs the "state" as well to validate the checksum of the "state" and instantiate the wire component before updating any values or making any method calls.

I have been in the same situation many times, specifically in regards to pagination. If your dataset is large and you would prefer not to hit the database on every wire update request my solution is almost always to implement caching, thus taking a slight hit on the initial render ( onMount() ) and then getting a massive performance boost on all subsequent wire requests. You can further improve the end-user experience by using lazy loading so the initial DB query time does not slow down the initial rendering of the entire page.

[Adrian-Sanchez]

Funny enough, the page i was working on, i was creating a page where i'm setting about 5 different cachebox caches. Sort of like a app specific cachebox management screen. But i was using the data variable to output them to the page so i can see how they are being populated.

I did solve my problem essentially removing the caches from data and only output the paginated results

Pressing forward, i'm wondering if it's this checksum all or nothing logic that is preventing doing things like transitions for looped DOM elements....

I have no clue how you guys are doing this...it's great work. Last night, i didn't get around to checking this, maybe it's already implemented:

But i'm wondering for more granular control, if a dev implements alpine x-data attributes, you could sync and checksum only the data that pertains to that DOM element. Maybe that would even solve that wire:transition goodness that we see in this livewire example. https://www.youtube.com/watch?v=0AvfYxJ5Ss0