The following is an excerpt from the Planning And Angular Application Whitepaper by Todd Motto. You can download the full Whitepaper for free at telerik.com/campaigns/kendo-ui/planning-an-angular-application.
Planning an Angular (version 2 and above) application is something you may have already done or will be soon attempting. This whitepaper documents a high-level outline of things to consider when planning an Angular application, from tooling choices during development all the way through to deployment and performance strategies. There’s certainly a lot more to it than meets the initial eye.
Before you get started, you need to consider how you’re going to get the ball rolling – and keep it rolling. This usually starts with project management and discussing and agreeing upon particular toolchains to accomplish your next application.
To manage the development of the front-end application, you’ll minimally need to select the following software management tools to manage code, assets, and team members’ tasks:
|Software management tools||Examples|
|Issue and Feature tracker||GitHub, BitBucket, JIRA|
|Version control system||GitHub, BitBucket|
|Document/asset storage||Slack, internal network storage, cloud|
|Team Communication||Slack, HipChat, IRC, Google Hangouts|
|Task Manager||GitHub Org Tasks, Trello, JIRA|
Ensure that you and your team adopt the tools you choose, and frequently assess and improve your workflow. New applications and tools are released to the public all the time and you may wish to address new tools that coincide with features or things you feel are missing – and you’ll naturally adopt new tools as time progresses.
Accessibility, i18n (internationalization) and building for the correct environments are an essential part of any application. It’s not just deciding what to build, but how you’re going to build and support it. Addressing these considerations at the beginning of a project will enable you to clearly vision how you’ll implement the said features, such as accessibility concerns and i18n for example.
|Software management tools||Examples||Links|
|Internationallisation / Globalisation||Translations for different languages / Culture differences||https://angular.io/docs/ts/latest/cookbook/i18n.html|
|SEO||Yes, server-side render||https://universal.angular.io/|
|Progressive Web App||https://developers.google.com/web/progressive-web-apps/|
|Native Mobile App||http://docs.nativescript.org/angular/tutorial/ng-chapter-0.html|
Above are some examples for consideration when deciding baseline standards and types of support your application can offer. These details may differ per project, for things such as i18n and offline strategies, it comes down to the goals of your project.
Typically there are a few different approaches to development, such as Agile, Waterfall, Scrum, Kanban and likely many more adaptations.
Whichever approach you take, it’s important to remain consistent. The processes I’ve found to be ideal are the custom, loosely enforced, agile-like processes that can be wrapped around the uniqueness of the project and team members.
Package managers allow you to grab dependencies from an external host, for example using npm to fetch your dependencies for development and also any dependencies that will make it into production.
An example of this would be using a development dependency such as TypeScript, which will never make its way into the browser as it’s pre-compiled locally during development and for project builds before deployment. An example of a dependency that needs to make its way into production would be parts of Angular itself, such as Http, core and other modules.
Here are a few examples when considering a package manager.
Task runners will allow you to configure particular tasks depending on what you’re aiming to achieve. Managing third party code and their dependencies should not be a manual task performed by a human, it’s not productive.
For example, you can use a particular command from a task runner to start a local server, compile all assets and then serve those assets in your browser with ease. WebPack has become the default standard with Angular as it can run your tasks, tests, compile your code and serve locally – as well as much more.
When working on a team, the goal should be that each file is written as if it were coded from a single developer’s mind in regards to error prevention, formatting, and style. Three main types of tools (i.e. code linters/hinters, code style checker, and a code editor config file) aid this process and should be properly implemented and configured before coding begins.
|Linters / Hinters||Codelyzer, CSSLint, ESLint|
|Code style checker||ESLint|
|Code editor formatting/style||.editorconfig|
The Angular CLI will allow you to do most of the above, all in a single environment. Using the CLI will allow you to create new components, directives, services and more via commands in your terminal. You can also serve the app, run local servers, build and compress styles (Sass) and compile the application for best possible performance. I’d highly recommend checking it out and building applications with it.
Building web applications means that you are likely going to require some additional UI components beyond what the browser itself has to offer. Textboxes, labels and dropdown lists will only get you so far.
When it comes to UI components, there are a lot of great options. You can choose either commercial or open-source components. The important thing is to pick a component library which is built on Angular, not wrapped with it. If the underlying components are not built specifically for Angular, you will lose much of the advantages that Angular offers, such as Ahead of Time Compilation, tree shaking, server-side rendering and more.
|Kendo UI||The popular commercial Kendo UI component library. Built as pure Angular components and fully supported.|
|Angular Material||An open-source library containing many of the components needed to create applications which adhere to the Material Design specification.|
|Bootstrap||A baseline CSS framework that is often used for application layout and it’s popular grid system.|
How you test and what you test is less important than the fact that you test something. It’s likely the case that you’ll want to test each module or unit of code by writing unit tests. When all of the units of code unite to form a running application, you’ll want to do functional end-to-end testing. Below I detail the tools required (tasking tool facilitate all this) to do cross-browser unit and functional testing.
|Jasmine||The Jasmine test framework. provides everything needed to write basic tests. It ships with an HTML test runner that executes tests in the browser.|
|Angular Testing Utilities||The Angular testing utilities create a test environment for the Angular application code under test. Use them to condition and control parts of the application as they interact within the Angular environment.|
|Karma||The karma test runner is ideal for writing and running unit tests while developing the application. It can be an integral part of the project’s development and continuous integration processes. This chapter describes how to setup and run tests with karma.|
|Protractor||Use protractor to write and run end-to-end (e2e) tests. End-to-end tests explore the application as users experience it. In e2e testing, one process runs the real application and a second process runs protractor tests that simulate user behavior and assert that the application responds in the browser as expected.|
You can read more about Angular via the documentation.
Gone are the days where we can just build an application purely for the browser environment. We’re at the stage where, without necessarily knowing it, we’re writing code in a format that can run pretty much nearly anywhere. Under the hood, language parsers such as Babel or TypeScript convert our code into an AST (Abstract Syntax Tree). An AST is a chain of commands that describe our code, at a higher level. This means that we’re not limited to the original language it was written in. People can then (and already have for most cases) write programs that interpret these ASTs and spit them out in whatever language is needed.
Via an AST, things like NativeScript exist to transform that AST into native code on mobile for impeccable performance and native experience.
For your application, you need to consider the initial environments you’ll be deploying to, as well as any future considerations – such as NativeScript for native mobile applications (it’ll compile your Angular code for you, reusing 90%+ on average of your existing codebase).
If your application will only run in a browser, then your strategy will be fairly simple. You’ll be able to deploy to a single environment and the code will run in the browser like any other web app that’s “browser only”.
A single blog post is not enough space to cover all of the aspects of planning and Angular application. Download the whitepaper, which includes all of what we’ve covered here as well as Mobile and Desktop, Style Guide and Architecture, State Management, Progressive Web Apps, Backend APIs, Performance Strategies and much more.