@colin Just wondering if the production release will improve speed? I've been using the initial release for quite some time, and on a table with about 10,000 rows it can take about 35 seconds to load with the search panes. Searchpanes are a fantastic addition that really improves the usability of Datatables, but the speed is definitely an issue with the initial builds.
@yakov116 Yes, I tried pulling down the nightly build, but it's going to take me some time to test as it's pretty different from the original test one. Mostly I have to work on the styling, trying to get the panes (on bootstrap4) into a container-fluid instead of just a container, and then get the filter boxes looking a little closer to the original style.
One thing I quickly noticed was that the bootstrap4 css sheet for SearchPanes makes a couple of global styles (button.btn, div.btn-group, etc). It might be best if those styles were all scoped to only apply to elements within the SearchPane div so that they don't impact anything else on the page.
@yakov116 / @prgmr1 - yep, performance is the main focus for the next week, Allan is going to take a look to see where optimisations should occur.
I've flagged the BS4 styling issue as well, so expect that to be changed in the next week or so. We're aiming to get a release out by the end of the year.
@colin That's all great to hear. Even the initial implementation of SearchPanes was pretty great, looking forward to this being final. Working with the code to style it will take some work compared to the original simple design, but there's a ton of functionality that's been added (and really very useful).
Regarding styling, is there going to be an easy way to override some of the lower-level internal styles? Mostly I'm looking at the container class that's on the dtsp-panesdiv. For those of us using Datatables on a full page layout the container object (at least in bs4) forcibly limits width and seems unnecessary. The other generic classes being used aren't quite as opinionated as container.
Glad to hear speed improvements are coming. I got the latest build running and it seems to be about the same speed as the initial versions. I recall Allan mentioning that one day SearchPanes would support server-side, so maybe at some point we'd be able to 'pre-seed' the filter options like yadcf requires (except even on non-server-side configs).
Thanks for the thoughts - I've added those to your jira, so they'll be considered - we'll report back here with the conclusions and our thoughts. It's still early days, so this feedback is useful if honing the extension into something that everyone will find useful.
p.s. the server-side side aspect won't be part of this initial release, but is certainly on the roadmap when v2 is designed. That won't be in the immediate future due to other priorities unfortunately.
so maybe at some point we'd be able to 'pre-seed' the filter options like yadcf requires (except even on non-server-side configs).
This will actually be possible with v1 of SearchPanes. You can give it an options list (which you might have got from the server), or it can automatically detect the options. What it won't do is automatically integrate with the JSON feed from the server similar to how Editor works with the options. That is something that will come in a future version - for now you'd need to specify the options in an init option.
Mostly I'm looking at the container class that's on the dtsp-panes div
That max-width is coming from our demo stylesheet! That needs to be dropped for our Bootstrap 4 styling integration.
Performance: Sandy has done some work on reading data which appears to make a massive difference in the test case I'm looking at (1S down to 26mS for a click) so you could try using the latest nightly. Cascade panes and possibly some other stuff has been broken though, so you might need to wait a little bit if you are using anything more than the simple case.
We'll be looking at initialisation performance as well.
@colin Fully appreciate any consideration! It's great that you folks are even open to feedback on these things. Definitely didn't think server-side was coming right away, but this will may even lessen my need for server-side usage (since often I go down that road for filters, searching, etc).
@allan That's great to hear - well, I only say that because I've been assuming the initialization delays I have are due to SearchPanes looking for all the options. Even being able to specify the options is better than not being able to at all. Well, assuming that it is the reason for initial delay.
Performance wise that's a huge improvement, that's great - I've actually found the using it to be fairly quick and responsive. The only performance issue I've noticed is with initialisation performance (~10,000 rows taking about 45 seconds which drops to 2 or 3 seconds with I disable SearchPanes).
Oh - That makes sense, I saw the use of searchPanes.bootstrap4.js on some of the demo links and just assumed it was needed. Sorry about that!
Uncaught TypeError: Cannot read property '_updateFilterCount' of undefined
at SearchPanes._startup (dataTables.searchPanes.js:1870)
at HTMLTableElement.<anonymous> (dataTables.searchPanes.js:1452)
at HTMLTableElement.i (jquery-3.4.1.slim.min.js:2)
at HTMLTableElement.dispatch (jquery-3.4.1.slim.min.js:2)
at HTMLTableElement.v.handle (jquery-3.4.1.slim.min.js:2)
at Object.trigger (jquery-3.4.1.slim.min.js:2)
at HTMLTableElement.<anonymous> (jquery-3.4.1.slim.min.js:2)
at Function.each (jquery-3.4.1.slim.min.js:2)
at E.fn.init.each (jquery-3.4.1.slim.min.js:2)
at E.fn.init.trigger (jquery-3.4.1.slim.min.js:2)
Not sure what changed but have this error the past few days
We haven't seen that - it's not happening in our test cases, see here. Could you look at that, please, and see if it helps. If it's still not working for you, please can you update my example, or link to your page, so that we can see the problem.
No worries, I just did a pull on your repo and I can see it. I've raised it internally (DD-1290 for my reference) and we'll report back here when there's an update.
That should be it working for you now. We have been working on getting SearchPanes to behave asynchronously for larger tables and this left behind a few bugs that you have helped us catch with this.
We're getting close to making the first release of SearchPanes - if you've got any feedback, missing features or if you've spotted any issues, shout fast
@colin I would like to test it out all the options that you have. However I cannot see the documentation. (Its there when searching but the page is inaccessible)
The docs are in the repo, but a bit hard to read due to the HTML - I think the directory is called docs or manual. There aren't too many options, but you can see them being tested in the test directory, likewise the API calls.
I'm having an issue when using SearchPanes with state saving. The following error pops up on the page after doing some filtering and returning:
Uncaught TypeError: Cannot read property 'length' of undefined
at SearchPanes._startup (dataTables.searchPanes.js?13:1760)
at dataTables.searchPanes.js?13:1724
Additionally, it causes one of the search panes to simply disappear and the "Clear All" button to not function as expected
Another error that creeps up is:
Uncaught TypeError: Cannot read property 'toString' of null
at v.<anonymous> (dataTables.searchPanes.js?13:961)
at v.map (<anonymous>)
at v.map (datatables.min.js:141)
at SearchPane._reloadSelect (dataTables.searchPanes.js?13:961)
at SearchPane._buildPane (dataTables.searchPanes.js?13:641)
at SearchPane.rebuildPane (dataTables.searchPanes.js?13:213)
at SearchPanes._startup (dataTables.searchPanes.js?13:1740)
at dataTables.searchPanes.js?13:1724
@ITAppData@HomeStreet.com - the first issue is now fixed, but we were unable to reproduce the second issue. Could you try both again, please, and if any issues remain, could you create a test case on live.datatables.net. Information on how to create a test case (if you aren't able to link to the page you are working on) is available here.
Just to let you all know that SearchPanes is now officially released - see notice here. Thank you for all the feedback, it helped us hone the requirements.
Thanks @colin, @sandy and all the team for the excellent work you've done on the extension!
I'm really happy to finally be able to use the "official" extension! (not that I wasn't already using it ahah )
Excellent, glad you like! Let us know if there's anything missing that you would like to see. We've got a short-list of extra features and fixes for 1.1, always capacity to add more
Maybe a new feature suggestion (that might not fit the current extension's scope though, you will be better placed than me to evaluate).
I thought it could be nice if there was a way for the user to "save" his filters so that he could reuse them in the future (hence creating "user defined views" of a same data model). I would have seen it maybe integrated with StateSave...
That sort of feature is available for example with MS Azure Devops for filtering issues in backlogs etc... and is really useful for different users to really be able to configure the views as they want it while not having to modify the backend or add complex queries to fit everyone's preferences.
What's your point of view on this? Thanks again for your time and effort!
@setwebmaster - I think that's a great idea - thank you. We won't be implementing it for v1.1, but I have filed it in our internal feature / issue tracker (DD-1341), so expect to see it at some point in future.
Replies
Ok thanks
@colin Just wondering if the production release will improve speed? I've been using the initial release for quite some time, and on a table with about 10,000 rows it can take about 35 seconds to load with the search panes. Searchpanes are a fantastic addition that really improves the usability of Datatables, but the speed is definitely an issue with the initial builds.
@prgmr1 the past few days they have been working on its great!
@yakov116 Yes, I tried pulling down the nightly build, but it's going to take me some time to test as it's pretty different from the original test one. Mostly I have to work on the styling, trying to get the panes (on bootstrap4) into a container-fluid instead of just a container, and then get the filter boxes looking a little closer to the original style.
One thing I quickly noticed was that the bootstrap4 css sheet for SearchPanes makes a couple of global styles (button.btn, div.btn-group, etc). It might be best if those styles were all scoped to only apply to elements within the SearchPane div so that they don't impact anything else on the page.
@yakov116 / @prgmr1 - yep, performance is the main focus for the next week, Allan is going to take a look to see where optimisations should occur.
I've flagged the BS4 styling issue as well, so expect that to be changed in the next week or so. We're aiming to get a release out by the end of the year.
@colin That's all great to hear. Even the initial implementation of SearchPanes was pretty great, looking forward to this being final. Working with the code to style it will take some work compared to the original simple design, but there's a ton of functionality that's been added (and really very useful).
Regarding styling, is there going to be an easy way to override some of the lower-level internal styles? Mostly I'm looking at the
containerclass that's on thedtsp-panesdiv. For those of us using Datatables on a full page layout thecontainerobject (at least in bs4) forcibly limits width and seems unnecessary. The other generic classes being used aren't quite as opinionated ascontainer.Glad to hear speed improvements are coming. I got the latest build running and it seems to be about the same speed as the initial versions. I recall Allan mentioning that one day SearchPanes would support server-side, so maybe at some point we'd be able to 'pre-seed' the filter options like yadcf requires (except even on non-server-side configs).
Really looking forward to the production release!
Thanks for the thoughts - I've added those to your jira, so they'll be considered - we'll report back here with the conclusions and our thoughts. It's still early days, so this feedback is useful if honing the extension into something that everyone will find useful.
p.s. the server-side side aspect won't be part of this initial release, but is certainly on the roadmap when v2 is designed. That won't be in the immediate future due to other priorities unfortunately.
This will actually be possible with v1 of SearchPanes. You can give it an options list (which you might have got from the server), or it can automatically detect the options. What it won't do is automatically integrate with the JSON feed from the server similar to how Editor works with the options. That is something that will come in a future version - for now you'd need to specify the options in an init option.
That
max-widthis coming from our demo stylesheet! That needs to be dropped for our Bootstrap 4 styling integration.Performance: Sandy has done some work on reading data which appears to make a massive difference in the test case I'm looking at (1S down to 26mS for a click) so you could try using the latest nightly. Cascade panes and possibly some other stuff has been broken though, so you might need to wait a little bit if you are using anything more than the simple case.
We'll be looking at initialisation performance as well.
Allan
@colin Fully appreciate any consideration! It's great that you folks are even open to feedback on these things. Definitely didn't think server-side was coming right away, but this will may even lessen my need for server-side usage (since often I go down that road for filters, searching, etc).
@allan That's great to hear - well, I only say that because I've been assuming the initialization delays I have are due to SearchPanes looking for all the options. Even being able to specify the options is better than not being able to at all. Well, assuming that it is the reason for initial delay.
Performance wise that's a huge improvement, that's great - I've actually found the using it to be fairly quick and responsive. The only performance issue I've noticed is with initialisation performance (~10,000 rows taking about 45 seconds which drops to 2 or 3 seconds with I disable SearchPanes).
Oh - That makes sense, I saw the use of
searchPanes.bootstrap4.json some of the demo links and just assumed it was needed. Sorry about that!Not sure what changed but have this error the past few days
We haven't seen that - it's not happening in our test cases, see here. Could you look at that, please, and see if it helps. If it's still not working for you, please can you update my example, or link to your page, so that we can see the problem.
Cheers,
Colin
I can try later today. Or if you want look at the latest in my repo and you will see the error.
No worries, I just did a pull on your repo and I can see it. I've raised it internally (DD-1290 for my reference) and we'll report back here when there's an update.
Cheers,
Colin
Did a drop of debugging.
if I load the script later in the list it does not error out but does not load at all.
I think this may be the issue.
Hi @yakov116 ,
That should be it working for you now. We have been working on getting SearchPanes to behave asynchronously for larger tables and this left behind a few bugs that you have helped us catch with this.
Cheers
Yup working!! Thanks
We're getting close to making the first release of SearchPanes - if you've got any feedback, missing features or if you've spotted any issues, shout fast
Colin
@colin I would like to test it out all the options that you have. However I cannot see the documentation. (Its there when searching but the page is inaccessible)
The docs are in the repo, but a bit hard to read due to the HTML - I think the directory is called docs or manual. There aren't too many options, but you can see them being tested in the test directory, likewise the API calls.
I'm having an issue when using SearchPanes with state saving. The following error pops up on the page after doing some filtering and returning:
Additionally, it causes one of the search panes to simply disappear and the "Clear All" button to not function as expected
Another error that creeps up is:
Here is the searchPanes code I'm using:
Thanks @ITAppData@HomeStreet.com , I've raised it internally (DD-1306 for my reference) and we'll report back here when there's an update.
Cheers,
Colin
@ITAppData@HomeStreet.com - the first issue is now fixed, but we were unable to reproduce the second issue. Could you try both again, please, and if any issues remain, could you create a test case on live.datatables.net. Information on how to create a test case (if you aren't able to link to the page you are working on) is available here.
Colin
Seems to be all fixed up. I'll report back if anything changes, but it's working great now
Thanks!
Excellent, thanks for the update.
Colin
Just to let you all know that SearchPanes is now officially released - see notice here. Thank you for all the feedback, it helped us hone the requirements.
Colin
Thanks @colin, @sandy and all the team for the excellent work you've done on the extension!
)
I'm really happy to finally be able to use the "official" extension! (not that I wasn't already using it ahah
Excellent, glad you like! Let us know if there's anything missing that you would like to see. We've got a short-list of extra features and fixes for 1.1, always capacity to add more
Colin
Maybe a new feature suggestion (that might not fit the current extension's scope though, you will be better placed than me to evaluate).
I thought it could be nice if there was a way for the user to "save" his filters so that he could reuse them in the future (hence creating "user defined views" of a same data model). I would have seen it maybe integrated with StateSave...
That sort of feature is available for example with MS Azure Devops for filtering issues in backlogs etc... and is really useful for different users to really be able to configure the views as they want it while not having to modify the backend or add complex queries to fit everyone's preferences.
What's your point of view on this? Thanks again for your time and effort!
@setwebmaster - I think that's a great idea - thank you. We won't be implementing it for v1.1, but I have filed it in our internal feature / issue tracker (DD-1341), so expect to see it at some point in future.
Allan