Question on calling grid.setViewState and grid.setFields with large number of fields

[senordhuff]

Hello,

Our application has one main grid that has a large number of fields. The current count is at about 700 and growing. This creates a variety of performance problems for us.

One use case that presents a problem is that we have a list of views where a user can choose grid view states they have created. When they select a view, it calls grid.setViewState and the subsequent call to grid.setFields is taking 1 second or longer by itself. Then, after the browser finishes actually resetting view state, it often takes 4-5 seconds before the user gets control back.

We are looking for ways to speed this up. This is a serious issue that is preventing us from getting traction with our users. The users typically only show 10-12 fields at one time. So, I'm wondering if there is some better way to do this to avoid the performance penalty associated with calling setFields every time we call setViewState?


One idea I have is to instantiate a brand new grid each time they change views with only the visible fields they want to see. The challenge is how to present the user with a Column Chooser so they can add any other fields they want that aren't currently visible. But, I'd like to know if you have any thoughts or suggestions?

[Isomorphic]

It sounds like your use case is quite an unusual UI - a grid with ~10 visible columns and ~680 hidden columns.

It seems there are two ways to attack this:
Firstly your numbers for how slow the setViewState call is seem pretty high, especially if we're talking about only ~10 actually visible fields. Can you show us a standalone sample demonstrating a grid with a similar field configuration which we can run to see this poor performance?
Once we see the problem in action it may be something we can address in the framework directly - though we can't make any guarantees until we have an idea what's going on.

Secondly - it sounds like your proposed workaround,or something similar may be a sensible alternative.
From your description it sounds like, depending on the task the user is performing, they probably want to see a manageable subset of fields which relate to some specific view at any time and then just have the option to pick a (small number) of extra fields to add. You could certainly pass just your small set of options to 'setFields' as a default and then support some other UI for picking additional fields. We have examples of adding custom logic to the ListGrid header menu so you could take that approach if it made sense.

However if you can show us this case with large numbers of hidden fields profoundly effecting the time to setViewState we will take a look and see if there's a way to improve things at the framework level.

Regards
Isomorphic Software