Design patterns for Lightning Aura Application.

Manjot Singh
Salesforce-Lightning
3 min readNov 26, 2017

When we start developing lightning application for our app one year ago then we didn’t know how to start. We were looking for what design pattern should we use in Lightning. As salesforce as such didn’t recommend any design patterns and after going through there documentation we decided to break our App into smallest functional components and try to reuse those components in different places.

In above diagram boxes are represented as a component and arrows are events handled and attributes passed by different components(here we created a real mess of events that we fired and attributes passed to components).

Now above architect will work fine for simple apps but as you add more features it will start getting complex. So we end up with a real mess of different components events, application events, attribute change and initialization events.

So we analysed and come up with problems and there solution:-

Coupling of UI Components and Api Calls: We coupled our UI components with Apex callouts.

Now problem with above is that if we need same api at some other place or we need to change UI we have to rewrite the same api(even though it might work by a simple copy paste).

So what we did is introduced a data Service component in between.

So data service component will be a just do a api call and return response to respective components.

Single Source of truth: In lightning when we pass a attribute from parent to child from child to there child components then if anyone component change the attribute they are reflected in all components.

If you start debugging which component made changes in that attribute it will be a difficult task. So it might lead to unexcepted behaviour of your application. So to make task easy you should have a single source of truth. Whenever you want to change a attribute fire an component event and handle that at very top which will change attribute value.

By doing so your data flow will be unidirectional that is it will always flow from outermost component to innermost component.

--

--