Combination of `@dynamicOptions` and `primaryProperty`
- Dominant language
- TypeScript
- Stars
- 11.7k
- Forks
- 608
- PR merge metrics
- No merged PRs in 30d
Description
**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.
Contributor guide
Research direction
Start by tracing how Aurelia custom attributes handle @dynamicOptions, @bindable, and primaryProperty, then reproduce the interaction described in the issue. Done means a component or attribute can retain predefined bindable properties with primaryProperty while also accepting dynamic options, with coverage for both behaviors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100