[pmg-devel] applied: [PATCH] panel/acme-domains: fix cyclic dependency in view model

[pmg-devel] applied: [PATCH] panel/acme-domains: fix cyclic dependency in view model

[Thomas Lamprecht]

A view model forumla cannot depend on itself, as that is a dependency
cycle.

In this specific case we can just drop the `hasUsage` forumla entry
completely, it is bogus as it was just returning its value, and that
is actually taken care of by the `hasUsage` data binding.

The debug build of ExtJS throws an exception on such cycles, the
release build does not cares to much and seems to do the right thing
already here.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
---

@Wolfgang, or was there an actual reason this formula got added in the first
place?

 src/panel/ACMEDomains.js | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/panel/ACMEDomains.js b/src/panel/ACMEDomains.js
index f66975f..2b6c204 100644
--- a/src/panel/ACMEDomains.js
+++ b/src/panel/ACMEDomains.js
@@ -47,7 +47,6 @@ Ext.define('Proxmox.panel.ACMEDomains', {
 	    editBtnIcon: (get) => 'fa black fa-' + (get('accountEditable') ? 'check' : 'pencil'),
 	    accountTextHidden: (get) => get('accountEditable') || !get('accountsAvailable'),
 	    accountValueHidden: (get) => !get('accountEditable') || !get('accountsAvailable'),
-	    hasUsage: (get) => get('hasUsage'),
 	},
     },
 
-- 
2.20.1

Re: [pmg-devel] applied: [PATCH] panel/acme-domains: fix cyclic dependency in view model

[Thomas Lamprecht]

On 23.03.21 17:29, Thomas Lamprecht wrote:
> A view model forumla cannot depend on itself, as that is a dependency
> cycle.
> 
> In this specific case we can just drop the `hasUsage` forumla entry
> completely, it is bogus as it was just returning its value, and that
> is actually taken care of by the `hasUsage` data binding.
> 
> The debug build of ExtJS throws an exception on such cycles, the
> release build does not cares to much and seems to do the right thing
> already here.
> 
> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
> ---
> 
> @Wolfgang, or was there an actual reason this formula got added in the first
> place?
> 
>  src/panel/ACMEDomains.js | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/src/panel/ACMEDomains.js b/src/panel/ACMEDomains.js
> index f66975f..2b6c204 100644
> --- a/src/panel/ACMEDomains.js
> +++ b/src/panel/ACMEDomains.js
> @@ -47,7 +47,6 @@ Ext.define('Proxmox.panel.ACMEDomains', {
>  	    editBtnIcon: (get) => 'fa black fa-' + (get('accountEditable') ? 'check' : 'pencil'),
>  	    accountTextHidden: (get) => get('accountEditable') || !get('accountsAvailable'),
>  	    accountValueHidden: (get) => !get('accountEditable') || !get('accountsAvailable'),

Oh, and note that statements like above may break "change detection" for ExtJS.

With view model formulas, it first executes every formula and records the
keys all the get() calls use, this is then tracked as dependencies for a
formula and used to see what subsequent formulas need to be updated if any
other formula or data binding changes.

So, if on evaluation a get(X) is missed due to it being not always called,
like with boolean statements where a single truthy is enough for an or expression
like above, that data dependency is lost and one may see bug like behaviour.

Use intermediate variables to combat that, for example, above `accountValueHidden`
formula should read:

accountValueHidden: (get) => {
    let editable = get('accountEditable'), available = get('accountsAvailable');
    return !editable || !available;
},

Alternatively, one can tell ExtJS explicitly what a formula binds too:

accountValueHidden: {
    bind: {
        editable: '{accountEditable}',
        available: '{accountsAvailable}',
    },
    get: data => !data.editable || !data.available,
},

https://docs.sencha.com/extjs/6.0.2/guides/application_architecture/view_models_data_binding.html#application_architecture-_-view_models_data_binding_-_formulas_with_explicit_binding

Re: [pmg-devel] applied: [PATCH] panel/acme-domains: fix cyclic dependency in view model

[Dietmar Maurer]

> So, if on evaluation a get(X) is missed due to it being not always called,
> like with boolean statements where a single truthy is enough for an or expression
> like above, that data dependency is lost and one may see bug like behaviour.
> 
> Use intermediate variables to combat that, for example, above `accountValueHidden`
> formula should read:
> 
> accountValueHidden: (get) => {
>     let editable = get('accountEditable'), available = get('accountsAvailable');
>     return !editable || !available;
> },

I guess a good JIT can still optimize that away?

Re: [pmg-devel] applied: [PATCH] panel/acme-domains: fix cyclic dependency in view model

[Thomas Lamprecht]

On 23.03.21 19:22, Dietmar Maurer wrote:
>> So, if on evaluation a get(X) is missed due to it being not always called,
>> like with boolean statements where a single truthy is enough for an or expression
>> like above, that data dependency is lost and one may see bug like behaviour.
>>
>> Use intermediate variables to combat that, for example, above `accountValueHidden`
>> formula should read:
>>
>> accountValueHidden: (get) => {
>>     let editable = get('accountEditable'), available = get('accountsAvailable');
>>     return !editable || !available;
>> },
> 
> I guess a good JIT can still optimize that away?
> 


You're right, that may be the case.
Albeit, I guess that for such short method where the JS engine cannot know if it is
a "hot" function (lots calls) so the JIT won't be used initially, and the interpreter
probably isn't smart enough to detect this optimization.

At least above approach helped a bit ago when I ran in such a bug, but yeah, it may
not be really future proof...

Re: [pmg-devel] applied: [PATCH] panel/acme-domains: fix cyclic dependency in view model

[Dominik Csapak]

On 3/24/21 08:21, Thomas Lamprecht wrote:
> On 23.03.21 19:22, Dietmar Maurer wrote:
>>> So, if on evaluation a get(X) is missed due to it being not always called,
>>> like with boolean statements where a single truthy is enough for an or expression
>>> like above, that data dependency is lost and one may see bug like behaviour.
>>>
>>> Use intermediate variables to combat that, for example, above `accountValueHidden`
>>> formula should read:
>>>
>>> accountValueHidden: (get) => {
>>>      let editable = get('accountEditable'), available = get('accountsAvailable');
>>>      return !editable || !available;
>>> },
>>
>> I guess a good JIT can still optimize that away?
>>
> 
> 
> You're right, that may be the case.
> Albeit, I guess that for such short method where the JS engine cannot know if it is
> a "hot" function (lots calls) so the JIT won't be used initially, and the interpreter
> probably isn't smart enough to detect this optimization.
> 
> At least above approach helped a bit ago when I ran in such a bug, but yeah, it may
> not be really future proof...
> 
> 

but AFAIR, extjs actually parses the function *text* to find the
data dependencies (see 
https://docs.sencha.com/extjs/6.0.1/classic/src/Formula.js.html)

and i hope that the JIT does not change the text of the function
at all....

Re: [pmg-devel] applied: [PATCH] panel/acme-domains: fix cyclic dependency in view model

[Thomas Lamprecht]

On 24.03.21 08:31, Dominik Csapak wrote:
> On 3/24/21 08:21, Thomas Lamprecht wrote:
>> On 23.03.21 19:22, Dietmar Maurer wrote:
>>>> So, if on evaluation a get(X) is missed due to it being not always called,
>>>> like with boolean statements where a single truthy is enough for an or expression
>>>> like above, that data dependency is lost and one may see bug like behaviour.
>>>>
>>>> Use intermediate variables to combat that, for example, above `accountValueHidden`
>>>> formula should read:
>>>>
>>>> accountValueHidden: (get) => {
>>>>      let editable = get('accountEditable'), available = get('accountsAvailable');
>>>>      return !editable || !available;
>>>> },
>>>
>>> I guess a good JIT can still optimize that away?
>>>
>>
>>
>> You're right, that may be the case.
>> Albeit, I guess that for such short method where the JS engine cannot know if it is
>> a "hot" function (lots calls) so the JIT won't be used initially, and the interpreter
>> probably isn't smart enough to detect this optimization.
>>
>> At least above approach helped a bit ago when I ran in such a bug, but 
yeah, it may
>> not be really future proof...
>>
>>
> 
> but AFAIR, extjs actually parses the function *text* to find the
> data dependencies (see https://docs.sencha.com/extjs/6.0.1/classic/src/Formula.js.html)
> 

here the rendered docs version of that source code link
https://docs.sencha.com/extjs/6.0.1/classic/Ext.app.bind.Formula.html

> and i hope that the JIT does not change the text of the function
> at all....
> 

Not sure if there are any guarantees on that and not touching the src.
But yeah I slowly remember, and my issue then probably came from an use of
a variable as get parameter, which then naturally cannot work.