Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Combination of @dynamicOptions and primaryProperty #937

Open
ConductedClever opened this issue Jul 27, 2019 · 5 comments
Open

Combination of @dynamicOptions and primaryProperty #937

ConductedClever opened this issue Jul 27, 2019 · 5 comments

Comments

@ConductedClever
Copy link

ConductedClever commented Jul 27, 2019

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.
@ConductedClever
Copy link
Author

ConductedClever commented Jul 27, 2019

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.

@ConductedClever
Copy link
Author

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

@bigopon
Copy link
Member

bigopon commented Jul 28, 2019

@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?

@MohsenBazghandi
Copy link

MohsenBazghandi commented Jul 28, 2019

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
Copy link
Author

ConductedClever commented Jul 28, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants