inPlaceSort property setted to true brakes sort if it used together with filter in virtualisation mode

[Petr]

Here is a link to reproduce an issue - https://dojo.telerik.com/@WA_PMak/uNEVisOT

inPlaceSort property setted to true brakes sort if it used together with filter in virtualization mode.
Steps to reproduce:

1. Set inPlaceSort=true, turn virtualiztion on.
2. Set filter of City column to "not equals to "qwerty".
3. Set First Name column order to asc.
4. Set Last Name column order to asc.
5. Scroll till grid loads next virtual page.
   
   Actual result: setted sorting and filtering brakes - data in unordered state
   Expected result: data keeps it order and filtering states. 

[Stefan]

Hello, Petr,

Thank you for reporting this.

I can confirm that this is an issue with the current version of Kendo UI Grid.

I created an issue in our GitHub repository and forwarded it to our developers for fixing. You can track its progress at:

https://github.com/telerik/kendo-ui-core/issues/4053

For now, the workaround will be to use the standard sorting without the inPlaceSort property.

Additionally, I updated your Telerik points for bringing this to our attention.

Regards,
Stefan
Progress Telerik

[Petr]

Using of inPlace Sort and virtualization is critically important for me. Could you name the version of kendo UI lib without having this issue please?

[Petr]

Stefan, I'd tried to switch inPlaceSort option off as a result I've got extreamly slow scrolling grid.

Please update severity status of issue you'd created in git hub it can't be low (currently seted) I'm strongly believe that it is a pretty serious issue which makes impossible usage of grid with large amount of local data.

[quote]
I can confirm that this is an issue with the current version of Kendo UI Grid.
[/quote]

I'd tried to switch to previous versions and I'd found out that the issue first time appears in 2017.3.913(R3) version.

So I tried to use 2017.2.621(R2 SP1) and it seems like it has another issue - inPlaceSort property doesn't work in this version so I'd tried 2017.2.504(R2) and 2016.3.1118. These versions have not working with inPlaceSort property too.

By saying "not working" I mean that setting of the property to the true value does affect speed of scrolling if datasource have filter(s) seted. It works extremely slow and cannot fit requirements of my project.

[quote]
For now, the workaround will be to use the standard sorting without the inPlaceSort property.
[/quote]

Also I'd tried your suggestion - on a latest version I'd set inPlaceSort to false and now I have really slow scrolling grid so I cannot accept the workaround you'd suggested.

All described issues can be reproduced on kendo grid virtualisation (local data) example also it can be reproduced here - https://dojo.telerik.com/@WA_PMak/uNEVisOT

As a conclusion:

1) Please provide the number of version that have no described issues (wasn't able to found one) 

2) Please increase severty status of the issue - https://github.com/telerik/kendo-ui-core/issues/4053

[Stefan]

Hello, Petr,

Regarding the questions:

1) The issue is not reproduced in version: 2017.2.621.

2) The issue severity was changed to medium, but the ETA may vary depending on its complexity and the current workflow.

Regards,
Stefan
Progress Telerik

[Petr]

[quote]1) The issue is not reproduced in version: 2017.2.621.[/quote]

As I said few posts before that version has another issue - "So I tried to use 2017.2.621(R2 SP1) and it seems like it has another issue - inPlaceSort property doesn't work in this version so I'd tried. This version have not working with inPlaceSort property too" By saying "not working" I mean that setting of the property to the true value does affect speed of scrolling if datasource have filter(s) seted. It works extremely slow and cannot fit requirements of my project.

So I'm still can accept that. Please create another issue in git hub for it.

 

[quote]2) The issue severity was changed to medium, but the ETA may vary depending on its complexity and the current workflow.[/quote]

Medium? You really think that is enough? From my perspective it is a blocking issue 'cause it makes the Grid totally unusable in case of using it with local data. 

I insist on increasing the severity level to at least a critical level ideally to a blocking issue level, 'cause my project is blocked by that issue. 

 

 

[Petr]

Also there is no workaround exists for this issue it is totally a blocking issue! I have no doubt about that.

[Stefan]

Hello, Petr,

I'm sorry to hear that this is a blocking issue which is holding the project.

The reason I set the severity to medium is our internal prioritization policy. For example, an issue that is reported a single time and does not cause JavaScript errors and it does not occurs directly in one of the core widget functionality is usually considered as Low. The High severity is used for an issue which is reported multiple times, and the Critical and Blocking are reserved in a scenario where the Grid will not render at all or a core functionality will cause a JavaScript error.

Of course, the severity can change when more customers are encountering this scenario or upon finding out additional details about the issue. I increase the priority in this case per your request as I understand that it is important to you. I also escalated it to my support manager.

I hope this provides more details on why this severity was set in this case.

Also, I used the sorting with virtualization in the suggested version 2017.2.621 and it was scrolling with no issues on my end:

https://www.screencast.com/t/xQsqIo0a

Could you elaborate what exactly isn’t working on your side?

Another option will be to use our endless scrolling feature with local data and sorting:

https://demos.telerik.com/kendo-ui/grid/endless-scrolling-local

https://docs.telerik.com/kendo-ui/controls/data-management/grid/appearance#endless-scrolling

I realize it may be a big change for your product, but if reverting to the older version doesn’t work for you I’m afraid this will be the only other option I can suggest at this moment.

Regards,
Stefan
Progress Telerik

[Petr]

[quote]Also, I used the sorting with virtualization in the suggested version 2017.2.621 and it was scrolling with no issues on my end:

https://www.screencast.com/t/xQsqIo0a[/quote]

Try to set filter to "not equals "qwerty"" for the City column.

I elaborated it enough. Reason of that happens is sorting occurs after every single virtual page loaded.

[quote]and the Critical and Blocking are reserved in a scenario where the Grid will not render at all or a core functionality will cause a JavaScript error.[/quote]

Try to reproduce that issue on the low RAM machine and you will see that it not just throwing js-error but it crashes the browser. What is a lowest RAM capacity should be installed to successfully run Kendo Grid product?

[Stefan]

Hello, Petr,

I tried setting the mentioned filter and the scroll was normal on my end again.

As for the RAM, I used the example and perform multiple scrolls and the RAM usage was not getting higher.

Could you please advise the machine parameters on which the issue is reproduced.

I tested it on a machine with 1GB of RAM and it as working normally.

Also, please advise if the suggested approach for endless scrolling is causing the same issues? 

Regards,
Stefan
Progress Telerik

[Petr]

[quote]Also, please advise if the suggested approach for endless scrolling is causing the same issues?[/quote]

The endless scroll has the same issue. Wanna have video of it?

Stefan, please answer the question do you wanna try to help me or you gonna pretend like there is no problem in software that your company are selling? 

Here is a video with scrolling the filtered grid (inPlaceSort seted to true) - https://youtu.be/CLHc6r3As4I 

[Stefan]

Hello, Petr,

I do want to help you to achieve the desired result, my manager is supervising this to ensure that we are offering all of the possible solutions in order to help you deliver the desired application.

I can suggest a couple of additional modifications which can speed up the performance.

1) In the Dojo, there are two different style themes which are creating overwhelming CSS styles over the widget.

2) Set a larger pageSize for example 100(test different ones to observe which one is giving the best results)

This is how the scrolling looks on my end after these changes:

https://www.screencast.com/t/H8tJULwi

This is the modified Dojo:

https://dojo.telerik.com/aXEKeqOd


Regards,
Stefan
Progress Telerik

[Petr]

I see several differences.

1. You are filtering by the City column. In my example filter is set to Title column.
2. You are scrolling by clicking on the scroll bar. In my example I'm using mouse wheel.

Didn't you or your manager notice that? :)

Here are videos with my use case applied to the Dojo you've provided.

• https://youtu.be/ZCezw0PBviQ
• https://youtu.be/633WCcpOwQY

Sorry for my emotions but to my mind instead of trying to reproduce the issue, you are trying to not reproduce it.

[Dimo]

Hi Petr,

My name is Dimo Dimov and I am the support lead at Kendo UI.

Let me first express my regret about the disappointment this thread has caused. I agree that exchanging multiple messages to clarify a test case and the reproduction steps can lead to justified frustration, especially if you are working on a tight schedule to release an application. That includes the case when two similar, but also different scenarios are perceived as one. Please accept my apologies.

Let me provide an overview of the situation and the next steps.

When using local data operations, the Kendo UI DataSource stores the data items in their initial non-manipulated state (i.e. non-sorted, non-filtered, non-grouped state). In order to display sorted or filtered data, the Grid executes DataSource API methods. The DataSource instance performs the desired operations in-memory and returns the expected data items. The specific "view" of the data items in the current sorted or filtered state is not stored. As a result, when paging or scrolling virtually, the same sorting and filtering operations are performed again on the whole dataset. This is a fundamental design decision that has its pros and cons, but ultimately, the way it works now saves memory. Indeed, the speed of client-side data operations will depend on the device and when there is a huge number of items (over tens of thousands), a noticeable lag may occur during virtual scrolling.

To mitigate the issue described above, the inPlaceSort property was introduced in 2017.3.913. It makes the DataSource store data items in their sorted state, which improves client-side performance during client-side paging and virtual scrolling. Testing with earlier Kendo UI versions, which do not feature inPlaceSort, will result in slow virtual scrolling indeed, because the DataSource will sort all data items repetitively, every time when new items should be rendered.

In this specific case, we were not able to observe the severe lagging shown in your videos initially, but it turns out noticable lagging does occur when we scroll near the bottom of the Grid. In any case, we admit the client-side performance will depend on the Grid configuration, the browser and the device power. It is also worth pointing out that there is no "inPlaceFilter" feature. So, using client-side filtering together with virtual scrolling and a huge number of data items will still impose a performance penalty during scrolling.

If sorting, filtering and virtual scrolling are all required features in your use case scenario, and the expected number of data items is large, then my recommendation is to resort to remote data for the best performance. I can confirm that virtualization with huge large amounts of local data is a rare use case, hence the currently assigned priority of the logged sorting bug. Nevertheless, I recognize the importance of the fix to you. I discussed it with the dev team and they will research if there is a quick way to fix it, so that we squeeze the implementation in our short-term to-do list. I expect this research to take place in the following days and will update you promptly as soon as I can.

Let me know if you need more information in the meantime. Once again, I sincerely apologize that we started off on the wrong foot in this support interaction.

Regards,
Dimo
Progress Telerik

[Petr]

I'm still pending for the following items done:

1. ETA for the issue got fixed.
2. Severety of the issue https://github.com/telerik/kendo-ui-core/issues/4053 should be increased to critical or even blocking.

[Stefan]

Hello, Petr,

The developers' team is already working on the issue with priority.

The ETA may vary depending on its complexity, giving a specific date is not a practice as you as a developer know that in our world setting a fixed ETA for an issue or a feature can be misleading as after the implementation and the tests some unplanned issues may occur that can take additional time to resolve. I just want to ensure you that the developers are working on it and are trying to fix it as soon as possible.

Once a developer starts working on it the severity is not that important as the severity determines which issue has to be resolved firsts. As the developers' are already working on it, changing the severity will not cause any difference in the time needed to fix the issue.

Apologies again for the created situation, and me and my team hope that we can fix the issue sooner, so you can proceed with releasing the application.

I will close the ticket(not this forum) for now so we can keep all of the details and the conversation in one place. I will keep you posted in this thread on the state of the issue.

Regards,
Stefan
Progress Telerik

[Petr]

Can I finally know an ETA? I've posted an issue on March the 3rd, your team spent enough time to post an ETA for the issue to my mind!

[Petr]

[qutoe]I will close the ticket(not this forum) [/quote]

Nope, I wish to have ticket opened while my issue wasn't solved! Please reopen it if you already closed it! 

 

Can I finally know an ETA? I've posted an issue on March the 3rd, your team spent enough time to post an ETA for the issue to my mind!

[Stefan]

Hello, Petr,

I'm glad to inform you that the developer has already pushed a fixed on the issue. Once it has been tested by the QA team the QA engineer will set the milestone which will point to when the fix will be available for download.

Please have in mind that our next official release is planned for the middle of May.

We may publish it in an internal build, but they are available only to accounts with full license, so please make sure to use that account when logging as the Trial accounts do not have access to the internal builds.

Please monitor the issue for the official ETA for the fix which will be set by the engineer once the issue is closed.

Regards,
Stefan
Progress Telerik

[Petr]

That's really nice to hear! Please let me know when the fix will be available for licensed users.

[Stefan]

Hello, Petr,

The issue is already closed.

We are planning to release the fix and an internal build by the end of this week.

Once the internal build it available I will let you know, so you can download it as soon as possible.

Apologies again for all of the frustration caused by this issue I hope that in the future situations like this will be handled better.

Regards,
Stefan
Progress Telerik

[Petr]

Thanks a lot! Nice job! Can't wait to try it! :)

[Stefan]

Hello, Petr,

I'm glad to inform you that the internal build with the fix is already available for download.

It can be downloaded from your profile directly:



I hope that the fix will allow the application to run smoothly with no undesired side effects.

Regards,
Stefan
Progress Telerik

[Petr]

Thanks a lot guys! I'd just checked issue is gone! The 2018.1.322 build works great!