Repeated entries of the same value are dropped

Repeated entries of the same value are dropped

Posted by: taran.twomey on 19 February 2024, 5:03 pm EST

• 

  taran.twomey

  • Post Options:
  • Link
    Copy

  Posted 19 February 2024, 5:03 pm EST

  When editing a cell within the flexgrid, if you enter the same value in multiple times these changes are all dropped before they are assigned to the underlying row model. This makes sense somewhat from an efficiency standpoint, but we have recently had a need to ensure that even when the same value is re-entered into a cell our data item’s setter is still called. This does not seem to be configurable in any way in the grid, and subsequent re-entries are just dropped.

  What is the reccommended way to achieve this functionality?

  I have created a demo below that can quickly showcase the issue. What I want is for it to be able to re-emit the same value into the console each time I enter it into the same cell.

  demo: https://jscodemine.mescius.io/sample/0_TxR4BIC0Gzx6lWjomkmQ/

• 

  anirudh.verma

  

  • Post Options:
  • Link
    Copy

  Posted 20 February 2024, 4:10 pm EST

  Hi Taran,

  We are sorry for the inconvenience caused. There is no direct way to configure this behavior in the FlexGrid. The new value is checked for equality with previous value before getting set in the appropriate method. So, the setter is not called in case the value is same.

  However, could you please elaborate more on the use case? Specifically, why there is a need to call the setter of the modal property even if the new value is same as the previous? It would help me to suggest some better alternatives (if any) as per your use case.

  Thank you for your understanding.

  Regards

• 

  taran.twomey

  • Post Options:
  • Link
    Copy

  Posted 20 February 2024, 4:57 pm EST

  Hi Anirudh,

  Our integration with Wijmo leverages a virtual ‘expand and collapse’ of rows because the in-built capabilities of the grid do not offer the features that we need. When a group of rows is collapsed we remove them from the grid’s collection view, leaving just the parent row that preserves the parent to child relationship.

  In this case we still need to coordinate edits to the cell in the collapsed row so that they ‘flow through’ to the corresponding collapsed rows, because these collapsed rows might not hold the same values.

• 

  anirudh.verma

  

  • Post Options:
  • Link
    Copy

  Posted 21 February 2024, 5:08 pm EST

  Hi Taran,

  I apologize for the confusion, but could you please provide confirmation about the following points:

  As per my understanding you are not using the default collapse and expand option that is provided by FlexGrid for group rows. Please refer to this DEMO that demonstrates the default collapse and expand functionality: https://developer.mescius.com/wijmo/demos/Grid/Grouping/Groups/angular

  Instead of this you have implemented a custom functionality to expand and collapse the group rows.

  Also, you are removing the child rows when the group row is collapsed. Please correct me if I am wrong but you are doing this for some performance reason. Please elaborate the same as by default the cells for the collapsed rows are not attached to the DOM so there is no need to remove the rows from the CollectionView. Also, removing the collapsed rows from the collectionView will interfere with the default grouping mechanism of the FlexGrid and might lead to unexpected behavior. So, if possible, please elaborate on the necessity of removing the collapsed rows from the collectionView.

  As mentioned, you are editing the cell of the collapsed rows, could you please let us know if you are referring to the cells present in the GroupRow or if you are directly editing the value using the code for the collapsed rows?

  **Please provide the detailed explanation on the use case and the necessity of using custom implementation for collapse and expand functionality along with the need of removing the collapsed rows from the CollectionView.
  
  **
  
  It would be really helpful if you could share a minimum working sample demonstrating this implementation along with the issue.

  Please note that if your response contains some private information then you may create a ticket on our private support portal: https://developer.mescius.com/my-account/my-support

  Thank you for your understanding.

  Regards

• 

  taran.twomey

  • Post Options:
  • Link
    Copy

  Posted 22 February 2024, 2:41 pm EST

  Hi Anirudh,

  I have created a syntehtic example using my last sample to showcase a simple structure that fits what we are doing, from a generic standpoint. This sample may not make immediate logical sense (in terms of content of the grid - downloads and grouped countries seem a bit strange), but the actual backing model and how it is used showcases our requirement/issue.

  demo: https://jscodemine.mescius.io/sample/MhhDR5I70E_zVvAiFmF5aQ/

  I will also quickly answer your questions from above.

  You are correct in your assumption that we do not use Wijmo’s grouping of rows for the expand and collapse functionality. This is because Wijmo GroupRows and regular rows do not share the same DNA/functionality at times, meaning that we cannot use a group row as a regular row entry (as if it were any other row when expanded), which was a requirement for us. We also wanted to be able to enter values into cells within an expanded row, which would not be possible and easy OOTB with group rows. Please refer to the provided demo for an additional look at the functionality.

  As to your point about removing rows, we have previously raised an issue about rows/columns being marked as visible=false within Wijmo grids causing significant, extreme slowdown in performance (especially with large volumes of data that are hidden). Here is a link to the forum post we made originally about this issue: https://developer.mescius.com/forums/wijmo/grid-performance-degrades-significantly-when-rows-are-hidden . The internal tracking ID was WJM-23060.

  As such, our solution instead entirely removes them from the Wijmo row collection, and manages them separately using the collapsed/expanded concept showcased in my demo. The default grouping of rows is not affected in our use case because our group rows (which we do use, just not for their collapse/expand functionality) do not make use of default Wijmo behaviour (like aggregates, counts etc.), and instead render custom content within them, so we can manage them easier.

  We do not edit cells with Wijmo GroupRows for this specific use case (but have done this before), but we do edit cells within our ‘collapsed’ row, as showcased by the demo.

  Let me know if you need any more of an explanation, or if more information about the demo is needed.

• 

  anirudh.verma

  

  • Post Options:
  • Link
    Copy

  Posted 22 February 2024, 10:43 pm EST

  Hi Taran,

  Thank you for explaining the use case and providing a working sample demonstrating your approach.

  As per my understanding, the requirement to call the setter even when the cell contains the same value is because, when a group is collapsed(Only group row is visible), then if the cell in that groupRow (PrimaryRow as per the sample) is edited and the same value is provided again then all the child rows (SecondaryRow as per the sample) should contain the same value for that column.

  If this is the requirement, then you can explicitly set the value for that specific property by handling the cellEditEnded event. The approach for this would be to store the current entered value and the previous value of the cell by handling the cellEditEnding event. Then, in the handler of the cellEditEnded event you may check if the current row is a groupRow/PrimaryRow and if the new and previous value is same or not. If it is same then you can directly change the value of the downloads property of the PrimaryRow instance. This will call the setter and hence all the child rows will be updated with the same values.

  Please refer to this code snippet:

      // Store the current and previous value of the cell.
      handleCellEditEnding(sender: wjcGrid.FlexGrid, args: wjcGrid.CellEditEndingEventArgs) {
          this.currentValue = sender.activeEditor.value;
          this.previousValue = sender.getCellData(args.row, args.col, false);
      }
  
      // Update the value of the child rows' dataItem if the value is same.
      handleCellEditEnded(sender: wjcGrid.FlexGrid, args: wjcGrid.CellRangeEventArgs) {
          let dataItem = args.getRow().dataItem;
          // If this cell belongs to PrimaryRow.
          if (dataItem instanceof PrimaryRow && dataItem.group.isCollapsed && this.isValueChanged() && args.getColumn().binding === "downloads") {
              console.log("using cellEditEnded to change the data for child rows as the groupRow already contains the same value for this cell");
              // If it is a numeric value.
              if (!isNaN(Number(this.currentValue)))
                  dataItem.downloads = Number(this.currentValue);
              // Reset the variables.
              this.currentValue = this.previousValue = null;
          }
      }
  
      isValueChanged(): boolean {
          if (this.currentValue === this.previousValue === null)
              return true;
          //
          if (this.currentValue && this.previousValue && this.currentValue === this.previousValue.toString())
              return true;
          //
          return false;
      }

  Please refer to this modified sample for reference: https://jscodemine.mescius.io/share/BGqvKx9XfE2o6shcC8ATNw/

  Also, just in case if you want to use the default group row for managing the child items then allow me to share the following information about them. Regarding the structure of the GroupRow and Data row, GroupRow is inherited from the Row (DataRow) which itself is inherited from the RowCol class. The major change is how they handle the dataItem that is associated with them. For example, the data row contains the simple object from the sourceCollection in the dataItem property. While the GroupRow contains the instance of the CollectionViewGroup class. This CollectionViewGroup instance contains the child items, name of the group, level of the group and the criteria for grouping the items. Please refer to the following links for reference:

  • GroupRow: https://developer.mescius.com/wijmo/api/classes/wijmo_grid.grouprow.html
  • Row: https://developer.mescius.com/wijmo/api/classes/wijmo_grid.row.html
  • RowCol: https://developer.mescius.com/wijmo/api/classes/wijmo_grid.rowcol.html
  • CollectionViewGroup: https://developer.mescius.com/wijmo/api/classes/wijmo.collectionviewgroup.html

  I hope this information helps in better integration of FlexGrid with your usecase.

  Thank you for your understanding and patience.

  Regards
  
  Anirudh