Infinite onWillUpdateProps Loop Triggered by Setting State to NaN via useSubEnv Callback

[kig-odoo]

Components Involved

• Root (parent component)
• ChildComponent

Summary

In my setup:

• The Root component manages state and passes the noProxy object as props to the ChildComponent, derived from its state.
• Additionally, Root provides a callback function (notifyParentComponent) to ChildComponent using useSubEnv, so that the child can trigger updates in the parent.

The issue arises when notifyParentComponent sets NaN to any of the Root’s state keys (note: this key is not part of the props passed to ChildComponent). Once this happens, the onWillUpdateProps lifecycle method starts getting called in an infinite loop.

Playgroud

Click the button in this example to observe the issue:

[sdegueldre]

This is caused by the fact that NaN === NaN is false. You can observe the same behavior if you notify the parent with an object literal or any other value that doesn't compare equal between renders. Whether NaN should be special cased is an open question but it's not obvious that it should. In general modifying parent state in willUpdateProps seems like a very bad idea.

[kig-odoo]

Thanks for the quick feedback. I understand the reason behind the behavior now, especially the NaN === NaN comparison and how values that don’t compare equal across renders can lead to unexpected results.

I might be approaching this the wrong way, but I’d appreciate your thoughts on a better solution. In my case, I have a standalone screen with a parent component that contains filters. These filter values are passed as props to a child component, which is responsible for fetching data and performing some processing (e.g., calculating the subtotal of the fetched records). The processed data then needs to be passed back to the parent component.

What would be a more robust or idiomatic way to handle this kind of child-parent communication and state update?

I’d greatly appreciate your guidance on this.

[ged-odoo]

We have some training materials for owl: https://docs.google.com/presentation/d/1iDQxiS--8g394R-4z7uIQYGEfj1C1NJsKU1Fk5EuZFE/edit?slide=id.g312004fbf51_1_25#slide=id.g312004fbf51_1_25 You can look at part 4 (around slide 101), to have a look at various strategies to manage state and communicate between components.

Usually, it's better to have a parent -> child workflow. So, a common solution is to move the state fetching/handling in the parent component, or a standalone class that will acts as a model.

[kig-odoo]

Thanks so much, Gery! I’ll go through part 4 carefully.

Also, I just wanted to say, you and your team have done such amazing work. OWL has truly made developers’ lives so much easier. On my side, I recently built a heavy screen for one of my projects and managed to integrate OWL into Odoo v13 (since the customer didn’t want to migrate to a newer version). I made sure the new development would be easy to migrate in the future if needed. OWL saved me countless hours and really made my life easier.

Thank you!