Closed carlosalvidrez closed 6 years ago
Hi,
This is the correct pattern. You should instantiate the pagination object in the onCreated method of the template and only change when necessary filters, sorting, perPage, etc. either on an event (click on a button) or in an autorun function added to onCreated.
Understood. Now, I’ve noticed than adding no filter on the initialization causes a high load on the mongo dB, even if right after, on auto run, the filter is properly set.
So, question... can the pagination be initialized while at the same time not expressing a filter, or what filter should be used to make the initialization light? I just don’t want t have to repeat code calls that initialize the filter (page size and page number either), back to back (once for on created and then once for the first auto run).
Does this make sense?
If you don't put a filter, you'll notice a high load because an observer is put on the whole collection.
If you are gonna set a filter on autorun after init, you could initialize the pagination with an invalid filter ({_id: 0}
).
Hi there, a hopefully quick question...
I found out that I can't instantiate the pagination object within the "autorun" clause of the "created" template event... when I do, the page cycles endlessly (stuck in a loop).
So what I've done is instantiate the pagination object first, outside of the autorun, and then, within the autorun, update the filter reactively (based on user input).
My question is... is this the expected/correct/best pattern? I wonder because I end-up duplicating code to, for example, setup the "perPage" property initially, and then also within the autorun, to perform the same task but once reactivity triggers occur.
Hope this makes sense, please let me know.