Completely separate this from rendering context

[sdegueldre]

Currently, in some cases, calling component methods without qualifying them with this (eg myMethod() instead of this.myMethod()) inside the template of a component can cause subtle bugs: because a bare function call is transpiled by owl into a method call on the rendering context (ctx['myMethod']()), that function will be bound to the rendering context, which can cause several issues. In particular, any "write" in the function will be written on the rendering context instead of the component, and if a variable in the rendering context shadows a property of the component, the method will read that instead.

This is particularly confusing because for the most part, the method will behave as expected in most respects, and so a method call can be written incorrectly and still work, until a code change adds a write to the method which appears to mysteriously not work, the fix needing to be applied being in an entirely different place from the original code change.

The issue is further aggravated by the existence of getters, which makes any unqualified property read unsafe. The issue can be further obscured if for some reason the method or getter returns a handler, as that handler will be bound to the wrong this but the bug will only appear when that handler is called at a later point, and again only on the condition that it attempts to write on a component or reads a variable that is shadowed by the rendering context.

[aab-odoo]

also, should it be named this or comp or whatever (in qweb, it was widget)

[sdegueldre]

Alternative: reimplement t-set/t-foreach so that they don't need to protect the context, ie the rendering context is only the scope of the rendering function and during compilation don't look up template-local variables in the context.

[ged-odoo]

@sdegueldre I think that it was done that way in owl 1.0, or in some early prototype. The problem is how can you tell in a t-called template that a variable is local to the template?

<t t-name="mycomponent">
  <t t-set="a" t-value="1"/>
 <t t-call="subtemplate"/>
</t>
<t t-name="subtemplate">
  <t t-esc="a"/> <!-- local -->
  <t t-esc="b"/> <!-- not local, should look in component-->
</t>

Maybe we can change the expression "compiler" to do a lookup in a scope object, and fallback on ctx object. So, instead of transforming a into ctx['a'], we could transform it in: ('a' in scope ? scope['a'] : ctx['a']).
It's annoying to have such a complex expression in most cases :(

[ged-odoo]

Note that having a clear and obvious distinction (statically known at compile time) between "local" and "component" variables should allow Owl to simplify the code handling scopes. Currently, it has to capture the current scope in many cases, and it has to perform various kind of weird shenanigans when writing/updating values. Doing what this issue propose would remove all that, which would also slightly accelerate owl rendering speed