odoo / odoo/owl

investigate: avoid updating arrow functions props if possible

Open
#2,003 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
1.6k
Forks
427
Avg merge
10h 44m
Merged PRs (30d)
18

Description

Context:

Props assigned an arrow function are "ignored" (auto .alike) for re-renders 👍
... but they are not ignored for useEffect if a render actually occurs for another reason 🤔

Another way to say it: I think the intended behavior of useEffect is to "trigger when something that is read inside the effect changes" but a simple useEffect(() => { this.props.doStuff(); }) actually triggers on all renders, as doStuff gets reassigned to a new arrow function. Is this wanted?

I made a PR with a quick test to demo the issue more precisely: https://github.com/odoo/odoo/pull/278104 (the last assertion fails, I would have imagined it should not).

well, yes it is intended. the useEffect has no way of knowing that the function is actually the same. if the effect reads a reactive value (in this case this.props.doStuff), and that value is reassigned, the effect is reexecuted. Now, for the props in a template, since owl knows that the new function is actually the same closure, it does not need to update the child component.

for the props in a template, since owl knows that the new function is actually the same closure, it does not need to update the child component

If it didn't update that prop, wouldn't the problem go away too?

that's an interesting thought. not sure how easy it is to propagate the information to the useProps function and define a signal with a truthy comparison function to skip the update, but it could very well work. i'll investigate

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with PR #278104 and its failing last assertion, then trace how arrow-function props reach useProps and how useEffect observes them. Determine whether the prop update can be skipped without changing intended reactive behavior, and add or update a focused regression test showing the expected effect execution.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend, web-dev
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.