my-company-frontend

My Company Frontend - Monorepo

View the Project on GitHub

projects/my-company-frontend CircleCI

This frontend application/s is a mono-repo version of the lab, and represents a predecessor of a multi-repo version. It conusumes a REST API (Java, Spring Boot, Eventsourcing, CQRS), and enables you to manage blog posts, projects and teams of a ‘fictitious’ company.

Monorepo

Instead of having a large monolith, we have dozens of small libraries with well-defined public APIs (and an Nx Workspace ensures you only use your libraries’ public APIs).

At this stage we have one deployment pipeline for all projects (apps & libs). In addition, all projects in the repository share the same dependencies. Hence, there are no version conflicts because everyone has to use the same/the latest version. And you don’t need to deal with a private NPM registry when you just want to use your own libraries.

Benefits of monorepo

Drawbacks of monorepo

Architecture overview

Feature Components vs Presentational Components

Feature and Presentational Component Design pattern has been called many things such as:

Feature components

A Feature component is a top level component that contains all other components in our feature. Our feature components are organized and packaged into modules(ex. blog.module), but they are not exported for use on templates of other modules. They are rather used as a routed components.

Feature components are responsible for gathering data from various services for our feature to use. If our user saves data the feature component is responsible to pass that data to our Angular Services to save the data to our server API. Feature components are very slim with the amount of application logic. We try to defer this logic to Services if possible. For this example the blog.component is our Feature Component and it is composed of many Presentational components.

Presentational components

Presentational Components behave like pure functions taking in the data via @Input and emitting data via @Output. This allows the majority of our UI to not know the underlying implementation detail of where the data came from. For example a side-item.component takes in a @Input of an item to display. This allows the side-item.component component to have the only responsibility of rendering the item when the data is passed to it.

Many if not most Presentational Components can be abstracted into a style guide or UI library for the project. Using a shared style guide for an organization or project improves reusability, increases the consistency between the different views that form a web application and encourages the communication between the different teams. It can also ensure that a unified brand is used across different products. To get ideas of component design and style guide maintainability I recommend Brad Frost’s book Atomic Design.

There are downsides to this though. As the feature grows in complexity we may have a deeply nested component structure. Since presentation component events only bubble up one level at a time we will have to manually pass up to each parent component. Introducing other sub feature components (blog-list.component, blog-detail.component, blog-new.component can help elevate this. The communication between feature components is event driven, and enables loose coupling. For example a blog-new.component will trigger an event on successfull creation of a blog post, and blog-list.component is subscribed to it so it can re-fetch and refresh a list of blog posts.

Let’s place components into a layout and articulate the design’s underlying content structure:

Home template

My Company - Home

Blog post detail ‘template’

My Company - Blog

Theming our custom presentational components

Our application supports use of potentially unlimited number of different themes. This is useful in itself but these themes will only style components provided by the Angular Material library itself.

We put our general layout and styling to the main-list-blog.component.scss, but we also create a new file main-list-blog.component.theme.scss where we are using style rules which have something to do with the color. In our mixin, we retrieved all the necessary theme variables needed for the styling of our custom component.

To use our custom component theme, we have to include it in the application styles.scss file.

Running instructions

This project was generated with Angular CLI using Nrwl Nx.

Quick Start & Documentation

Watch a 5-minute video on how to get started with Nx.

Development server

Run ng serve --app=my-company-ui for a dev server. Navigate to http://localhost:4200/. The app will automatically reload if you change any of the source files.

Code scaffolding

Run ng generate component component-name --app=my-company-ui to generate a new component. You can also use ng generate directive|pipe|service|class|guard|interface|enum|module.

Build

Run ng build --app=my-company-ui to build the project. The build artifacts will be stored in the dist/ directory. Use the -prod flag for a production build.

Running unit tests

Run ng test to execute the unit tests via Karma.

Running end-to-end tests

Run ng e2e to execute the end-to-end tests via Protractor. Before running the tests make sure you are serving the app via ng serve.

Generate documentation

We are using Compodoc as a documentation tool for Angular. It generates a static documentation of our applications and libraries.

Build static documentation

By running the command below, a static documentation will be generated in ‘documentation’ folder.

$ npm run compodoc:build

Serve static documentation

By running the command below, a static documentation will be generated in ‘documentation’ folder and served on http://127.0.0.1:8080.

$ npm run compodoc:serve

References and further reading


Created by Ivan Dugalic@lab. Need Help? Join our Slack team.