Closed newtec-foggia closed 6 months ago
If I were you, disable the select all feature for tables of this size. By selecting all records, your browser is downloading their IDs into memory. This is not very efficient, but there isn't really a better way that we can do this. The reason your browser freezes when you click delete is because it has crashed, see the alert.
Wouldn't this be solvable by making the selectedTableRecords private member and create a getter for this attribute if you need them client side? But I didn't investigate the inners on how this works.
But in that case you won't need to download them, and the action would be executed server side, and only at that point the selectedTableRecords member would be requested.
I can imagine this would be a solution where you have 1.000.000 record table, but an applied filter would only return 50.000 records, and you would like to execute an action on those records.
In Livewire, PHP properties are stored on the client side between requests.
ok... I understand. I thought only public properties were exposed to the client. that is why I had this in mind. Nevermind in that case :)
from the docs of livewire:
protected and private properties DO NOT persist between Livewire updates. In general, you should avoid using them for storing state.
so indeed, my assumption does not make sense... we would need to store them in a session or whatever, getting more trouble than it would provide a solution.
Storing in the session would make the session huge, I don't think many apps can scale to support that
If I were you, disable the select all feature for tables of this size. By selecting all records, your browser is downloading their IDs into memory. This is not very efficient, but there isn't really a better way that we can do this. The reason your browser freezes when you click delete is because it has crashed, see the alert.
Hi @danharrin, I couldn't find a way to disable this feature. How would you do that?
$table->selectCurrentPageOnly()
🛠Trouble with Export/Import Functionality in Laravel Filament Admin Panel: 'Login Route Not Found' Error
I've been tackling the export/import feature, aiming for smooth functionality. However, upon attempting to export or import a CSV, it seems to generate within the notifications. Yet, when I endeavor to download the file, a persistent 'login route not found' error arises.
I've configured separate guards for authentication, catering to both admin and user panels. Additionally, I've ensured that the export/import policy is correctly set to return true within the view function.
Furthermore, I've diligently included Export::polymorphicUserRelationship();
in the app service provider and executed all requisite database changes.
Despite these efforts, I find myself still grappling with the 'login route not found' issue when attempting to access export/import. Any suggestions on resolving this within the Laravel Filament admin panel?
Unrelated to bulk actions I think - https://github.com/filamentphp/filament/discussions/5226
@DishantPal I have the same issue How did you fix it?
Package
filament/actions
Package Version
v.3.1.
Laravel Version
v10.39.0
Livewire Version
v3.3.5
PHP Version
php 8.2.4
Problem description
HI, I have a user table with 50,000 records, I noticed when creating a bulk action that when trying to select all the records, pressing the export button seems blocked, for smaller selections it works perfectly.
https://github.com/filamentphp/filament/assets/83398776/6b1319c7-fd81-49d1-a4c4-e33595dff22d
Expected behavior
if we consider that there is no connected action the response should be immediate
Steps to reproduce
Reproduction repository
https://github.com/newtec-foggia/filament3-job.git
Relevant log output
No response