FlexGrid column.visible=false, item.prop=undefined and CollectionView.getError

FlexGrid column.visible=false, item.prop=undefined and CollectionView.getError

Posted by: steidle on 1 January 2024, 5:40 am EST

• 

  steidle

  • Post Options:
  • Link
    Copy
  • Jump To Answer

  Posted 1 January 2024, 5:40 am EST - Updated 1 January 2024, 8:38 am EST

  I just updated to Wijmo v20232 and the selection on my FlexGrids has stopped working.
  
  I managed to narrow the problem down to this combination, which no longer works:

  • column.visible=false
  • item.property undefined
  • CollectionView.getError function defined (returning null == no error)

  Older version of Wijmo where the above combination works:
  
  https://stackblitz.com/edit/ng11-wj20213-grid-colinvis-noval-geterror
  
  (Still worked on 20221 or 20222, sorry I do not remember what version I had before)
  
  Not working on latest version:
  
  https://stackblitz.com/edit/wj20232-flexgrid-col-invisible-noval

  I have defined the order and editing behavior of my columns in JS code and only a few of them are visible initially. Things like type or if an column is required is set when a column really gets used and is loaded from the database. So I would want to avoid having to specify dataType or isRequired on all my columns (which solves the problem).
  
  Has something changed in your code running before CollectionView.getError ? Value coercion on dataType Object?
  
  Edit: I just went through your ChangeLog.txt of 5.20232.939 and noticed this might be related to WJM-26326 fixed in 5.20231.900. Going back to build 5.20231.888 is unfortunately not an option as I have also already updated to Angular16.

• 

  anirudh.verma

  

  • Post Options:
  • Link
    Copy

  Posted 2 January 2024, 7:57 am EST

  Hi,

  Thank you for sharing a working sample. In my investigation, I have observed that the issue occurs for PureJS. Since, you are defining Flexgrid in PureJs way so it is causing the observed behavior. This is happening because the default dataType of “City” column is set to “Object”. This causes the validation of cells present in that column. This was not done in previous versions. I have escalated this to the development team for further investigation. Please note the internal tracking id of the issue for further communication on the issue: WJM-32997

  Meanwhile, as a workaround,

  • I would recommend you to use the Angular Markup syntax to define the FlexGrid. Please refer to this sample for reference: https://stackblitz.com/edit/wj20232-flexgrid-col-invisible-noval-s1rxj5
  • If there is any specific use case because of which you are using PureJS way to define FlexGrid in Angular then you may overwrite a default method that checks if a particular cell is requried or not. Please refer to this sample for reference: https://stackblitz.com/edit/wj20232-flexgrid-col-invisible-noval-r69hq8

  If there is any specific use case of defining FlexGrid in ngOnInit() then please let us know.

  Thank you for your understanding.

  Regards

• 

  steidle

  • Post Options:
  • Link
    Copy

  Posted 4 January 2024, 3:35 pm EST - Updated 4 January 2024, 3:41 pm EST

  Hi
  
  Thanks for your answer and escalating the issue. I noticed on other columns that they have type Object while the type is not set. But not sure why one would want to validate an undefined value that is neither visible nor explicitly required…
  
  I am extending FlexGrid to a PersonGrid which is used in multiple places. The scaffolding of the PersonGrid will have to work with different sets of columns for different use cases. I know I can derive from WjFlexGrid, too, but for know I enjoy the greater flexibility of pureJS. Just easier to juggle with arrays of columns .
  
  So I went with you second solution, which indeed fixes the problem.
  
  There is no specific reason I am initializing FlexGrid in ngOnInit(). Could this be problematic?
  
  Where can I follow what happens with WJM-32997? Will I get a notice?

• 

  steidle

  • Post Options:
  • Link
    Copy

  Posted 5 January 2024, 2:50 am EST - Updated 5 January 2024, 3:27 am EST

  [deleted - related symptom / console warning, but managed to solve it on my side]

• 

  anirudh.verma

  

  • Post Options:
  • Link
    Copy

  Posted 5 January 2024, 5:18 am EST

  Hi,

  Thank you for notifying me that the second solution was helpful to you.

  There is no known issue in creating FlexGrid in ngOnInit() using pureJS but, it is recommended to use the Angular markup syntax (as described here: https://developer.mescius.com/wijmo/docs/GettingStarted/Angular-Components#angular-markup-syntax).

  Related to “Where can I follow what happens with WJM-32997? Will I get a notice?”, currently the issue is with DEV team. I will update you as soon as I get any update from the DEV team. Meanwhile, you may use this id(WJM-32997) to ask for the updates in case it gets delayed.

  Thank you.

  Regards

• 

  steidle

  • Post Options:
  • Link
    Copy

  Posted 27 April 2024, 6:14 am EST

  Any news on a fix for WJM-32997 ?

• 

  vivek.pannu

  

  • Post Options:
  • Link
    Copy

  Posted 30 April 2024, 1:22 am EST

  Hi Steidle,

  The dev team is still working on this, we have asked them to prioritize this issue. We will update you when we have more information from the dev team.

  Regards

• 

  steidle

  • Post Options:
  • Link
    Copy

  Posted 16 May 2025, 10:09 am EST

  Hi!
  
  I never got any update on this. Nor does WJM-32997 show up in any of the changelogs of recent Wijmo versions.

  I just upgraded the stackblitz sample to ng19 and Wijmo 20251. The problem still persists.
  
  https://stackblitz.com/edit/ng19-wj20251-grid-column-invisible-no-value-bug?file=src%2Fmain.ts%3AL5

  Is it safe longterm to stay with the solution provided by anirudh.verma which overwriters Column.prototype.getIsRequired(e)

• 

  vivek.pannu

  

  • Post Options:
  • Link
    Copy

  Posted 20 May 2025, 12:10 am EST

  Hi,
  
  The engineering team has considered this behavior as expected behavior, that when the ‘isRequired’ property of a column is set to true, and the getError method is set, then the cell in the edited row will be highlighted as an error cell if it fails the required validation. You can set the ‘isRequired’ property of that column to ‘false’ to avoid this behavior if needed, or you can keep using the previous workaround we suggested by overriding ‘getIsRequired’ method.
  
  We also encountered some other issues with cell selection when a required column that fails the validation check is hidden, the engineering team is working on that. The same workaround can be used to avoid this issue also. Overall, you can keep using the current workaround it is safe for long-term usage. We will share more updates when we have information available.
  
  Regards

• 

  steidle

  • Post Options:
  • Link
    Copy

  Posted 20 May 2025, 5:26 am EST - Updated 20 May 2025, 5:41 am EST

  Hi Vivek,

  Thank you for your reaction. I will keep the hack with overwriting Column.prototype.getIsRequired()

  I would not be complaining if Column.isRequired would be true!! But in this case it is undefined, also in the latest sample code on stackblitz. In the docs
  
  https://developer.mescius.com/wijmo/api/classes/Wijmo_Grid.Column.html#isrequired
  
  it says that only some specific datatypes are validated in this case.
  
  In my case dataType is also null/undefined for which it says in the docs: The default value for this property is null, which causes the grid not to perform any data type coercion. Taking this into account, not sure if you could still say what I experience is expected behavior.
  
  Bottom line: getError() validation is run and complains in a case where very few is known about the nature of the column/propery: No datatype, not explicitly required. And then how should the user introduce an error in a column that it not visible.
  
  Your colleague anirudh.verma says above on dataType for v20232 (were the problem first appeared): “This is happening because the default dataType of “City” column is set to “Object”. This causes the validation of cells present in that column. This was not done in previous versions.” So your internal conversion from dataType “unkown” to Object has an unforseen side-effect. Maybe this is useful for your analysis.
  
  I would have appreciated if the change in behavior would have been listed as breaking change. I am fine for now. Good luck to your engineering team in finding a solution which solves this and the connected issues you mention. Looking forward to hear back from you.

• 

  vivek.pannu

  

  • Post Options:
  • Link
    Copy

  Posted 21 May 2025, 5:52 am EST

  Hi Andreas,

  We have shared this information with the engineering team along with the request to add this change to the list of breaking changes, if possible. We will update you when we have more updates from the engineering team.

  Regards