I used to work in lightning using developer console. But when I tried to create a Lightning Bundle in Force.com IDE in eclipse, and it displays several options such as Lightning Component, Lightning App, etc.

I have created a Lightning Component and a Lightning App separately. It looks like the screenshot below. My questions are,

enter image description here

  1. why it has the separate controller and helper for app and component respectively?

  2. How the controller and helper would help an app? Because I think controller and helper are more meaningful in a component. Please clarify.

  3. Would there be more than one controller and helper in a Lightning component bundle? Please clarify.


  • [It looks like the screenshot below.] Where is the screenshot?
    – metasync
    Commented Apr 11, 2018 at 15:38
  • @datasert sorry, I just missed and added it now. Kindly check it. Thanks
    – Bforce
    Commented Apr 11, 2018 at 16:20

4 Answers 4


An App is essentially a specialized top-level component. It comes with the same code structure that a component does, including both a helper and a controller.

These entities can of course be empty if they're not required. However, the app often plays a "coordinating" role amongst its child components, and it may (for example) handle application events. These needs would be supported by the application's controller and helper, which might fire other events, call methods on the public API of its child components, set attribute values, and so forth.

A single Lightning component bundle would include only one helper and one controler.


An application is almost a type of component. The Lightning Experience is an app one:one, and contains a few hundred lines of code to provide specialized Lightning application logic, and tons of helpers for loading/saving data, loading other components, etc. While the apps that you typically see in examples are just containers for a component, they are not; they are full-blown stand-alone components that can provide a complete experience. It's the "glue" that holds the rest of the components together.

why it has the separate controller and helper for app and component respectively?

The helper is "shared code", and reduces the memory footprint of each component by sharing common methods. The controller itself is duplicated each time, so it should be as small as possible to reduce memory usage. For an application, this doesn't matter, but it's still a best practice. For example, you might later want to convert your application to a component.

How the controller and helper would help an app? Because I think controller and helper are more meaningful in a component. Please clarify.

The same way that it helps a component; the controller is the "controller" part of MVC design (Model-View-Controller). Without a controller, you can't implement business logic. How useful would an app be without any business logic?

Would there be more than one controller and helper in a Lightning component bundle? Please clarify.

No, you have at most one controller and one helper.

  1. The app itself does have it's own standalone controller/helper. You can technically build out an entire app using only built in components and the app controller/helper; however, this is pretty much the exact opposite of what lightning components are designed for and should pretty much never be done. Apps are intended to host and manage components components, layouts, and events for the entire application. Building an entire app without any components is against modular design principals.
  2. Again, yes they are much more meaningful in a component, but they can also add app level functionality such as dynamically getting a list of records and passing it to a component to be rendered.
  3. No, each lighnting component bundle has 1 controller and 1 helper. Same with the app, there is only 1 controller and 1 helper in the app. The app and component are bundled separately. Deploying an app without it's required components would result in errors.

Basically, it's a mindset. There is some flexibility and everyone will have an opinion on a "best practice". The way you structure your components/apps is entirely up to you and what makes sense to you as a developer.

One of the first pieces of advice I received as a developer was always code as if they person maintaining your code is an axe wielding murderer. Encapsulate your logic, stick to the single purpose principal and don't use dumb variable names. Otherwise, if it works, it works.

EDIT: Clarified some vague language based on feedback in comments.

  • Regarding (1): What do you think the Lightning Experience is? Just because you've never seen the source for a full-blown application does not mean you've never used one. Try using the Lightning Inspector sometime, you'll see that the One app is signifciantly involved.
    – sfdcfox
    Commented Apr 11, 2018 at 16:03
  • It would be quite shocking to me if they built the entire app without using a single component.
    – gNerb
    Commented Apr 11, 2018 at 16:12
  • No, they obviously used components, which is the point of modular programming. But the point is that one:one isn't just a single line of code. It has a controller, a handful of attributes, event handlers, and all that stuff. It's like a component that simply happens to not have a parent component.
    – sfdcfox
    Commented Apr 11, 2018 at 16:15
  • Then I'm confused, what did I say that was wrong?
    – gNerb
    Commented Apr 11, 2018 at 16:16
  • 1
    Perhaps I've misunderstood your answer then. You seem to imply that an application is just a place to hold components ("If you do need a controller, it should be for very top level stuff."). Applications certainly can be as complicated as they need to be, because, after all, they're applications. While it's true that applications will have a number of components in them, they're also responsible for laying out the design of the application and coordinating events and data across child components. It plays a critical role in the real world.
    – sfdcfox
    Commented Apr 11, 2018 at 16:22

Applications vs components

In Lightning, applications are just a specialized type of component. They allow extra attributes such as "template". A template is another type of specialized component that is rendered server-side to provide the page layout.

But as far as JavaScript goes, applications behave the same as components.


A bundle is simply a folder controlled by an XML file, either a .app, .cmp, .inf, or .evt file.

All resources (CSS and JS) in the bundle are meant to be private. Components are supposed to be opaque, and only attributes and methods declared in XML should be visible to other components.

This privacy ensures that components can be maintained individually and keep working, as long as the attributes and methods remain the same. Those act as a public contract with other components. However, the JavaScript is not exposed directly.

JavaScript in bundles

Applications and components can have 3 different types of JavaScript files: the controller, helper, and renderer. All of these files are wired automatically to the XML file, and the name is set by the component bundle as <bundle-name>Controller.js, <bundle-name>Helper.js, anf <bundle-name>Renderer.js. This means that there can only be one of each per bundle.

Lightning was originally designed for a zero-code approach: you would primarily build apps by putting together pre-built components, adding a few event callbacks in the controller, and occasionally tweak the rendering cycle via the renderer. The helper was added later as use cases kept growing.

How to best use helpers

The controller methods behave like standalone callback functions, and it's not possible to call one controller method from another (the value of "this" is undefined). This means controllers can't reuse code.

Lightning provides the helper to alleviate that problem and share code between different controller methods, and even with renderer methods.

A good programming practice is to keep the controller methods as lean as possible: get/set component attributes and event parameters in the controller, but do the heavy lifting in helper methods. If you don't pass components and events to the helper, it makes your code more testable, as fewer mocks are necessary.

Beware that helpers are singletons, they are shared between all instances of a given component type. If you store data on the helper, it will be visible by all controllers.

Application controller and helper

At the application level, it's common to declare application event handlers. Those need controller methods, which in return can leverage helpers.

It's also common to have an init handler at the application level:

<aura:handler name="init" value="{!this}" action="{!c.init}"/>

The application can declare attributes, and those are automatically populated using the URL query string (the key-value pair after the "?"). The application init handler usually is tasked to read them and setup things accordingly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .