What is the best way to block observable propertie's value?

[Reinmar]

This is a common practice e.g. when one feature wants to control a state of another feature's command.

See https://github.com/ckeditor/ckeditor5-core/blob/4d768dff3facd329b881859a4b831d2dd6a3e3f4/tests/command.js#L118-L135

It overrides some property and then ensures that no one changes it back.

In that test I used a high priority listener and stopped the event so the change of the property value is not visible to the normal listeners.

However, this breaks bindings because they rely on normal priority listeners.

So another option is to listen with a low priority listener and to not stop the event. This will fix the bindings but it means that the change event is visible twice. It's hard to predict implications of that. Infinite loops or blinking UI are possible.

So, what's the best way to achieve:

• minimal noise,
• working bindings,
• safety?

[pjasiun]

More I think about it, more I feel that changing the observable value in change:observable listener is wrong. change event should be used only to listen on the property change, not to change it. I believe we need a separate event to let users change properties like command.isEnabled and I believe we will be able to bring a nice API for it.

I propose to define some of the observable properties to be overwritable to:

this.set( 'isEnabled', false, { overwritable: true } );

Such properties will not fire one, but two events. The first one will be fired before the change happens, will contain the new value in evt.return and should be used to overwrite the value of the property. I propose to call it set:observable but we could consider something more unique:

command.on( 'set:isEnabled', ( evt ) => {
    if( isReadOnly ) {
        evt.return = false;
        evt.stop();
    }
} );

In such solution both new and old values are available: new as evt.return, old as command.isEnabled (it is not changed yet).

if change event will be fired after set event if the value really changes, does not matter if set event was stopped or not. There is also no priorities collisions: you can set higher priority if you need to execute your listener before others or lower if you need to execute your listener after, you do not need to follow any specific rules.

Note that only some properties should be overwritable, It is unexpected that the value can be different than the one you set:

this.foo = 'bar';
this.foo // 'bom'

We should not overuse this mechanism.

[oskarwrobel]

I would call it beforeChange and fires for each observable.

[jodator]

I would call it beforeChange and fires for each observable.

Yeah. AFAIR Something similar is in Backbone (before:change or something like this). The question is it that necessary for every observable 🤔. If only few of them requires such thing wouldn't be overhead to add this to every property?

[scofalik]

On a plus side of having it for every property is that it would make the code a little easier extendable. Of course, it adds overhead, but I don't think a lot of it. I'd go with having this for every property. This is the easiest solution too.