Planning An Angular Application

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.

Project management

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.

Software management tools

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:

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 and Environments

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.

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.

Development Process Methodology

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.

Tooling and Development

Tooling has been increasingly important when developing any kind of application for the web or other platforms. With Angular, there are a vast amount of tooling options available. System.js was introduced first, however WebPack has seemingly become the de facto standard across the JavaScript ecosystem. Let’s dive into some tooling a little further.

Package Managers

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

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.

Linters and enforcement

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.

Angular CLI

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.

UI Components

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.

Testing Methodologies

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.

You can read more about Angular via the documentation.

Codebase distribution strategies

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).

Browser only

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”.

Server-side rendering

Server-side rendering has a huge performance and SEO benefit to loading an Angular application directly in the browser. Because the Angular rendering core is split from the framework itself, we can essentially render a view on the server. Once the server has rendered the initial payloads, the client-side part of Angular can pick up where the server left off, hydrating it with JavaScript once Angular is ready. For this, you’ll need Angular Universal.

Continue With The Whitepaper

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.