6

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.

  • 1
    I've noticed issues like this in the past, although not to the extent you're describing. Making sure I close the component using the e.force:closeQuickAction event seemed to do the trick for me. – Antonio Manente Jun 1 '18 at 19:22
  • Thanks Antonio, however this is not a QuickAction. There is no quick action dialog to close. This is a component overriding the 'New' action, which is totally unrelated to a quick action. I'm glad you got your issue sorted out however ..... – Peter Byrne Jun 1 '18 at 23:14
  • I understand. I thought there may have been something similar for overrides but I was mistaken. That being said, I spun up a bare-bones component in an effort to reproduce your findings to no avail. My init handler fired every time without fail. I think it would be helpful to share a code sample in order to try and diagnose; including only the essential logic for reproduction. – Antonio Manente Jun 2 '18 at 0:21
  • @PeterByrne I have observed the similar issue in Summer 18 sandbox. Let me explain more in detail. We have overwritten the New button with a lightning component and that object has couple of record types. we need to pick the record type id based on user selection and render certain part of the markup in cmp. We are achieving this by parsing URL parameters in init method of the cmp. This solution is being worked perfectly before Summer 18 but for some reason it stopped working which means, only first time init method is getting invoked and the rest of the clicks it used to take old value. – brahmaji tammana Jun 2 '18 at 13:22
  • (2/2). Basically 'init' method is NOT getting invoked from second click (on New) onwards. It is referring same attribute which was selected in previous click. We have raised a case to Salesforce as it caused due to Summer 18. I just checked in cs84 sandbox (Summer 18 upgrade) and it looks to be resolved now. Hope i understand the problem and this comment is relevant to your question. – brahmaji tammana Jun 2 '18 at 13:24
2

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.

  • Part 1 Good info ... Thanks... I resurrected the old code I was playing with, to test out your theory. As it turns out, my example code is pretty well the same as yours except I implement the isUrlAddressable interface rather than the hasPageReference interface. In either case (implementing either of the two interfaces, doesn't matter), the behavior that I observe is identical, and unfortunately is not the same as the behavior you have described. – Peter Byrne Dec 5 '18 at 23:06
  • Part 2 What I see is exactly as I described in my initial big and ugly post, and that is : EITHER the init event will fire OR the change handler will fire. Never NONE. Never BOTH. Either one OR the other. ALWAYS. As I described, we could perhaps work around that using either event to fire our code, but it feels like a total hack. When delving in to the why's and wherefore's of it all, we could sort of explain the behavior, based on how Lightning is apparently caching Lightning components in the background. – Peter Byrne Dec 5 '18 at 23:06
  • Part 3 When Pressing the 'New' button the VERY FIRST TIME you enter the application, the init event WILL ALWAYS fire (because the component does not exist and the framework will create it). OK. Very good. The 'change' handler will NEVER fire in this case, as it can't. The component does not even exist and so cannot possibly respond to a change of a field value. When navigating away from the component and then AGAIN pressing the 'New' button, THEN and ONLY THEN does the 'change' event fire. Why? Because we see that the component still actually exists (cached somewhere !!) – Peter Byrne Dec 5 '18 at 23:07
  • Part 4 The init event will NOT fire in this case, as the component was not created. But it DOES handle the change event, because the pageReference really did change, and there is a component with a registered change handler to handle it. It must be noted that in the second scenario, it is NOT guaranteed the the Lightning Framework still has a cached verion of the component available for resuse, and we then see the init event firing again (and NOT the change event). – Peter Byrne Dec 5 '18 at 23:08
  • Part 5 We gave up on all this, as it was simply part one of the bigger issue about not really being able to use Lightning components as 'New' action overrides as we do NOT have access to the Parent ID (the context in which the New action was invoked). (That's a whole other story) Sure, I've seen some smart dudes out there figure out how to unravel the pageReference object and actually find the Parent Id, but that (from my understanding) is totally undocumented / unsupported at this stage, and we have enough issues trying to make 'documented' things work in Lightning :) – Peter Byrne Dec 5 '18 at 23:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.