Real World App: Part 24 - Angular Workspace

Akshay Nihalaney

Follow

Published in

Real World Full Stack

4 min readNov 17, 2018

--

Using Angular workspace to split up the app into project application and libraries

Workspace - Photo by Tyler Nix on Unsplash

This is Part 24 of our Real World App series. For other parts, see links at the bottom of this post or go to https://blog.realworldfullstack.io/. The app is currently under development and can be viewed at https://bitwiser.io and the github repo can be found here.

Angular workspace

A workspace is a way to split up your application into smaller units called projects. There are 2 types of projects - library and application.

A workspace library is a logical grouping of modules that can be re-used across workspace projects. A library can also be published & distributed to be re-used in other applications.

A workspace application is a single-page application (SPA) that may or may not consume one or more libraries.

Angular introduced the concept of workspaces in version 6. Prior to version 6, the concept of workspaces was introduced by the nrwl.io team - https://nrwl.io/nx.

Why workspaces? Why now?

The admin module of our application was never meant to be part of the main app. Even though the module was lazy loaded and behind a route guard, the admin users are different from the users of the rest of the site. Also, the functionality of this module is so distinct from the main site, that it’ll almost never be used along the main site. The state that supports this functionality is different than the state that’s on the main site.

As our main app is reaching minimum viable functionality, we also need to start development of our mobile app. This will only add to the complexity of the existing application. The mobile app will not have any of the admin functionality.

This part of the series will focus on simply refactoring our existing application into 3 Angular projects - we will create 2 application projects (trivia and trivia-admin) and one library project, for now, that’s shared between the two. Let’s get right into it.

Generating the new application

First we’ll rename our project in angular.json temporarily, so we can create another project with the same name. Let’s rename our project to triviatmp in angular.json

Next, let’s generate a new one -

ng generate application --name=trivia

This would generate a new project under /projects/trivia and create a corresponding section in angular.json. Let’s the /projects/trivia/src with our /src folder, and then replace the /projects/trivia-e2e/src with contents of /e2e.

Next, we modify angular.json, project trivia to match triviatmp (including styles, assets, serviceworker, dev build configuration), but keeping the folder paths the same. Let’s try it out -

ng serve

Note: I did have some incorrect import paths that I needed to fix.

Remove the tsconfigs and typings from inside the projects/trivia/src folder as they are now at the project/trivia level.

For unit testing

I also had to modify the jest setting in package.json (path to setup and tsconfig.spec), had to move the setup-jest out of src and modify the path to mocks.

For e2e testing

Simply remove protractor.conf.js from root folder and then use command “ng e2e trivia-e2e”

Trivia project folder structure -

Admin & Shared library projects

Let’s create the other projects. This will also modify our angular.json -

ng generate application --name=trivia-admin --prefix=app
ng generate library --name=shared-library --prefix=stl

We would then carefully replace the contents of each of the src folders of these projects with what we need from our main project.

The core module along with the services and the shared module with our model will be moved to the shared-library project.

Admin and bulk (for admin) modules will be moved to the admin project. Our application folder structure for the 3 projects will looks something like this -

To run these applications -

ng serve triviang server trivia-admin

The complete code for this part is here. Even though the PR shows a daunting 852 files changed, most of this is just moving the files around and changing import paths.

Next up

In this part, we broke up our app into more maintainable workspace projects. In the next part, we will introduce NativeScript and start developing our mobile app.

If you enjoyed this article please recommend and share and feel free to provide your feedback on the comments section.