aurelia / framework

The Aurelia 1 framework entry point, bringing together all the required sub-modules of Aurelia.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Combination of `@dynamicOptions` and `primaryProperty`

ConductedClever opened this issue · comments

I'm submitting a feature request

  • Library Version:
    v1.0.2

  • Operating System:
    Windows 10

  • Node Version:
    v12.5.0

  • NPM Version:
    v6.9.0

  • Aurelia CLI Version
    CLI v1.0.2

  • Browser:
    all

  • Language:
    ESNext

Current behavior:
Currently there are two options to develop a custom-attribute in aurelia. One to use dynamicOptions and one to not.
If dynamicOptions is not used, I can mark a bindable as primaryProperty, but in other way, when dynamicOptions is used, I can't find a way to specify a primaryProperty. And if I use dynamicOptions and also define a @bindable, the dynamicOptions stops working.

Expected/desired behavior:
I think it will be a good possibility to be able to use both @dynamicOptions and @bindable({ primaryProperty: true }) ... in a component or attribute. Because I have some predefined properties that I want to have configurations like primaryProperty on them and also I want to be able to receive dynamic options.

  • What is the motivation / use case for changing the behavior?
    ‌Being able to have benefits of @dynamicOptions and primaryPropert in a place.

And also there is a need to combination of @dynamicOptions and @bindable. Let's say I am developing a component for my inputs, which contains a label, input and a span for validation messages. Then I want to have some bindables defined like @bindable labelText to fill the label tag content, and then forward other unexpected bindables to the attributes of input itself. For example I want to forward bindable min to attribute min in input. So it will be useful to be able to define bindables in a component which is annotated by @dynamicOptions.

Another necessity of this behavior is when I want to have some bindables dynamic and also have some two-way bindables or other ways.

@ConductedClever thanks for filing this issue. It maybe do-able, let me have a look, are you blocked by this or it only causes boilerplate code that you would love to eliminate?

and I also have this problem how to set defaultBindingMode for dynamicOptions?


  @dynamicOptions
  @inject(Element)
  export class SquareCustomAttribute {
    @bindable ({defaultBindingMode: bindingMode.twoWay}) fill;

    constructor(element){
      this.element = element;
    }

    propertyChanged(name, newValue, oldValue){
      switch(name){
        case 'fill':
          this.element.style.backgroundColor = newValue;
          break;
        case 'size':
          this.element.style.width = this.element.style.height = `${newValue}px`;
          break;
        default:
          this.element.style[name] = newValue;
          break;
      }
    }
  }

if I set fill property to bindable I will not access inside the propertyChanged to other property like size

@ConductedClever thanks for filing this issue. It maybe do-able, let me have a look, are you blocked by this or it only causes boilerplate code that you would love to eliminate?

@bigopon thanks for paying attention to this issue. In fact this issue does not exactly block our job but pulls our job out of its way. Let me describe more. We are developing a full UI-component framework for our company. And currently in order to use binding options, I have to lose the benefits of dynamic options.
So it will be good news that this issue will be fixed. And if not, we have to come back later to all components to remove all unnecessary properties which will bind dynamically.

And I found that, I have asked this question before on stackoverflow.