13

The framework will never have a way for you to get the parent component. That breaks encapsulation. You have two options: Fire an event that your containing component can listen for and act upon. Pass in a reference to the attribute to the child component. <c:childComponent myValue="{!v.B}"/> When the childComponent updates myValue, v.B will also ...


12

During the event bubble phase, use event.stopPropagation() to cause the component's root to be become the root node for the default phase. This means you'll need a handler at the top-level component to halt propagation beyond that component. See Application Event Propagation. It'll stop processing with the component that fired the event. <aura:component ....


11

When you use the pattern of: <c:parent> <c:child name="xyz" /> </c:parent> Then you must use includeFacets="true" to make a component event from the child bubble to the parent in the way you think it would in a DOM i.e. <aura:handler name="childInitialized" event="c:childInitialized" action="{!c.registerStep}" includeFacets="true"/&...


11

You'll want to use an application event; see the application event life cycle. The trick here is that you must call stopPropagation on your event from c:parent in order to set itself as the "root" for the application event. This will limit your event's scope to just components within your own hierarchy. The following should suffice: <!-- parent --> &...


11

You can try force:refreshView, which reloads all data for the view. So in addition to $A.get("e.force:closeQuickAction").fire(); add $A.get('e.force:refreshView').fire(); in your setCallback method. ({ handleClick : function(component, event, helper) { var saveLeadAction = component.get("c.leadSave"); saveLeadAction.setCallback(this, ...


11

Are lightning event synchronous or asynchronous? Yes. Asynchronous When fire() is called, the event is placed in to a queue for later execution. Atomic Until canceled or completed, only one event will be in the "executing" phase at any given time. Synchronous Once an event has been fully handled, the event queue is checked and the next event is fired. ...


10

I ended up moving the createItem function from my helper function to the CampingListController, since Trailhead does not "ask" us to split the createItem into a helper function. handleAddItem: function(component, event, helper) { var addItm = event.getParam("item"); helper.createItem(component, addItm); }, createItem: function(component, ...


10

Application-level events certainly are what Salesforce recommends for the use case of components that will be "App Builder siblings" and need to talk to one another. I think you won't be able to limit which components see the event, but you can limit which ones respond to it. If I understand correctly your "pitcher" and "receiver" are independent components ...


10

You can pass a reference to the parent into the child, so in the parent component: <aura:method name="parentMethod" .../> <c:child parent="{! this }" ... /> and in the child component you can then invoke the parent method: <aura:attribute name="parent" type="Aura.Component" required="true"/> someMethod: function(component, event, ...


10

what EXACTLY does not work? You may find that Locker Service will filter out some or all of the data you're trying to work with, even within your own namespace. For this reason, the two related methods for using Aura.Action, $A.run and Action.run, have been deprecated in favor of event handling. Previously, these methods would allow you to pass in ...


8

The bug in your code is at <aura:handler name="refineList" action="{! c.refineList}" event="c:contactListSearchFormEvent"/> you must use same name that you gave in registered event <aura:handler name="searchContact" action="{! c.refineList}" event="c:contactListSearchFormEvent"/> The name attribute in <aura:handler> must match the name ...


8

Lightning has some sort of digest cycle analogous to what you see in Angular and other front-end frameworks. When you make changes that affect the UI, they are not evaluated instantly but rather as part of the framework lifecycle. As far as I know, when you fire an event it happens asynchronously. That means the current cycle continues executing and ...


7

Usually, the component does not get destroyed once you navigate to a different view. When I tested at my end it usually takes around 9 distinct navigation(eg: visiting 9 different tabs) for the component to become invalid (i.e destroy). In general, when component is destroyed it is necessary to remove event handler or callbacks attached to the window,...


7

As stated in the documentation: The handler for an application event won’t work if you set the name attribute in <aura:handler>. Use the name attribute only when you’re handling component events. You need to remove the "name" attribute.


6

Hope this will help you out in your requirements. Create the event. Event: setAttributeEvent <aura:event type="COMPONENT"> <aura:attribute name="attributeValue" type="String"/> </aura:event> Register the event in child component. Component: ChildComponent <aura:component> <aura:registerEvent name="setAttribute" type="...


6

I'll tackle the Alternatives question here: I've got two ways to address this, because I felt the exact same pain points as you (it's so ridiculously redundant to create so many events). First method is a generic key:value eventing system where you switch keys and handle value optionally. I made this pattern here. You'll still need a generic handler/...


6

try to add oncancel event in your component. <lightning:recordForm objectApiName="Custom_Object__c" recordTypeId="{!v.Applicant.recordTypeId}" layoutType="Compact" columns="2" mode = "edit" onload="{!c.handleLoad}" ...


6

Yes. It can be achieved using the pub-sub model. To communicate between components that aren’t in the same DOM tree, use a singleton library that follows the publish-subscribe pattern. Refer to Communicate Between Components documentation for more details. For example, if you add two components to a Lightning page in Lightning App Builder, use the ...


5

Generally when an component/app runs in LEX, it will not get destroyed as soon as you navigate to a different view. Have a look at the post here. Also destroying component manually has a impact too which explained here. I believe action associated with destroy event will not be called immediately because of the component destroying issue in LEX. The right ...


5

Mohit points out that right now you aren't binding the value of the ui:checkbox to a component attribute, but that's not of concern here. Using your code copied and pasted into a new component, I cannot reproduce your error. The checkbox state changes and it reports to console. Is there other code in the mix here? Is that your code verbatim? That being ...


5

Actually I'm using the event force:refreshView which is doing what I want: <aura:handler event="force:refreshView" action="{!c.forceRefreshViewHandler}"/> and in the controller forceRefreshViewHandler : function(cmp, evt, hlp){ // your logic here }, If my stuff is making an update, which the flexipage should update on, I'm firing the very same ...


5

You could use Lightning Data Service to handle the record changes, but its still in Developer Preview which means that you won't be able to use it in a Production or Sandbox org. Next option is to use Streaming API, to listen for record updates you can find it here. Still I feel it's hacky way. Final option though I don't like either, 1) Regularly poll ...


5

So now that I understand correctly your problem, I have a better answer. This is a known issue. You can subscribe to it to receive a notification once it's fixed.


5

You cannot directly modify a child components attribute in parent.It provides that extra layer of security when each component can only modify its own attributes. You can do it in 3 ways Pass an attribute by reference to child component from parent and whenever its changes the child component can handle it appropriately Use Application events to ...


5

You can request your managed package application provider to provide a global event for your scenario . The managed package vendor will need to something similar to below code <aura:handler name="render" value="{!this}" action="{!c.onRender}"/> Controller code ({ "onRender" : function(cmp) { var appEvent = $A.get("e.c:appEvent"); ...


4

From the lightning component developer guide: This event is handled by the one.app container. It’s supported in Lightning Experience and Salesforce1 only. This means the event is handled only in one.app. Now, when you open a lightning tab, it opens in one.app container hence the successful run. Communities don't run on one.app hence the unavailability ...


4

You have registered the event on the handling modal, not the despatching modal. Move this from the ModelDialog2.cmp: <aura:registerEvent name="NavigateEvent" type="c:NavigateEvent"/> To the ModalDialog1.cmp component and I think it should all work. Your handler is also setup for handling a COMPONENT event, not an application event. Change your ...


4

I reproduced your code and found its not a problem with the events. They get perfectly fired. The root cause to me instead seems to be the use of $A.util.toggleClass(spinner, 'slds-hide') to show/hide the spinner. As the docs mention here https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/js_cb_styles.htm If the utility function ...


4

Application event handlers cannot have name. In the same link you have added in the question read it through and it has the information. Only component event handlers have name. <aura:handler event="c:aeEvent" action="{!c.handleApplicationEvent}"/>


4

Yes, you can get the toast information, as it is an application event, and thus propagates to all interested listeners. Here's the code I wrote that demonstrates this: <aura:component implements="flexipage:availableForAllPageTypes"> Toast Processor <aura:handler name="init" value="{!this}" action="{!c.init}" /> <aura:handler ...


Only top voted, non community-wiki answers of a minimum length are eligible