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.
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.
Feature and Presentational Component Design pattern has been called many things such as:
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 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-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:
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.
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.
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.
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.
ng test to execute the unit tests via Karma.
ng e2e to execute the end-to-end tests via Protractor.
Before running the tests make sure you are serving the app via
We are using Compodoc as a documentation tool for Angular. It generates a static documentation of our applications and libraries.
By running the command below, a static documentation will be generated in ‘documentation’ folder.
$ npm run compodoc:build
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