With Aurelia 2, everything has been reimagined from the ground up. While the syntax and way you build applications is largely the same as Aurelia 1, there are some key differences and one of those is lifecycles.
When I say lifecycles I am talking about component lifecycles and router lifecycles. If you need a handy reference for what lifecycle you should use, you just found it.
This will not cover all lifecycle methods, just the ones that most people would want to know about such as dom attached and where you should load data from an api.
Component Lifecycles
There are a lot more lifecycles than shown below. These are the ones you want to know for loading data or working with the dom.
beforeBind (equivalent to bind in Aurelia 1) – Fetch data in here, initialize things and set up subscriptions. If you make this method async, Aurelia will wait for your function to resolve before rendering. This is a great place to load data. You can modify the bindings before they’re attached to the view (coerce values and so on).
afterAttach (equivalent to attached in Aurelia 1) – Work with the dom, use 3rd party libraries. Can be async.
afterDetach (equivalent to detached in Aurelia 1) – Clean up anything that touched the dom. Can be async.
Router Lifecycles
canEnter (equivalent to canActivate in Aurelia 1) – Useful for loading data or verifying parameters passed in the URL that are required for the component to render.
enter (equivalent to activate in Aurelia 1) – Similar to canEnter anything loaded in here is not necessarily crucial for the component to render.
canLeave (equivalent to canDeactivate in Aurelia 1) – Can the current user leave the component?
leave (equivalent to deactivate in Aurelia 1) – The user is leaving the current route and heading to another one.
We’re still using Aurelia 1, but are you sure beforeBind( ) means the same as bind( )? I thought bind( ) meant (in Aurelia 1) that Aurelia had finished setting up all of its bindings between data objects and HTML, and hence the “bound” values were usable.
For example, we frequently used bind( ) to convert attribute values provided as strings in HTML which were declared as bindable properties (especially booleans like “false” and “true”) into real booleans that the remainder of our component class could more easily use. This was because HTML would give you a string value if you assigned it directly (eg. my-attribute=”true”) and a bound attribute might give you an actual bool (eg. my-attribute.bind=”someobject.isBigThing”), so we wanted to normalise the types.
So I’m surprised (that’s all) that beforeBind( ) has the same meaning.
@Kevin Frey,
That’s correct. While work on lifecycles is normalising and still ongoing, at the time of writing of this, `beforeBind` is the closest matching lifecycle method to `bind` in Aurelia 1.
Here is a more long-winded explanation from Aurelia 2 WIP docs:
>If your component has a method named “beforeBind”, then the framework will invoke it when it has begun binding values to your bindable properties. In terms of the component hierarchy, the beforeBind hooks execute top-down, from parent to child, so your bindables will have their values set by the owning components, but the bindings in your view are not yet set. This is a good place to perform any work or make changes to anything that your view would depend on because data still flows down synchronously. This is the best time to do anything that might affect children as well. We prefer using this hook over afterBind, unless you specifically need afterBind for a situation when beforeBind is too early. You can optionally return a Promise or ILifecycleTask. If you do so, it will be awaited before the children start binding. This is useful for fetch/save of data before render.