Modular platform using Angular — Part 2

Link to part 1.

In the first part, we prepared the platform application that will load our Plugin. At this part, we will develop our plugin.

So first of all, we will create a new angular application that we will call file-explorer.

// Let's generate the plugin app
ng new files-explorer
// move into generated application
cd files-explorer
// add shared-api dependency 
npm install [PATH_TO_SHARED_API_PACKAGE_DIST] --save-dev
// generate main module (entry point module)
ng g m entry-point
// create our file-displayer component
ng g c entry-point/display-files

The file-displayer will use the FileAPI.getAllConfigFiles() method to retrieve the different files to display, so we will inject this class into our component constructor.

Use the code below for the display-files.component

Now to test our display we may provide a fake implementation of the FileApi, so let’s change the app.module.ts and provide our fake service

Now, you can see that we need to create real entry component for our plugin, it’s the files-explorer.component. Using the cli let’s run the command below:

ng g component entry-point/FilesExplorerComponent --flat

Why flat ? to tell the cli to generate the component into the entry-point folder and don’t create a new specific folder for it. But you may reorganize the folder on your way. Just don’t forget to update the component reference in the public_api.ts

The FilesExplorerComponent will embed the different component that we will use for our plugin. This component looks like below:

To start developing our extension into a Sandbox mode (isolated), we need to export this component in the entry-point.module so we can use it in the app.component of our plugin.

Let’s update the entry-point.module like below:

Now, let’s update the app.component.html of our plugin:

At this point, we need to show how our plugin will looks like ? so let’s run :

ng serve

Go to http://localhost:4200

Providing a fake implementation can help our team members to develop their plugins (extensions) without taking care of the implementation of this kind of shared API. So they develop the plugin in a sandbox and a non blocking lifecycle.

At this point our plugin is ready, let’s build it and loaded using our platform.
As you can see, our plugin is a full angular application, but in our case it should be delivered as an angular module, this is why we will build only the entry-point module that we have created.

Creating a full angular application was to facilitate debugging and developing the plugin, but the packaging will contain only the required entry point module.
In our team we were dealing with gulp and rollup to build only the required module, but when ng-packagr was released we have found it as the best solution for our build scripts. After that, it was adopted by the angular-cli team at the V6 and now they use it as a packager for the angular project generated by the cli.
So let’s add ng-packagr dependency

npm install ng-packagr --save-dev
// mkdir ng-packagr folder, it will contain specific config
mkdir ng-packagr

add the files below to ng-packagr folder
- tsconfig.packagr.json contains the required config
- build.ts contains the build runner for ng-packagr

We need to add a custom ng-packagr configuration into package.json of the plugin.

The public_api.ts file is required to export the entry-point component, it will be used by ng-packagr to perform the final bundle. We need to create this file like below

Let’s update the tsconfig file and the package.json script section to add the build:module task.

Run the command below:

// using npm
npm run build:module
// using yarn (i'm in love with yarn)
yarn build:module

The log will display how ng-packagr is processing

After finishing, you will get the different bundles into the different target type (umd, esm, fesm,…).

The part two is ready now, we will go back into our last article (Part 3) to show you how you will load this already built umd bundles into the main angular application which is our platform.