Code Structure
Learn how is the code structure of an Ionic Framework App and in particular how Ion2FullApp code is structured. Learn Ionic Framework with this complete Ionic Template.
Last updated
Learn how is the code structure of an Ionic Framework App and in particular how Ion2FullApp code is structured. Learn Ionic Framework with this complete Ionic Template.
Last updated
Ionic 3 is very different from Ionic 1. We have much experience building apps and themes with both of them and let me tell you that in my opinion Ionic 3 is much more mature, stable and understandable than Ionic 1. Many hard things that require workarounds with Ionic 1 are now trivial to implement with Ionic 3. It’s clearly a step forward!
In this section I’ll do my best to explain you the basics of an Ionic 3 app so you have a better understanding on where to start and where to focus.
There are three main folder structures in an Ionic 3 app:
App: has all the files needed to bootstrap the app and the main structure we will build the app upon.
Pages: as you imagined, here goes all the app pages html, js and css. Including models, services to access backend data, etc.
Theme: this folder contains all the superpowers of Sass (variables, mixins, shared styles, etc) that makes super easy to customize and extend the app.
And there are other secondary but also important folders:
Components: here we included custom components that enhance the user experience of our full starter template app.
Assets: in this folder you will find images, sample data json’s, and any other asset you may require in your app.
If you want more information, please refer to Ionic Getting Started pages.
It’s the main entry point of our app. It defines the basic structure and initial navigation of the app.
In our case we have a combination of tabbed navigation and side menu navigation. In this file we define which page would be the first one and the options and navigations of the side menu. It’s also where we get notified when the platform is ready and our plugins (cordova, native stuff) are available. That enables you to do any higher level native things you might need.
Here we define the navigation and it’s root. Also, as we have a side menu, here is where we should place it’s layout.
This file includes the main angular 2 module (NgModule) of our app. It’s also the place where we should declare the vast majority of our dependencies, such as pages, custom components, services, etc.
This is the main entry point for our app sass files/styles. Here is the place you should include your app shared imports and global sass you may use and apply globally. Additionally, this file can be also used as an entry point to import other Sass files to be included in the output CSS.
This is NOT the place to include shared Sass variables. You have to define, adjust, add those in "theme/variables.scss".
This file takes care of the bootstrapping of app.
Each page has its own folder and within that folder you will find every related file for that page. This includes the html for the layout, sass for the styles, the data modeling for the content that will fill the layout, any additional service to access the data that will be presented in the page and the main page component.
Let’s have a closer look at what I’m talking about deglossing the feed page.
feed.html
All the layout for the page. Everything we do is crafted using cutting edge techniques and technologies and we always code towards customizability and ease of use. We also make use of the awesome ionic 3 components.
feed.model.ts
As you may know Angular 2 relies heavily on typescript and object oriented programming. It’s a good and recommended approach to follow these principles along the way, That’s why we create models to represent the data that’s going to be presented in each layout. That’s what you will find in these files.
feed.scss
Centralized styles for this page. This app structure makes it easy for you to know and centralize in one place where you should change stuff.
feed.service.ts
In this file you will find methods to access and pull the data that will be presented in the page. This is where you should call your backend API. In our case we are using sample data pulled from a series of json files.
feed.ts
Here are all the functionality and interactions of the page and where the view logic should go.
Here you will find all the variables, mixins, shared styles, etc that makes this app template so customizable and extendable.
Maybe you don’t know Sass, in short is a superset of css that will ease and speed your development cycles incredibly.
common
Under the theme/common folder you will find (classified by component/functionality) all the shared styles, this way we encourage code reuse and prevent DRY.
variables.scss
This is the predefined ionic file where you should include all the variables you may use in your app. In our case we defined all the colors used within the app in easy to change variables so you can play around and try different color schemes.
These are custom components we created to improve the user experience of our app template.
background-image
This component adds a background image to the desired html element and clips itself to fill the area of that html element.
preload-image
This component prevents your content to jump around while images load. We do this by specifying an aspect ratio for the image you want to load and applying the technique described in this article.
color-radio, counter-input, rating
These custom inputs/components are meant to improve the user experience in forms, filter pages, etc. You may find them handy depending on your use cases.
show-hide-password
In mobile devices sometimes is hard to type and is very common you miss some character when typing passwords. This directive let you show/hide the unmasked password so you improve user experience by avoiding typos on passwords.
Here go all the images you may use in your app as well as other assets.
In our case we simplified the data layer of the app by creating a series of jsons with the sample data of each page. We followed this path because there are so many options and flavours when it comes to backend implementations that it turns impossible to provide examples for every option.
