Similar to the Angular 4 release, this isn’t a core change to the platform, rather it is adding some improvements to your applications that will increase overall performance and allows hybrid app development to come a few steps close to being on par with its native development counterparts.
As always here is some useful Ionic reading material. And here is the official post from the Ionic team specifying all the changes.
Updating from Ionic 2
Updating from Ionic 2 is actually quite a simple process. This video from Paul Halliday simplifies the process even further:
Ionic has been updated to be compatible with Angular 4 and all the features that come with it. You can find our Angular 4 release post here.
And the official Angular blog covers it here aswell.
One of the most notable features of the release, lazy loading provides us with the ability to breakdown our bundles for our application even further.
This allows our application to only load certain bundles/modules when they are actually needed. When you lazy load, your application performance improves, particular as the app is starting up because all the modules that were previously loaded in our app.module.ts are not requested at once rather they are loaded on a page by page basis.
I would highly recommend checking out Paul Hallidays tutorial on this:
TypeScript 2.1 and 2.2 compatibility
As specified on the official Ionic blog. Ionic 3 has been updated to be compatibly with Typescript versions 2.1 and 2.2. This is inline with **Angular 4 ** being compatible with these versions as well. More information can be found here.
A Promising future
So that just about summarizes the main changse for Ionic 3. I don’t think anyone can deny the momentum and progression that this framework has going for it.
While originally I was concentrating on all things Angular. Ionic has really provided such a sleek way to use web technologies in order to reach such a wider userbase and to target them more personally through mobile applications.
If you needed even more detail regarding Ionic 3 changes please check our Joshua Morony’s detailed guide here:
I highly recommend all his content as it provides a huge insight into all potential features you might want to implement into your application.
If you missed our last Angular post please check it out here.
Some directives will go beyond the scope of this post but be sure to check out this awesome Angular book by Nathan Murray for additional information.
Not much has changed in terms of directives for Angular 4 so this post will be a general directive overview mentioning Angular 4 directive changes where appropriate.
An attribute directive tends to change the look and behaviour of an element. Whereas a structural directive will manipulate the DOM and add or remove elements depending on what action the structural directives apply.
A Component Directive uses the shadow DOM to create encapsulated visual behaviour that is typically used to create UI widgets.
We will start with attribute directives and how this interacts with our DOM and data.
We can also differentiate a component from a directive using this handy table provided for here.
You can create your own attribute directives or you can use Angular’s built in directives.
The let key is part of the Angular template syntax. It creates a local variable that can be referenced anywhere in that specific template. let also creates the index i and keeps it as a reference to the current whiskey. All this is done under the hood of this directive.
What if we wanted to style the first and last item in our ngFor directive? This is actually made relatively easy by using let again to assign the first items to variable first and last to variable last.
<li style="list-style-type: none;">
To be as efficient as possible, ngFor will attempt to not remove and recreate these DOM elements and instead to reuse and recycle when possible. This helps with performance and prevents significant slowdown in our DOM.
Here is a simple example that combines input button events with ourSwitchCase loop. Based on the number that value returns which is changed depending on which button is clicked, one of the divs with the *ngSwitchCase will be displayed.
NgIf adds or removes an element or elements from a sub tree based on the condition specified.
If the expression assigned to ngIf evaluates to a falsy value then the element is removed from the DOM, otherwise a clone of the element is reinserted into the DOM.
This would be similar to how the display: none property behaves in CSS.
The NgModel directive allows us to provide two way data binding to our HTML element. Whatever we type in the input field will reflect in our name element. In our sample Plunker we had to import and declare our FormsModule in order for this to work. The name attribute should also have the same value as our ngModel.
Creating our own Attribute Directive
I will be going over the fantastic introduction to creating our own directives from Angular University.
We can also create our own custom directives in Angular. In this case, this directive can be applied to any HTML element on the page and will hide this element when it is clicked.
Firstly, we need to import our Angular Directives from Angular core library into your component file.
We then need to then initialise our directive meta data decorator with the selector property of our choice. In this example its HideElement.
We then want specify the CSS classes that we want to use for the fade out transition.
And we also need an action to occur when the element is clicked so we will create a function called toggle.
We than want to use a click event that will trigger the function “Toggle” that will add or remove this fade out css class but we will not be using Angular’s(click) event so how exactly will we accomplish this?
Well, we will use the Angular directive HostListener from Angular Core. Using a Host Listener, Angular will invoke the decorated method (in this case toggle) when the our html element emits the event (when clicked).
In order to access and change properties of the Host Element we must use the HostBinding Decorator. This will check the host binding properties once a change is detected.
For a more detailed explanation of creating your own Angular directives check out this tutorial from Rangle.
If this helped you out be sure to check out our resources page for more recommended reading material on Angular.
One of the most straightforward ways to demonstrate Ionic Native and how it works is to use the GeoLocation native plugin. This will allow us to use a range of methods that will configure the the users current GeoLocation and we can then use this information in combination with a Google Maps implementation as well.
There is already some well established tutorials for achieving this so I’m going reference them in this post whilst also giving an overview for those that don’t have to time to implement their own example.
Please also keep in mind this excellent Ionic 2 book that will get you up to scratch very quickly.
And these articles by Toptal might help you to further understand Ionic concepts:
With your Ionic 2 project already created we need to install the cordova geolocation plugin here.
ionic plugin add cordova-plugin-geolocation
This plugin will provide information about the current users device’s location, such as latitude and longitude. When starting the application, the user will receive a dialog asking for permission to use the current location.
This is a standard practice as some of the native plugins want to ensure that the user is content with sharing certain information with our Ionic 2 application.
In our created Ionic page, where we want to display our Google maps instance, we need to import our GeoLocation plugin from ionic native so we have access to it in the page.
We are just invoking the .getCurrentPosition() method on the imported Geolocation object. Afterwards or .then(), we assign the current value of our location variable to our components location variable of type any that was declared earlier in the component.
In our html file we are now able to output a value for our coordinates by accessing the properties for coordinates (.coords) and for the latitude value of those coordinates (.latitude) as well as the longitude (.longitude) on the location object.
While getting a GeoLocation is handy to know, what exactly should we do with the users position? Well you could implement the retrieved coordinates into a Google Maps implementation in your App.
There are two main ways to do this.
The first is to install Angular Google Maps. This is very well covered in the video tutorial below by Mindspace.
Fast forward to about 21:37.
And if you have the time, be sure to watch part 1 and 2 in its entirety as you will come away with a full application with some nice Ionic Native functionality.
However, for both cases you might as well generate an API key as if you were to ever to implement your app into a production environment or upload it to the app store there is a usage limit Google has and you might have to pay in order to remove the limit.
We then just need to reference the map id in our template HTML.
By default, the div containing our Google Maps object has no styling properties. We need to change this order for the map to display properly.
Overall, I hope that this post has given a good indication of how to use Ionic Native plugins and from that point how to combine them together.
I didn’t want to provide too much detail as there is already quite a lot of fully fledged tutorials on this.
However, if you followed the links and references in the tutorial provided there is plenty of information to digest but bear in mind that the way you implement Ionic Native functionality never really changes, its just the built in methods and functions of the particular Ionic Native plugin that you are using that will be different.
I’m far from an expert in Ionic 2 but as I’m getting to grips it, I’m becoming more comfortable with Hybrid App development and want to share what I’m learning so be sure to check out our future posts on it.
I’m thinking about covering the changes in Ionic 3 and what it means for the framework.
Please check out our resources here for additional reading content.
A lot of this post stems from Josh Morony’s Ionic Google Maps & Geolocation guide so be sure to check his post out and his great Ionic 2 content in general.
Angular 4 was fully released on 17th March. In this post, I hope to address any confusion or niggling worries regarding how this affects current Angular projects and how exactly these changes could benefit your next project.
If you are baffled as why there is already a 4th version of Angular I covered semantic versioning in a previous post here.
Flat ES Modules
Most of the changes in Angular 4 comprise of performance improvements for the framework. Perhaps the most significant one is the introduction of Flat ES Modules that treeshake your application for you.
During the ng-build process, the compiler deems certain code unnecessary because it has no usages. The compiler then removes this code in order to reduce file size and to make the application more lightweight.
Since the scheduled announcement of Angular 4, the Angular team have been reassuring everyone that this change will not affect the way your current applications run. When upgrading your application to Angular 4, there will be a seamless transition for the most part.
This seems to be the case as I have only experienced one issue and this is with the AngularFireBase package which the developers for it has stated that they haven’t made it fully compatible with it yet .
If you have experienced this issue you can also follow this excellent tutorial by Coursetro to get Firebase working with Angular 4.
This tutorial is very insightful and solved my Firebase issue.
You may also experience a similar situation with some of your libraries and packages but the core features from Angular 2 seem to function just fine.
The way animations are imported has been cleaned up for Angular 4. Instead of importing the various types of animations such as state, keyframes, trigger etc,
You now specify an import that contains tools and assets for animations in one package. This isn’t much but it does feel less cumbersome to set up an animation for a component.
The browser animations modules should also be added to your app.module.ts file for this to function properly.
When using the ngIf directive we never had the ability to add an else clause to the statement. This has been addressed in Angular 4, we can use the element <ng-template> to specify the name of our else condition by specifying it after the # symbol.
Please note that <template> is now deprecated and is replaced by <ng-template>
Perhaps one of the handiest changes, an email validation directive was added to input elements. This saves us from having to manually create regular expressions to validate a users email address.
Simply add this to an input field element just like you would for the required directive and our email input field will automatically have validation.
This is actually quite a useful feature as it applies an email validating regular expression pattern to our element using just one keyword.
You can, of course still create your own custom expressions for validating emails and other input fields.
I hope this post has reassured you that this new version of Angular isn’t as significant as the version increment might make it sound. Some nice changes here lets us utilise some conditions and statements a bit more as well as cleaning up some of the imports.
Following on from some of our Angular 2 posts, the next logical step was to delve into the Ionic 2 framework to see what it has to offer.
What is Ionic 2?
This is very advantageous for the developer as it allows him/her to create and publish mobile applications without having to be proficient in their native programming languages (e.g Java for Android).
This allows us quick access to a multitude of structural components to use for an application.
For example, one of the most basic components, cards would use the following markup.
<!--Add card content here!-->
As you can see custom HTML tags can be used to generate this structure with outputting a result like so.
There is a whole host of different components like this with usage examples for most so be sure to experiment with different combinations
You’ll need to install the latest version of Node before installing Ionic. Once installed you will have open up your command line and type.
npm install-gionic cordova
This may take a few minutes.
To create a blank new Ionic project in your current directory you should then use the command.
ionic start MyProject blank--v2
However, we also have other options to create our Ionic application. Ionic will generate some of the applications structure if we specify in a different command.
$ionic start myApp tabs--v2
We can also generate a project that has a fully integrated sidebar using the command.
ionic start myApp sidemenu--v2
These templates tend to be very useful when you want to scaffold a prototype as fast as possible.
While the custom layout elements provide a variety of ways for you to creatively structure an application, the plugins or (Ionic Native) are also an extremely useful feature. They are a set of plugins that add native mobile functionality to your application. To install one simply use the command:
Ionic plugin add plugin-name
The plugin has now been added to the project. You can check it out in the plugins folder
Like most packages/plugins that you add in we have to import it at the top of the desired component where it will be used.
I hope this post gave you an insight into how Ionic can benefit you for hybrid application development.
We’ll be sure to cover more interesting topics about it in our next post. Including how to publish to an application to the Android SDK. Be sure to have a look at our resource page for any other useful reading material.
If you missed our last Angular post please check it out here.
So SASS (Syntactically Awesome Style Sheets) are an already well established and renown pre-processor for CSS. It allows the developer to create modular CSS where classes can nested inside each other. To summarize is benefits, it allows you to write less and customize more.
It also has a whole host of features including variables for colors,urls, fonts etc, while also having, mixins, extending/inheritence and operators.
You will write all your SASS code in a .scss extension file. The compiler will then output this into a css file based on the nested structure of your classes.
Having already seen the structure of Angular’s component based architecture you might wonder what exactly is the best way to implement SASS to an existing project.
And although I could show some of Sass’s great features, I will concentrate on whats important in the context of an Angular application.
And here is a great book resource for learning Sass and Compass if you wanted to really hone your Sass skills.
There are many different application you can use to get going with Sass you can pick your own preference here.
I personally use Koalaits a nice GUI 3rd part application that looks for a scss file in a specified file directory and then compiles it to a css file.
Once you open Koala navigate to your desired project directory.
When you find the .scss file you want to turn into css, simply press compile once you find it in the directory. Koala will also has real-time compilation and will listen for the file changes in this folder.
It is also cross platform so it will run on Windows, Mac and Linux.
An ideal Sass structure would have folder called partials. Each file in this folder would have many different scss files that would be prefixed with an underscore.
Each file would adhere to a specific part of a website for example home, about, navigation.
All of these partials are then imported in the main .scss file ( usually called global.scss or style.scss). This one file is then compiled into a css file that is used for the whole project.
This is deemed as one of the most efficient ways to manage the styles of your project as all your css is compiled into the one file. However, in an Angular project there are two different approaches.
The easiest way to get going with SASS in an Angular project is to create a project in your command line with the styles set to scss.
This will scaffold a project for you that will contain an app.component.scss file that will automatically be compiled for you without the use of a 3rd party application like Koala.
If you wanted to setup up your own styling structure once you create an Angular project through the CLI you should note that
each component generated has its own css file specific for that component. So if you create a Sass file with the component’s naming convention eg home.component.scss Koala will detect this and will compile it to home.component.css.
So instead of having a partial import system we just have individual sass files that are unique to the component.
I’m sure there is an argument for using both methods but this is the method I personally use. It makes the most sense to me as it aligns with the way an Angular project is typically structured and goes hand in hand with using the Angular CLI.
To give a practical example of using Sass in Angular I’ll focus on styles for form validation.
For validating forms in Angular we can use preexisting classes that correspond to the state of on input field or select box.
These classes are:
These classes are self explanatory for the most part, ng-touched is applied when the input field is written in, ng-dirty is applied when
The ng-dirty classes indicates when the form has been modified by the user. The opposite of this is the ng-pristine class which is applied as long as the form has not been modified by the user.
In Sass we can add appropriate styles to these classes to indicate when an input field is empty, invalid, not yet entered etc;
Here is an example of adding relevant border colors to these input states.
Although styling might seem quite arbitrary in context of learning Angular. Sass allows you to be more efficient and modular when it comes to creating a beautiful Angular application. Its a very useful tool to use in combination with Angular and fits in nicely to the structure of a component.
If you are looking for anymore resources to learn Angular be sure to check our resource page here.
Following on from some of our Angular posts, we were itching to learn more. Where better to accomplish this than attending the most renown Angular conference in the Nordics?
The event took place in the IT University of Copenhagen. First of all, I would like to acknowledge how well thought out and structured this conference was. Going back and forth between two lecture halls was all that was necessary for the size of this conference. And the building allocated was the right fit.
Perhaps the most beneficial aspect of the event was the easygoing, relaxed environment it provided to network with other Angular enthusiasts. I know there are many who, like myself, are unable to to work with Angular in our day-to-day roles so to be able to be among a whole conference of like-minded people proved invaluable and motivating.
Before covering the guests in the talks, I would like to mention that the university itself was a sight to behold. The frozen-over lakes inside the university looked spectacular. This in combination with the incredible architecture of the university made it a fantastic venue for the conference and really solidified the Nordic feel. I’ll let the pictures do most of the talking here.
I’ll be focusing on 3 speakers in order to give you an idea what the conference was about.
One of the opening speakers, Kenneth, gave an insight into the future of specific browser based development(or lack there of).. You can find his slides here.
An increasing amount of the applications we are using will be able to obtain browser-like capabilities. The actual need to use a browser will diminish as time goes on. He demonstrated that originally browsers were designed to generate income through use or by providing browser start-up pages.
This is obviously not the case any more because we see that the functionality of a browser is paramount to daily web use. But as stated, this functionality is no longer exclusive to browsers.
Web applications provide just as much functionality as a browser and so the lines between the two become blurred. An increasing amount of the applications we are using will be able to obtain browser-like capabilities.
The actual need to use a browser will diminish as time goes on. He demonstrated that originally browsers were designed to generate income through use or by providing browser start-up pages.
As web applications provide just as much functionality as a browser then the lines between the two become blurred. From this point Kenneth predicts that if any web application is a browser, then a new meta platform will inevitably arise; e.g. React apps are created and viewed using Facebook as its browser engine.
This future prediction alludes to the fact that the frontend developer role will become a more intriguing space to be working in than it already is.
Tracy’s talk focused on Angular Material Design. While we have covered Angular Material on the blog before, I was really unaware of how powerful and seamless it is to integrate a quick materially designed functional layout.
She also has a informative series of posts setting up Angular Material here.
Tracy made an app on the fly that focused around animal puns which was quick to build due to the vast amount of readily available material design components.
Grids, sidebars, dropdown, indicators, popups, navigational components. These are all generated using a HTML tag attribute specific to the material design package.
Will generate a nicely coloured material design button.
For more on this you can see the component library here.
Overall, Angular material design seems to perform consistently fast as well as being fully optimized specifically for an Angular application.
I can already see myself using this to create an admin section of a website that is easy on the eyes with minimal effort.
To really simplify how Angular Material might benefit a development process, simply put, it allows you to build a structured grid quickly, with a wide variety of input components while also looking good in the process.
I was really fascinated with Uri’s talk. I had never previously seen an Angular 2 application interact with a piece of hardware. The ng-beacons not only looked great but also provided a new perspective of how Angular can connect to physical devices.
Uri also goes into more detail in his medium post here.
If you have any experience with physical computing, this was reminiscent of how a Arduino IDE would interact with an Arduino board to manipulate lights/temperature etc.
The beacon itself emits a low energy Bluetooth signal. Which is then outputted and detected.
The heat generated from the beacon is detected on a slider which is designed in material design.
3 volunteers were chosen to handle one of the beacons each. The heat generated from the participants moving was registered and updated in the sliders in real time over the Bluetooth signal.
You can find Uri’sGIT for the hot or not application here as well.
I really enjoyed this presentation. For me, it redefined how an Angular application can interact with a practical piece of hardware. I think there is a market for the ng-beacons within the Angular community as well.
There is currently no available way to purchase one of these beacons. But I’m sure the high niche demand created from the Angular community will enable this to be possible in the near future.
Although only three talks are covered here. A wide variety of Angular topics were covered throughout the duration of the conference. I hope this insight gives you an impression of what to expect next year.
The office hour segments in particular were extremely advantageous for those who took part in them.
If you missed the format of this, some of the speakers were available to speak to in an informal setting to give advice and answer your questions.
Now, we are moving onto something a little more visually apparent using some sample Whiskey data.
Our site looks something like this:
Here is our mock whiskey catalog used as the data for displaying the 3 different whiskeys.
newWhiskey("Jameson",22,'Florida','Jacksonville','An Oak that grew on the bank of a river was uprooted by a severe gale of wind, and thrown across the stream.','images/clontarf-whiskey.jpg'),
newWhiskey(" Wood Emerald",26,'Glasgow','Jacksonville','An Oak that grew on the bank of a river was uprooted by a severe gale of wind, and thrown across the stream.','images/kilbeggan_whiskey.jpg'),
newWhiskey("Paddys",42,'Ireland','Galway','his blend has always been a mix of both pot still whiskeys, grain and also some single malt.Paddy is best described as unpretentious and friendly,','images/clontarf-whiskey.jpg'),
desc:string="An Oak that grew on the bank of a river was uprooted by a severe gale of wind, and thrown across the stream.";
This component contains a class that initializes our imported Whiskey and WHISKEY_CAT classes.
From here, we want to be able to click on one of those whiskeys displayed to focus on it and display it in bigger dimension right above it.
We then want the clicked whiskey to appear inside a different div in a completely different component (whiskey.details.component).
This would be considered common practice in a typical website displaying a product catalog. They would have a style transition that highlighted one products chosen in a list by the user.
When understood, this should give you a good feel of how data flows down through components in an application. It will also show you how to utilize directives, while also showing you how the process behind how an event is handled in Angular 2.
Exposing selected data.
Our variable selectedWhiskey is assigned to a TypeScript export of a our Whiskey object. Just from being declared inside the WhiskeyListComponent class, selectedWhiskey is already exposed and accessible from our whiskey.list.component html file. We can bind our selected whiskey properties to our UI. In this case image src, whiskeyname and description.
But how will this component get access to the information from the clicked on whiskey? We need our application to take the properties of the item clicked on and to then pass it to our whiskey.details.component.
The @Input() decorator was added to our whiskey-details.component . @Input allows us to define an input for a given component. So our selected whiskey value can be put in as an data attribute and the value of it flows down to our component.
But what else is going on here? Well the object passed in our setSelectedWhiskey click method is referring to the singular whiskey at the current index using our *ngFor looping directive.
So when our *ngFor directive iterates through whiskeys in our whiskeyCat, whiskey is always referring to the current whiskey. When clicked the current whiskey is passed down to our whiskey-list-details.component.
We should now be able to see the selected whiskey in a different div from a our whiskey-list-details.component.
This is a very handy way of sharing a specific piece of data to another component. This is just one practical use of data sharing between components.
There are many other uses that I won’t cover here but make sure you check our resources page for any relevant reading material on Angular 2.
Overall, this is a simple example of how you would use Angular 2’s data flow decorators to control the flow of data to a nested component.
In essence, they are just a function that provides itself with instructions on what type of information it should expose it’s targeted variable.
This is a very basic version of this Angular 2 Whiskey application there isn’t a whole lot functionality here apart from the displaying the selected whiskey.
However, I plan to incrementally add bits functionality as I learn more about Angular 2 and its various techniques. I’m finding it be a very solid framework to be working with and something that I’m trying to specializing in.
The combination of TypeScript decorators and Angular directives really opens up the possibilities of your UI interacting with your data in different ways for creating feature rich applications.
Early GIT version
Here is very an early draft of this sample application for reference.
January has been a fairly quiet month regarding big notable Angular news. This is partly because a lot of revelations were revealed in November and December, highlighting the version changes of Angular3, and 4. Or more sensibly now called just plain Angular.
As of January 11th, Angular 2 switched back to an MIT open source license framework. While this has no bearing on any technical aspect of Angular, it does reassure developers how they can extend and modify Angular without any worries.
The Google Angular team actually prefers the Apache 2 license for scaffolding the legality of an Angular 2 project, but it was understood that the wider community has a better understanding of the MIT license.
While hardly a major cause for celebration, this is still a nice example of Angular reacting to community feedback. In short, a better recognized certification says you can happily publish your Angular applications without restrictions.
The Angular Material 2 beta has started, using the Angular CLI to install it. The beta provides high quality UI components using Angular 2 and TypeScript. These UI components are customizable within the Material Design specification. They also do not put a strain on the application by having low performance costs.
While Material Design definitely isn’t suited for everyone’s taste, its certainly nice to have the option as its neat, clean and has high usability Although, I think it limits creativity for UI designs to some extent.
In the context of an Angular 2 applications, functional design is incredibly important. If you value quick functional design over a design that has more visual fluidity and better creative processes, then you can’t go to far wrong implementing material design into it.
Heres some nice examples from the referenced sample application from the git.
A major release cycle schedule was announced, pinpointing the exact times where Angular are planning its forthcoming major releases.
Also you can check out a video detailing Angular 4 and version plans here.
A deprecation policy was also introduced so that any major releases that contain breaking changes to the API will automatically be notified well ahead of time.
If one had to guess of what a deprecation issue would look in the next major versions, then we could probably look back to when packages such as uibootstrap or ng-dialog from Angular 1 etc weren’t fully compatible with Angular 2. Similar forthcoming breakages might be comparable to these kind of previous issues.
It will be interesting to see how this effects the Angular job market, as there is plenty of Angular 1.x roles still available and probably will be for a very long time. In terms of maintaining projects and applications, many will still be developing on that version.
However, more Angular 2 positions are being listed everyday so it is likely that some previous features might be deprecated. This might accelerate the process of some companies adapting some of the latter versions.
As we grow, we hope to implement a job board that will have listings of some open Angular positions. Hopefully, this will connect potential employers with some of the developers from the JSdiaries community.
In simple terms, modules are the basic building blocks of our Angular 2 application, whereas routes provide us with paths to point to specific parts of our application. These are both core to an Angular 2 application. It is important to create both with good, clean separation of concerns in mind.
A standard application has different layers of components (or functionality) that the user can navigate to. This is where our routes come into play. These routes provide url paths to direct us to these different parts of the apps functionality.
Say we are creating an application that displays a list whiskeys. When the user clicks on a whiskey in the list, we want to display a page showing the detailed information about that whiskey. That’s just one piece of the application.
How about the user wants to search for a whiskey he has previously purchased? That’s another piece of similar functionality. Because these components are closely associated with each other in terms of purpose, it makes sense to create relevant routes in the same folder.
As a project of reference, I will be referring to my Whiskey shop application for example of the structure of its project directory. I hope to fully publish this within the next few weeks.
So for a basic application, we can just declare all these routes in our app.module.ts file (Our entry point for the application) . But what about more expansive applications with many different components to be directed to? We can then create a routing TypeScript file specific to a folder of similar components. This creates a routing system that is compartmentalized rather than declared in the one place.
For instance, say we have an actions folder containing a login, register and profile component. We can then create an actions.routing.ts file which contains the relevant route paths.
From here, we can export this routing file and include it in our App modules component.
For more detailed information on the Angular 2 router check it out here.
A module provides meta data for a particular section of your application. It is then exported and can be accessed by another component by importing it. This imports/exports system is made possible through TypeScript syntax.
The process of importing classes/components into other classes and components closely resembles something from Object Oriented languages Java, C# etc.
./ in an angular import means current directory. This is obviously something you’d be aware of while making an Angular 2 application but its nice to be reminded due to the amount of time you can waste trying to get the correct directory path.
By declaring similar components in the same module you get to have a cleaner components and separated logic. You can declare all imports that are relevant to those modules.
So as you can see we have consolidated some of our modules into groups. Our LayoutModule and ActionsModule contains more than one referenced component.
For example our LayoutModule contains all of the following modules from our layout folder. Just to note the layout folder is just name I gave the folder in this instance and is not an Angular 2 specific structure recommendation.
The components from this layout folder (FooterComponent, HeaderComponent, NavigationComponent) were declared and exported here:
This enables our app.module.ts file to be significantly cleaner because we don’t have to declare each individual component that we have in our application.
Another advantage of these components segmented by similar functionality is the ability to remove one from declarations if the developer wants to stop the use of certain piece of that particular functionality.
So just to reiterate we should assort all our module providers routes in RouterModule Object specific to that group.
We also no longer have to declare our routes here as we have our routes declared in our specific group components.
It is also regarded as good practice to separate your routes specific to what folders they are grouped in.
This allows you to have an Angular 2 application’s app.module file to not be overloaded with path references linking to different areas of your application. Instead, these routes will be located in a location thats relevant to the components it links to.
Our application is now nearly completely compartmentalized through the grouping of our modules and routes. Different types of functionality can now be targeted and contained within these groups.
I highly recommend this YouTube Angular Series by Lyrad Digital. The series provides some very useful information step by step, with the early videos in the series covering the best practices of routes and multiple modules. https://www.youtube.com/watch?v=33ADKstmXqQ&t=2351s