Timing for DataTables and Masonry layout in Firefox
Timing for DataTables and Masonry layout in Firefox
I have a page with 4 DataTables on it, each loading data via Ajax. Since the tables are of variable sizes, I use the jQuery Masonry plug-in (just a default masonry() without passing additional parameters seems to work fine) to shuffle all my tables into a neat layout.
The way I do this is in the fnInitComplete callback. Each of the 4 initializations fires a function that checks against how many times it has been called, and then executes masonry() when all the tables have "checked in", reducing the number of masonry calls to one.
In Firefox, it works on first pageload or when I SHIFT+refresh. However, when I do a 'normal' refresh on the page, the masonry executes against incomplete tables, breaking the layout. Here's my theory:
On initial or SHIFT+load, the masonry script itself has to be downloaded before it will execute, which coincidentally takes longer than loading the data via Ajax, thereby meaning that masonry happens AFTER the data is loaded. But for subsequent refreshes, the script is cached and therefore executes BEFORE the data is returned.
I would use fnDrawCallback, but it's too heavy calling masonry after each draw since I draw once every 2 seconds. Then I thought to set a flag, but the flag would be cleared with the refresh and therefore wouldn't work.
I know this is more of a general JavaScript question than a DataTables question, but since ultimately it will rely on one of DataTables' options or callbacks, I hope it's not inappropriate to ask for ideas!
The way I do this is in the fnInitComplete callback. Each of the 4 initializations fires a function that checks against how many times it has been called, and then executes masonry() when all the tables have "checked in", reducing the number of masonry calls to one.
In Firefox, it works on first pageload or when I SHIFT+refresh. However, when I do a 'normal' refresh on the page, the masonry executes against incomplete tables, breaking the layout. Here's my theory:
On initial or SHIFT+load, the masonry script itself has to be downloaded before it will execute, which coincidentally takes longer than loading the data via Ajax, thereby meaning that masonry happens AFTER the data is loaded. But for subsequent refreshes, the script is cached and therefore executes BEFORE the data is returned.
I would use fnDrawCallback, but it's too heavy calling masonry after each draw since I draw once every 2 seconds. Then I thought to set a flag, but the flag would be cleared with the refresh and therefore wouldn't work.
I know this is more of a general JavaScript question than a DataTables question, but since ultimately it will rely on one of DataTables' options or callbacks, I hope it's not inappropriate to ask for ideas!
This discussion has been closed.
Replies
> I know this is more of a general JavaScript question than a DataTables question, but since ultimately it will rely on one of DataTables' options or callbacks, I hope it's not inappropriate to ask for ideas!
Questions and ideas which related directly to DataTables are always very welcome, particularly insightful and helpful questions and answers such as your own!
Regards,
Allan
If it could be that snappy each refresh, that'd be even better. Looking at the new jQuery 1.5 'deferred' functionality, I suspect there's a solution in there, but I'll have to come back to it later. For now, it 'works' even with that bit of a hiccup.
I wonder what executing masonry() for each of the tables would do (for a total of 4 masonries on initial page load) for responsiveness. I fear jumpy visual artifacts, but it might be worth a shot.