hello,
while working on a production application that uses aurelia v1.<compose /> element.
when I investigated the issue, I found that the docs of that spesific behaviour was simplly missing, and that some types were not exposed correctly from the module.
I’ve ended up finding the issue in the source code, so I’ve created a PR for a fix + updated the unit tests accordignlly to reflect the previous buggy behaviour and the fix.
I’ve exported the missing type, and updated the docs.
who can check and accept those PR’s?
the link for the issues are: [the PR’s are linked to the issues]
opened 01:26PM - 08 Sep 23 UTC
**Library Version:**
1.14.3
as we can see from this PR https://github.com/au… relia/templating-resources/pull/382
we have the ability to control the activation strategy of the `<compose />` element in two ways.
* by passing a bindable property
* by implementing `determineActivationStrategy` hook on the VM.
**Current behavior:**
* those features are not documented in the docs.
**Expected/desired behavior:**
* document the two ways of controling this behaviour.
I'll be working in the near future on a PR for this.
opened 01:26PM - 08 Sep 23 UTC
**Library Version:**
1.14.3
as we can see from this PR https://github.com/au… relia/templating-resources/pull/382
we have the ability to control the activation strategy of the `<compose />` element in two ways.
* by passing a bindable property
* by implementing `determineActivationStrategy` hook on the VM.
**Current behavior:**
* the enum `ActivationStrategy` (different from the one declared in `aurelia-router`) is not exported at all - making it hard to use in TS applications. (we need to use the strings litteral instead - or use the wrong enum).
other issue with the enum is briefly mentioned here: https://github.com/aurelia/templating-resources/pull/382#issuecomment-508168710
I think the best way to deal with it - is renaming the enum while exporting it to `ComposeActivationStrategy`
**Expected/desired behavior:**
* exporting the `ActivationStrategy` enum using a different name: `ComposeActivationStrategy`.
I'll be working in the near future on a PR for this.
but I wanted to know if the approach I want to go is acceptable. (exporting the activation strategy as a different name)
opened 01:35PM - 08 Sep 23 UTC
**Library Version:**
1.14.3
as we can see from this PR https://github.com/au… relia/templating-resources/pull/382
we have the ability to control the activation strategy of the `<compose />` element in two ways.
* by passing a bindable property
* by implementing `determineActivationStrategy` hook on the VM.
**Current behavior:**
* using `replace` as the activation strategy doesn't actualy replace the current VM.
here is a simple example (thanks @yosefbuskila) demonstrating how the same VM is being reused.
https://github.com/yosefbuskila/test-compose
it's enough to notice that the constructor is called only once.
and that the lifecycle hooks of the same instance of the VM are called in the wrong order.
**Expected/desired behavior:**
* when using `ActivationStrategy.Replace` - the `<compose />` element should create a new VM when changes occures in the passed `model`. and should onvoke all the desired lifecycles on both the leaving VM and the new VM.
I'll be working in the near future on a PR for this.
@bigopon I think that this is your area… can you take a look?
with much love and respect for aurelia
3 Likes
bigopon
September 10, 2023, 8:28pm
2
Hey I did see and look at the work. Thanks. Just i didnt have bandwidth over the weekend. Will check them soon. Thanks
6 Likes
hi @bigopon ,
2 Likes
bigopon
November 9, 2023, 12:13pm
4
Been on my mind and should be completed soon (I’m sure this time). Thanks for the nudge.
2 Likes
Hi @bigopon ,
out of the 3 PR, it’s seems only 2 got merged.
opened 01:35PM - 08 Sep 23 UTC
**Library Version:**
1.14.3
as we can see from this PR https://github.com/au… relia/templating-resources/pull/382
we have the ability to control the activation strategy of the `<compose />` element in two ways.
* by passing a bindable property
* by implementing `determineActivationStrategy` hook on the VM.
**Current behavior:**
* using `replace` as the activation strategy doesn't actualy replace the current VM.
here is a simple example (thanks @yosefbuskila) demonstrating how the same VM is being reused.
https://github.com/yosefbuskila/test-compose
it's enough to notice that the constructor is called only once.
and that the lifecycle hooks of the same instance of the VM are called in the wrong order.
**Expected/desired behavior:**
* when using `ActivationStrategy.Replace` - the `<compose />` element should create a new VM when changes occures in the passed `model`. and should onvoke all the desired lifecycles on both the leaving VM and the new VM.
I'll be working in the near future on a PR for this.
1 Like
I noticed it as well but forgot it. Merged and released as 1.15.1@avrahamcool
1 Like
@bigopon Thank you very much
Although this PR was merged a while ago,docs .
