We have encountered a second, very significant problem with horizontal scrolling in igx-grid:
If the grid is scrolled all the way to the right and the existing set of columns is replaced, the grid will be irretrievably broken.
We have a grid that has the potential to have a very large number of columns. In order to make this manageable for our users, we allow them to save different sets of columns in views that they can switch between.
Because the users can move columns to different positions, we can just use a single set of columns and update them when the user wants to change the view.
The problem that we stumbled into is when the grid was scrolled all the way to the right and the new set of columns was loaded, an exception similar to the following was thrown:
Cannot read properties of undefined (reading 'context') at IgxGridForOfDirective._updateViews (webpack://ps/node_modules/@infragistics/igniteui-angular/fesm2022/infragistics-igniteui-angular.mjs:16000:0) at IgxGridForOfDirective._applyChanges (webpack://ps/node_modules/@infragistics/igniteui-angular/fesm2022/infragistics-igniteui-angular.mjs:16011:0) at IgxGridForOfDirective.ngDoCheck (webpack://ps/node_modules/@infragistics/igniteui-angular/fesm2022/infragistics-igniteui-angular.mjs:15818:0)
Once this exception was thrown, the user could no longer use the grid until they reloaded the page and, in some cases, the grid code or angular went into an infinite loop.
We were able to work around by asking the grid's navigation service to scroll to the first visible, non-frozen cell. We then had to issue a window.timeout to perform the column changing.
This, to us, seems like a fairly fundamental problem in the scrolling code that we probably shouldn't have to have a window.settimeout workaround for.
Hello Lance,
Thank you for posting into our community!
I have been looking into your question and what I understand is that you have a data source with many columns, for example:
const DATA = [ { prop1: 1, prop2: 2, prop3: 3, prop4: 4, ... prop20: 20 }, ... ];
and in one "view" you display, for example, the first 10 columns (prop1 to prop10), and when switching the view, you set the columns to be from prop11 to prop20. Could you please confirm if my impression is correct?
If it is correct, what I could suggest, in order to display different sets of columns in different views and allow the built-in functionalities of the IgxGrid, such as column pinning, column moving, etc., is defining a second IgxGrid component that contains the information for the second "view" and show/hide it whenever the user wants to change the view. This way every grid will manage its own set of columns and will allow its built-in column managing functionalities without any additional configurations.
Here could be found a small sample demonstrating my suggestion and the result could be observed in the below attachment:
Please test it on your side and let me know if you need any further assistance regarding this matter.
Additionally, if this is not an accurate demonstration of what you are trying to achieve, please feel free to modify it and send it back along with steps to reproduce.
Looking forward to your reply.
Sincerely, Riva Ivanova Associate Software Developer
Unfortunately this suggestion won't work for us. The columns are variable and can change from customer to customer and user to user. And one user could have 2 views while another might have 20.
The key to reproducing the problem is to use the same columns but in different order and with some removed.
I can't save the updated version at the moment, but changing columns2 to the following:
Thank you for following up!
I was able to reproduce the described behavior after following the listed steps.
Having this in mind, I have logged it in our GitHub repository here and prioritized it accordingly.
Any concerns or questions that you have can be directly addressed in the issue, which will give you the opportunity to directly communicate with our development team and any new information along with the progress in resolving it can be found there.
In the meantime, I would suggest using the workaround approach that you have mentioned in your initial post.
Please let me know if you need any further assistance regarding this matter.