Wj-multi-select infinite loop firing checkedItemsChanged

Wj-multi-select infinite loop firing checkedItemsChanged

Posted by: sp7 on 20 December 2017, 12:13 am EST

• 

  sp7

  • Post Options:
  • Link
    Copy
  • Jump To Answer

  Posted 20 December 2017, 12:13 am EST

  In the most recent version, 5.20173.380, using the multi-select on 2 different sections of the page, but having checkeditems bound to the same object causes it to fire checkeditemschanged in an infinite loop. This did not happen in version 5.20172.334.

  We noticed this as the cpu usage in Chrome 62 and 63 stayed consistently high when nothing was being performed on the page.

  Below is a plnkr example of the problem.
  
  http://embed.plnkr.co/js6vVr5ndSmOsLSTPekG/

• 

  manish.gupta

  

  • Post Options:
  • Link
    Copy

  Posted 20 December 2017, 8:45 pm EST

  Hi,
  
  Thanks for reporting the issue and sample. We are able to replicate the issue at our end and it seems a bug. Hence, this issue has been forwarded to the concerned team for further investigation with tracking id 301903.
  
  We will let you know as we get any update on this.

  ~Manish

• 

  manish.gupta

  

  • Post Options:
  • Link
    Copy

  Posted 2 January 2018, 8:36 pm EST

  Hi,
  
  It caused by the breaking change introduced in build 351 - two-way bindings became asynchronous.

  This can be changed by setting the asyncBindings property to false on wj-multi-select components, like shown here:

  http://plnkr.co/edit/pxfaoajS3ELDIRGFZ1Td?p=preview

  But the best way to solve this is to leave the bindings asynchronous and rework the host component’s selectedItem property, by turning it to a true property with a “smart” setter that keeps its own array instance and updates it only if the new assigned array’s content is different from the current one:

  http://plnkr.co/edit/MH3tiKZ5ZAYLNMoAgaJ6?p=preview

  ~Manish

• 

  sp7

  • Post Options:
  • Link
    Copy

  Posted 11 January 2018, 12:50 am EST

  Thanks! The “smart” setter approach worked for us.