Let's practice a little how to think and abstract one application into a few components. Here's some web template with some sections:

Now, it's time to think.

How many sections are similar?

• Buttons are very similar; just the text/color can change
• Menu options can be a reusable single component
• Main page sections are the same; just the content changes
• The header can be decoupled from the application main section

Which sections do you think can be reused across application pages, take a look:

• Main page sections can be used as a container for other options
• The buttons can be shared across all the application sections

Last, but not the least, do you think you need to refresh the entire page when you submit or just some sections?

A better option can be to refresh only what really needs to be refreshed. Each section can independently manage their data and the way it's retrieved.

Of course, all these answers depend on the business rules of the application, but the principles are always the same. If you find some section of your application that can be reused, reloaded, managed, and maintained independently of other sections, you should decouple it into a single component.

Once you have defined what parts of your application will be a component, it's time to organize. You must identify which components will be used just for some page in particular (maybe an Item component for a shopping cart page), how many of them will be shared across the entire application (a common table to be used into many reports of your application) and finally, organize them by separated groups:

Now, let's create one folder per component; you should keep in mind that if some component will be parent of another component, the child folder should be created inside the parent, to specify ownership. Remember always that as a programmer, your main goal is to make your code readable and understandable to other developers—that's a good quality measure!

At this point, we now have our folder structure created for our components. An Aurelia component is basically composed of two files: the HTML template, called view, is rendered into the DOM. The .js file, called view model, is written in ES Next, and it defines the behavior and provides data for the view. The templating engine, along with dependency injection (DI), that we will explain in detail in the following sections, is responsible for creating and enforcing a predictable life cycle for the component. Once the component is instantiated, Aurelia’s data binding links the two pieces together, allowing changes in your view model to be reflected in the view and vice versa. This separation of concerns allows us to work/collaborate with designers and improve our product quality. Let's create one component as an example:

/**card-component.js**/

export class CardComponent {

  cardTitle;

  constructor(){
    this.cardTitle = 'Card component example'
  }

}


<!--card-component.html-->

<template>
  <div class="card" >

    <div class="card-header">
      <h2>${cardTitle}</h2>
    </div>
    <div class="card-body">
    </div>

  </div>
</template>

You should remember some good practices about naming your components:

• Use dashes for naming your components. For example, <my-component> and <my-other-component> are valid name syntax, while <my_component> , <myComponent> and <my_other_component> are not. You must keep this notation, because the HTML parser will differentiate between custom and regular elements.
• You can't register an already existing tag.
• Custom elements are not self-closing. Only native HTML attributes allows this feature. Ensure that you write a closing tag (<my-component></my-component>).

Our first component is created, hard coded, and works. Wait a second… how does the .html template know that my .js file is correct for retrieving data? Aurelia works under one premise: convention over configuration. What does that mean? If we use the same name for both files, the framework automatically will map that JavaScript file managing the .html template, we do not write any configuration code (different from other frameworks). Now, it’s time to integrate it into our main page.

We just need to import the filename with the <require> tag. For other reasons, this tag will be in the top section of the page. Then, we just call the component:

<!--main-template.html-->

<template>
 <require from="./components/card-component"></require> //Remember to add the close tag

 <div class="main-content">
     <card-component></card-component>
 </div>
 
</template>

Launch your application, and you will see your component in action. In this case, we just defined one single property to be rendered from the .js file to our template. This is a very basic example, so don’t worry, the action is coming!