‘init’ event not always firing on Lightning component used as ‘New’ Action Override?

Question

We are building a lightning component to be used as a ‘New’ Action Override.

This question is NOT related to our inability to access the Parent Id of the new record. An example of that issue is “I click on a ‘New’ Opportunity on a related List on the Account Detail page, and there is NO official way of accessing the Account ID from within the Lightning component”. This deficiency has been discussed ad nauseum in other threads, and there is STILL no solution for it.

This question is NOT related to the fact that the behavior of the New override is inconsistent with the native ‘New’ functionality (where a modal dialog will popup OVER the existing page). This has also been discussed forever and we still cannot do this…..

This question IS about how to reliably execute initialization code for such a component.

We use the ‘init’ event handler right?

Has anyone ever done this?

Our observations so far suggest that the event WILL be fired when the component is actually created (just like the documentation says), but that the component sometimes just ‘hangs around’ after the user has completed the action or navigated away from the page or whatever, and that the existing instance of this component will be used for the subsequent invocation of the ‘New’ action.

We believe that the component still exists, as handlers for the ‘render’ event, or ‘locationChanged’ or anything else you can think of, fire when the ‘New’ action is invoked again (but the init event does NOT fire).

How do we reliably execute code ONE TIME at the start of the ‘New’ Action override then?

1. Use another event, like ‘render’ which appears to always fire? No way we are doing that. If our one time code needs to update an attribute on the component we end up in an infinite loop mess.

2. We somehow destroy the component ourselves (perhaps when we navigate away from the page by handling locationChange? No way we’re doing that either. Of course we’ve tried :) and it simply confuses everything. In the example given above, returning to the Account detail page and pressing ‘New’ does not create a new instance of the component, and so does not fire ‘init’ and we land on an empty page in outer space. So, that is just a big hack anyway…….

So, assuming we have created a new Lightning component to be used as an Opportunity ‘New’ override We can reliably recreate this issue by

1. Navigate to an Account Detail page.
2. Click on the ‘New’ button on the Opportunity related list.
3. Observe that the ‘New’ override ‘init’ event was actually fired. Cool..
4. Navigate to a different account.
5. Again, click on the ‘New’ opportunity button. You will observe that the ‘init’ event did NOT fire. The ‘state’ of the component is how it was the last time it executed. :( No ‘init’ event was fired for us to do our thing….

Hmmmm?? Could anyone please confirm / deny … whatever that you have also perhaps experienced this behavior? Perhaps we are doing something wrong here? I’m not of course going to bore you with copy pasted code. It is pure vanilla 101 lightning component code, and I trust the explanation of what we’re doing is clear enough.

Thanks for any help.

Answer 1

I know this question is quite old, but having run into this issue myself recently I wanted to post a workaround I was able to cobble together.

For the workaround to work, you need to add the lightning:hasPageReference interface to your component and an attribute to store the page reference. I was already using this interface for something, but it should work for any case, even if you don't need the actual interface.

<aura:attribute name="pageReference" type="Object" />
<aura:handler name="change" value="{!v.pageReference}" action="{!c.handlePageChange}" />

Then in the controller, fire whatever logic you need to fire from the handlePageChange method. In my case, I needed to reload a record using lds, which then fired more logic.

{( //controller.js
    handlePageChange : function(component, event, helper) {
        console.log("pageReference attribute change");
        component.find("userRecord").reloadRecord(true);
    }
})

By doing this I was able to successfully fire any logic that needed to fire each and every time the New button was pressed.

Answer 2

The answer @Piyush provided is a satisfactory solution, although it would have been easier to read if the code was formatted. In addition, I would like to propose a simplified version of the solution @lpbearden provided. Instead of creating a separate method for handling the pageReference change, I propose that you run the doInit method (or whatever your init method is called) in response to the change:

<aura:attribute name="pageReference" type="Object" />
<aura:handler name="change" value="{!v.pageReference}" action="{!c.doInit}" />

This solution worked for me when needing to address a recordTypeId change from the New action in a subsequent call. It specifically addresses the OP's request to rerun the init code.

Answer 3

One other thing that can be done is, on the 'change' handler - just call the $A.get('e.force:refreshView').fire(); This should call the init method again on refresh of the page. I had a similar problem - and this helped me overcome this. I was using an Aura component to override the New button, which in turn is calling a LWC component, and my data was getting cached on the second call. With this solution - not facing an issue anymore.