CollectionView.getError Breaking Change (version 5.20241.9)

Posted by: amakarenko on 4 April 2024, 6:04 pm EST

  • Posted 4 April 2024, 6:04 pm EST

    https://jscodemine.mescius.io/sample/cpFHtu9GXkaaigpvSLkhfQ/

    Test case 1:

    • Have a grid with a column that omits type or isRequired definition
    • Have a data payload with values equal null in this column
    • Enable CollectionView.getError
    • Result: the cells are highlighted erroneous, with a message “Please fill out this field.”
    • Expected: no validation to be enforced for this column (this was behavior in previous versions)

    Test case 2:

    • Based on Test case 1 source code
    • Edit source code and add isReadOnly: true property to the grid initialization
    • The cells are still highlighted as erroneous, but now they are not editable
    • Select one of the erroneous cells (e.g. on the row 1), then select another cell in the same column (e.g. row 2)
    • Result: the grid starts uncontrollably flickering, appearing to be jumping around between selection of erroneous cells. This seizes up user interface and makes impossible to do anything

    Notes:

    This code example is forked from the example published on the Demos website: https://developer.mescius.com/wijmo/demos/Grid/Editing/CollectionViewValidation/purejs

    In my fork, I short-circuited the getError() function so it always returns null (e.g. no error). The described issues disappear, if we simply delete the getError from collection view definition.

    According to documentation, when column definition dataType is omitted, it defaults to DataType.Object (0) - it should not enforce any validation.

    Also why is the validation enforced only when CollectionView.getError is present?

    I was able to work around it by setting isRequired: false in the column definition. The problem is that we have a portfolio of existing apps that would break if updated to version 5.20241.9

  • Posted 5 April 2024, 9:07 am EST

    Hi,

    We have forwarded this issue to the dev team for further investigation with internal tracking ID - WJM-33692. For now, please use the workaround that you shared, i.e. to set the ‘isRequired’ property of the Column to false.

    We will update you as soon as we have some updates from the dev team.

    Regards

  • Posted 11 June 2024, 10:23 am EST

    Hi Vivek -

    Do you have any updates on this issue?

  • Posted 12 June 2024, 6:42 am EST

    Hi,

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

    Regards

  • Posted 28 June 2024, 8:07 am EST

    Also seeing similar issues with CollectionView.getError. Any updates on WJM-33692?

  • Posted 1 July 2024, 8:06 am EST

    Hi Jonathan,

    The dev team is still working on this issue. We have asked them for more updates, we will update you when we have more information about the issue.

    Regards

  • Posted 16 July 2024, 9:24 am EST

    Hi Makarenko,

    As per the current investigation, inconsistent behavior is observed in FlexGrid for showing error messages in different scenarios, so the dev team is planning to add a grid-level mechanism to control how the Column Level validation should be displayed i.e. either in ToolTip, Title, etc. You will simply have to use this new mechanism to control how the isRequired validation error appears in the grid. Could you please confirm, if it would solve your issue or not?

    Regarding the validation enforcement that keeps the grid in edit mode until a valid value is entered, you can control this using the ‘validateEdits’ property of the FlexGrid. Here’s the API link for the same -

    https://developer.mescius.com/wijmo/api/classes/wijmo_grid.flexgrid.html#validateedits

    Please let us know if you have any more suggestions from your side regarding this.

    And the new reference ID for the second issue you mentioned in your first comment is - WJM-34412.

    Regards

  • Posted 27 September 2024, 10:46 am EST

    Hi Vivek,

    I don’t see how “new mechanism” can help me, since it does not exist yet. The isRequired behavior change breaks existing apps.

    The validateEdits setting does not solve it either. The validation enforcement that keeps grid in edit mode is not a problem - the problem is that it has validation errors get triggered in the first place. The isRequired default behavior was different in your earlier versions, it did not trigger the error

  • Posted 1 October 2024, 12:30 am EST

    Hi Makarenko,

    We have shared this information with the engineering team, we will update you when we have more information on this issue.

    Regarding your second issue, i.e. continuous selection flickering in grid, this issue has been fixed in the latest version of Wijmo i.e. 5.20242.21. You can verify the same in the following sample - https://jscodemine.mescius.io/share/vKN8SZVBik_0JoFg-EDy9Q/

    Regards

  • Posted 8 October 2024, 7:59 am EST

    Hi Makarenko,

    We have an update from the engineering team, this issue has been fixed in the latest nightly build of Wijmo, you can verify it in the following sample - https://jscodemine.mescius.io/share/9gfLaUcgOky3nQaxqS4vpQ/

    Could you please confirm, if your issue will be resolved with this fix or if there is something we missed?

    You can specify the ‘nightly’ keyword instead of Wijmo package version in your package.json file to download the latest nightly version of Wijmo.

    Regards

  • Posted 9 October 2024, 11:51 am EST

    Hi Vivek, I have tested the nightly build: looks like it behaves correctly.

  • Posted 10 October 2024, 5:30 am EST

    Hi Makarenko,

    Thank you for the confirmation. The fix will be included in the upcoming stable Wijmo release.

    Regards

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels