Why does't the Attached Lifecycle Callback Have a Parameter that is the Attached HTML Element?

Framework Knowledge
1

Using the ref attribute meets all of my needs but I am curious as to why nothing is passed into the Attached callback by default.

*Edit for more context
Like I have mentioned in other posts I am working on project that is currently upgrading a Durandal app to Aurelia. The Durandal lifecycle callback for attached included view and parent parameters and I am wondering why a similar pattern was not chosen for Aurelia’s corresponding life-cycle event. This seems like an unnecessary inconsistency?

2

Initialization has its own phase, which is created. In this lifecycle, you can have access to current view and its parent view:

export class Bla {
  created(owningView: View, view: View) {
    // attached happens after this
    // store the reference if you want to deal with it later
  }
}
1 Like
3

I understand how it works. I want to know why the actual html element that is being attached is not returned in the attached callback.

4

You can get the actual HTML element through constructor injection. This allows you to access it earlier than the attach lifecycle event. As a result, you can write more efficient code by making any modifications to that element before it’s actually attached to the DOM.

4 Likes
5

@EisenbergEffect thanks for replying to my post. I understand how to use the @inject(element) and the ref="property" patterns to get access to the elements I need. I even understand the value of that functionality compared to what was provided by the durandal framework.

What I don’t understand is why the new Aurelia patterns aren’t supplemental to the preexisting pattern of supplying the view to the attached callback. Keep in mind that the @inject method only works if you are not preconstructing your viewmodel before composing it. And the ref binding only works on the elements you have access to in the view markup. I have several preconstructed viewmodels that I need to pass to the dialog plugin which adds two div wrapper elements that I can only get access to with the @inject method (which I can’t use without significant refactoring). Having the attached elements passed to the attached callback would make our conversion a lot simpler and it would really help in the odd situation like I just discribed.

(related side note: why can’t I override the <ux-dialog-container> markup? Durandal let you create custom dialog contexts where you could define your own dialog host and attachment logic. Can Aurelia do this?)

6

I honestly can’t remember all the reasons that we made that decision, as it was made about 4 years ago now and at the time we didn’t document the why of it. I should note that documenting this type of decision is something we’re working to greatly improve with Aurelia vNext.

In general, a lot of decisions were made for reasons of performance and consistency, as well as aligning with some web components callback standards, ES2015 and module loader standards trends. Additionally, because Aurelia is an e2e templating and binding system, not based on KO, it has some different internal structures and capabilities, which again, were designed around performance and other scenarios. During our lengthy year+ alpha and beta period, I don’t recall anyone asking for this to be changed, or finding any issue with it, so it became crystalized in the design and hasn’t changed since. Essentially, the specific shape of this API is the result of many factors of the architecture and various constraints.

For Aurelia, the modal dialog plugin came along much later and has undergone a number of significant revisions. In fact, a next major version is going on right now, so it might be a good time to provide feedback on that project specifically.

Beyond that, I could really use a concrete example with some code to help understand what you are doing a bit better. I’m sure it can be done in Aurelia, it just might be done a bit different.