Odoo Changelog — 2023-05-12

Friday, May 12, 2023

1 change

Refactoring(1)

Code cleanup and technical improvements

[REF] pos*: use fine grained reactivity instead of deep renders

Enterprisemasterl10n_mx_edi_pospos_l10n_sepos_settle_dueMEDIUM

The point-of-sale interface now updates only the screen elements affected by a change, instead of redrawing the whole interface each time. This makes the system easier to maintain and can improve responsiveness in areas with large product lists or active payment workflows.

Original PR description

*: l10n_mx_edi_pos, pos_l10n_se, pos_settle_due The code of the pos was one of the first adopters of owl 1, as such, the code was not initially written to take full advantage of the owl reactivity…

*: l10n_mx_edi_pos, pos_l10n_se, pos_settle_due

The code of the pos was one of the first adopters of owl 1, as such, the code was not initially written to take full advantage of the owl reactivity system that would eventually make its way into owl 2. In order to convert the code quickly when migrating to owl 2, a big shortcut was taken: whenever something in the state of the pos changed, the entire UI would be rerendered. While this works decently well in practice, it can create confusing situations because the mental model needed to understand how components work in the pos is different from the rest of the code base.

This commit changes the existing code to use the typical fine-grained reactivity model used everywhere else: components individually subscribe to the pieces of state that they use and will rerender on their own when this state changes. In order to achieve this, the pos global state has been removed from the environment and should now be access through the use of the custom hook `usePos` which will subscribe the component to the state that it reads. This also has some minor performance benefits as we only render the parts of the UI that actually need to update whenever there is a state mutation, instead of the entire UI which can be expensive in some cases (eg, the product screen will filter all products during rendering to find only the products that match the search, which is expensive when there are a lot of loaded products)

Linked to: https://github.com/odoo/odoo/pull/120992

#point-of-sale#performance#maintainability

*: l10n_mx_edi_pos, pos_l10n_se, pos_settle_due The code of the pos was one of the first adopters of owl 1, as such, the code was not initially written to take full advantage of the owl reactivity system that would eventually make its way into owl 2. In order to convert the code quickly when migrating to owl 2, a big shortcut was taken: whenever something in the state of the pos changed, the entire UI would be rerendered. While this works decently well in practice, it can create confusing situations because the mental model needed to understand how components work in the pos is different from the rest of the code base. This commit changes the existing code to use the typical fine-grained reactivity model used everywhere else: components individually subscribe to the pieces of state that they use and will rerender on their own when this state changes. In order to achieve this, the pos global state has been removed from the environment and should now be access through the use of the custom hook `usePos` which will subscribe the component to the state that it reads. This also has some minor performance benefits as we only render the parts of the UI that actually need to update whenever there is a state mutation, instead of the entire UI which can be expensive in some cases (eg, the product screen will filter all products during rendering to find only the products that match the search, which is expensive when there are a lot of loaded products) Linked to: https://github.com/odoo/odoo/pull/120992