DEV Community: Felipe Norato Lacerda

Feature and Behavior Schematics - The Composition Approach

Felipe Norato Lacerda — Fri, 27 Sep 2019 00:49:51 +0000

Some weeks ago I started to study how to create schematics to deliver faster and creating code patterns. I could try lots of techniques in this meantime to make the schematics to my team, like:

Use Template files;
Apply string manipulations;
Path manipulation to move files;
Filtering files by props.

And also my favorite one. That allows you to create complete flows, but without big complexity. This is the Schematic Composition!

This technique provides you to combine the schematics you created and external ones, like Angular schematics, to build powerful schematics that could create a whole structure for a feature.

It's important to alert you that this is a 20% technical and 80% philosophic post. 😂

I wrote a post explaining more about creating schematics and how to simplify that using just one line. There you can see how to apply path, templates, string manipulation.

Why is this technique so useful?

We can think we are using the functional programming approach. Each schematic is a function, that has its responsibility and could be joined by another Schematic to compose a big flow.

Sharing the responsibility to many functions we reduce the complexity, so it is easy to maintain and reuse.

Another big benefit in creating small schematics is when you need to create just a part of a feature or flow, you can call this one schematic alone.

There are some cases that you didn't have defined the design and architecture pattern at the beginning of the project. So we create some pages, start to define the patterns and, finally, create the schematics to each single component part of this pattern. When you start to revisit the old pages to apply the patterns you can just use the schematics you need to rewrite the old component.

Basically, we can use the Feature Schematic to create a new feature from scratch and the Behavior Schematic to compose the Feature Schematic to apply the new code to an existent feature.

I, personally, like to think in using the Feature Schematic like a Façade to join lots of Behavior Schematics and create a complete feature or flow.

The Behavior Schematics needs to be more generic as possible to be used alone and to compose many other Feature Schematics if it is required.

It is very important to define patterns of code and layout to make these schematics really productive, but how granular and how you will implement this is up to your needs.

Now I will explain to you how I implement the schematics to my current project and I defined the Feature and Behavior Schematics approach.

You can follow the examples on schematic-composition at my github.

The Behavior Schematic

To explain the conception about this we will implement a form and a table and create one behavior schematics for each one. To make it simple, we will use the angular material schematics to create the components for us. So here, is the first example: How to extend an external schematics

We just use the method externalSchematic with the collection name, schematic name and the options. 😄

import { chain, externalSchematic, Rule } from '@angular-devkit/schematics';

export default function(schema: any): Rule {
  return chain([
    externalSchematic('@angular/material', 'table', {
      name: [schema.name, 'table'].join('-'),
      project: schema.project
    })
  ]);
}

Here we reuse the @angular/material:table schematic and it generates some files.

The same we will do to create the form.

import { chain, externalSchematic, Rule } from '@angular-devkit/schematics';

export default function(schema: any): Rule {
  return chain([
    externalSchematic('@angular/material', 'addressForm', {
      name: [schema.name, 'form'].join('-'),
      project: schema.project
    })
  ]);
}

For both schematics, I set the same schema just name and project properties.

{
  "$schema": "http://json-schema.org/schema",
  "id": "form",
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "Library name",
      "$default": {
        "$source": "argv",
        "index": 0
      }
    },
    "project": {
      "type": "string",
      "description": "Library name"
    }
  },
  "required": ["name", "project"]
}

Feature Schematic

For this schematic, we can face it as the Façade to join the other schematics. The method to call the schematics from your collection is schematic, where you only need to pass the schematic name and the options. It's easy!

The extra thing I add here is the module schematic for the feature.

import { Schema } from '@schematics/angular/component/schema';
import {
  chain,
  externalSchematic,
  Rule,
  schematic
} from '@angular-devkit/schematics';

export default function(schema: Schema): Rule {
  return chain([
    externalSchematic('@schematics/angular', 'module', {
      name: schema.name,
      project: schema.project,
      routing: true
    }),
    schematic('table', { ...schema }),
    schematic('form', { ...schema })
  ]);
}

You can see, when we call this Feature Schematic it will call the Behavior Schematics.

Well done!

This example is for you to think you can use schematics to create things for you. I did thought this when I realized how powerful is this and how much it could help me in other past projects.

Thoughts about monorepos and code-sharing

Felipe Norato Lacerda — Sun, 15 Sep 2019 14:41:07 +0000

Some weeks ago I went to a conference and I could hear more about monorepos and it makes my mind blows. The point that makes my mind blows was how to share code between applications in an easy way.

The problem

I worked on some projects that I really want to solve the code-sharing problems across frontend, libs, and microservices.

In a project, we had an Angular Web Application and many Node Microservices, each in different repositories. And it was close to impossible to share code between those applications since we did not have a private npm.

In other, we had to create an Angular Web application and an Electron desktop with Angular application both using an Angular Component Library. All in the same repository, and it as really difficult to manage, but, here we could share code.

For those projects, I think using monorepo could solve this kind of problems because we would have all applications in a single repository and we could painlessly share code.

But, the second project example we had a monorepo and it still causing pain to manage the projects. That was because we did not use a monorepo manager, we actually we did not know that it as a monorepo.

A possible solution

So, what really solves the complexity around managing multiples projects in a single repository is a monorepo manager. I have been trying nx by nwrl since that.

The NX has some commands to create, build, test and check the interdependencies between the applications and libs. It is really useful and it will keep all organized without multiple customs commands, as we need to make in the second project.

In this time studying and trying NX to manage monorepos I can list some pros and cons to use that for a javascript monorepo.

Pros

You don't need to download tons of node modules for each project. It will be reused by all libs and applications;
All code will be in the same place, so it is easy to navigate through the project;
You don't need to duplicate or publish some code in npm to share code through the application. It makes easy to refactor and improve code;
In a private project, you only need to allow access to a single repository;
Using a monorepo manager, like NX, you can use many commands from its CLI to automate the flow;
You will keep all working in the same branch;
It is easy to test everything together and check what artifact was affected by a change. You also can only test and build the affected artifact;
It is easy to create new applications. Is easy because we can use the CLI to create it and all provisioning and libs could be reused, it will save lots of time.

Cons

An untested change could break all project, in the same context that is easy to improve is easy to break everything;
You could not deny access to an application to a developer because you are keeping everything together in a single repository;
Is not so easy to create CI/CD to deploy a specific artifact. This is a point that I am still working to find a simple solution.

Considerations

I suggest to test it a new project to check if this alternative will fit your needs. It could prevent that effect POC to production! Some questions you could ask yourself to decide to move to a monorepo:

1 - Do you need to share code between projects?
2 - Do you have more applications using the same environment/language?
3 - Do you can allow all developers to access all source code?
5 - Do you think about to create new projects that need to reuse some existent code?
4 - And the most important, do you really think that could help you to deliver faster?

That questions I ask myself when I decided to try to use monorepo. I am working on a huge frontend application and we are going to create more projects. We started to think about speedup our delivery and reuse many features that we created in the other one. So this migration is motivated to anticipate to be productive when new projects arrive.

And you?
Do you already test monorepo? What is your experience on that?