odoo/o-spreadsheet#4104

Created by BI, Lucas Lefèvre (lul)

label

odoo:saas-17.2-stores-bye-reactivity-lul

head

5f4bcfcc075d6972f1fb4aff2c3024fa78129412

merged

2 years ago by BI, Rémi Rahir (rar)

	odoo/o-spreadsheet
saas-17.2	#4104
saas-18.2
saas-18.3
saas-18.4
19.0
saas-19.1
master	#4244

[FIX] stores: bye bye reactivity 👋

Description:

Reactivity is very very (very) slow, with potential overhead exceeding 90%.

With a reactive store, every this.something call traverses the reactive
proxy, incurring significant cost.

This commit completely revisit the way store updates trigger app rendering.
Previously, this process relied entirely on Owl's reactivity system.

Instead, it introduces a new approach where store updates are triggered by
explicitly declared public methods (mutators)
Since stores follow the CQS principle all public methods actually
mutate state in a store, they cannot have any other effect since they
can't return anything.

The new approach also relies on proxies to track mutators calls, but
the proxy is only on the surface. A mutator is usually only called once
in the component. A properties is also usually accessed only once for
rendering. The internal working of the store is not affected and can
run at full speed without any overhead.

Note the loss of fined-grained rendering. However, as observed, bypassing
reactivity might result in faster overall app rendering compared to
relying on reactivity for fine-grained rendering, even if it means rendering
the entire app rather than a few components.

Reactivity had another unexpected error-prone issue: since everything
was proxied, we could never compare objects references without using
toRaw to retrieve the underlying un-proxied object. It was very
error prone and added noise in the code.

On the large number data set, open the find & replace panel and search for "1"
It currently takes 1080ms (search + rendering)
With this commit, that time is reduced to just 111ms, nearly a tenfold
improvement!

Task: : 3829125

review checklist

• [ ] feature is organized in plugin, or UI components
• [ ] support of duplicate sheet (deep copy)
• [ ] in model/core: ranges are Range object, and can be adapted (adaptRanges)
• [ ] in model/UI: ranges are strings (to show the user)
• [ ] undo-able commands (uses this.history.update)
• [ ] multiuser-able commands (has inverse commands and transformations where needed)
• [ ] new/updated/removed commands are documented
• [ ] exportable in excel
• [ ] translations (_t("qmsdf %s", abc))
• [ ] unit tested
• [ ] clean commented code
• [ ] track breaking changes
• [ ] doc is rebuild (npm run doc)
• [ ] status is correct in Odoo