DEV Community: Gaëtan Redin

Angular multi translation files

Gaëtan Redin — Fri, 23 Jun 2023 09:44:10 +0000

Done with ngx-translate

I’ve been using ngx-translate for as long as I can remember. I find it easier than the native Angular i18n solution.

Translations is often complicated to maintain because the translation file grows as the application grows.

My use cases:

I don’t want to have all my translations in one single file
I want to know where to write my translations
I want to keep a common file because there are still common wordings
Bonus, I want to make that more readable, reviewable

Project Architecture

This is how my assets are architectured to let the solution works. this can be done in an another way but I don’t variabilize the path to the common files (which can be done if you want to handle it).

- assets
  - ...
  - i18n
    - common
      - fr.json
      - en.json
      - ...
    - feature-1
      - fr.json
      - en.json
      - ...
    - feature-2
      - fr.json
      - en.json
      - ...
    - ...

Custom loader

here is the doc about how to create a custom loader.

Let’s read my suggestion for a custom loader:

// model for a resource to load
export type Resource = { prefix: string; suffix: string };


export class MultiTranslateHttpLoader implements TranslateLoader {
  resources: Resources[];
  withCommon: boolean;

  constructor(
    private readonly http: HttpClient,
    { resources, withCommon = true }: { resources: Resource[], withCommon?: boolean }
  ) {
    this.resources = resources;
    this.withCommon = withCommon;
  }

  getTranslation(lang: string): Observable<Record<string, unknown>> {
    let resources: Resource[] = [...this.resources];

    if (this.withCommon) {
      // order matters! like this, all translations from common can be overrode with features' translations
      resources = [
        { prefix: './assets/i18n/common/', suffix: '.json' }, 
        ...resources
      ];
    }

    return forkJoin(resources.map((config: Resource) => {
      return this.http.get<Record<string, unknown>>(`${config.prefix}${lang}${config.suffix}`);
    })).pipe(
      map((response: Record<string, unknown>[]) => 
        mergeObjectsRecursively(response)),
    );
  }
}

export const mergeObjectsRecursively = 
    (objects: Record<string, unknown>[]): Record<string, unknown> {
  const mergedObject: Record<string, unknown> = {};

  for (const obj of objects) {
    for (const key in obj) {
      if (Object.prototype.hasOwnProperty.call(obj, key)) {
        if (typeof obj[key] === 'object' && obj[key] !== null) {
          mergedObject[key] = mergeObjectsRecursively([mergedObject[key], obj[key]]);
        } else {
          mergedObject[key] = obj[key];
        }
      }
    }
  }

  return mergedObject;
}

How to use it

With common translations:

TranslateModule.(forRoot|forChild)({
  loader: {
    provide: TranslateLoader,
    useFactory: (http: HttpClient): MultiTranslateHttpLoader => {
      return new MultiTranslateLoader(http, {
        resources: [
          { prefix: './assets/i18n/feature-1/', suffix: '.json' },
          { prefix: './assets/i18n/feature-2/', suffix: '.json' },
          ...
        ],
      });
    },
    deps: [HttpClient],
  },
})

Without common translations:

TranslateModule.(forRoot|forChild)({
  loader: {
    provide: TranslateLoader,
    useFactory: (http: HttpClient): MultiTranslateHttpLoader => {
      return new MultiTranslateLoader(http, {
        withCommon: false,
        resources: [
          { prefix: './assets/i18n/feature-1/', suffix: '.json' },
          { prefix: './assets/i18n/feature-2/', suffix: '.json' },
          ...
        ],
      });
    },
    deps: [HttpClient],
  },
})

Result

// assets/i18n/feature-1/en.json

{
  "HELLO": "HELLO",
  "CIVILITIES": {
    "MR": "Mister",
    "MS": "Miss"
  }
}

// assets/i18n/feature-2/en.json
{
  "TITLE": "LONG TITLE",
}

// generated translations
{
  "HELLO": "HELLO",
  "CIVILITIES": {
    "MR": "Mister",
    "MS": "Miss"
  },
  "TITLE": "LONG TITLE",
}

Conclusion

Now you can split your translation files, you will see how it will be easier to read, maintain and review. Don’t forget to use the lazy loading feature (from Angular) and then you will load only translation files required for a specific route.

If you need more details or want to give me your opinion let me a comment, don’t hezitate.

Thanks for reading.

From Angular 14 to Angular 16

Gaëtan Redin — Wed, 24 May 2023 16:27:36 +0000

What I have changed in my coding approach

From v14, The Angular team has certainly been busy. I work with Angular from the beginning of Angular 2. And I have never seen so many features in such a short amount of time.

My last article was edited 7 months ago and it’s time to share with you how I have changed my daily coding approach since v14.

In some cases, it will be a before / after comparison with the feature to show you quickly the benefits. It will allow you to understand how to update your code with examples.

Angular v14

Standalone components

Before

// my.component.ts
@Component({
  ...
})
export class MyComponent {}

// my.module.ts
@NgModule({
  declarations: [MyComponent],
  exports: [MyComponent],
  imports: [AnotherStuff]
})
export class MyModule {}

Now

// my.component.ts
@Component({
  standalone: true,
  imports: [AnotherStuff]
  ...
})
export class MyComponent {}

Advantage

One less file to maintain and less code. Be careful, the standalone component must be imported .

this can also be applied to the AppComponent, you “just” have to te rewrite your main.ts as follow:

bootstrapApplication(AppComponent, {
  ...
  importProvidersFrom(/* the imported modules in the app.module file*/),
  ...
});

Now there are many features you can provide without module, think to read the docs.

Typed Angular Forms

So highly anticipated and at the same time, somewhat disappointing for me.

Before ,

we only worked with an any type for all of our forms. It was a nightmare to maintain and to evolve.

const form: FormGroup = new FormGroup({
  lastName: new FormControl(''),
  firstName: new FormControl(''),
});

form.setValue({ ... }); // no type check
form.controls.(...); // no autocompletion
form.controls.firstName.setValue(0); // no type check every thing is ok...

Now ,

all of these points are resolved but there is still a problem. I find the syntax a bit indigest.

type FormType = { lastName: FormControl<string>; firstName: FormControl<string> };

const form: FormGroup<FormType> = new FormGroup<FormType>({
  lastName: new FormControl(''),
  firstName: new FormControl(''),
});

So why I find it indigest? Because our data models are not defined with Form[Control|Group|Array] types. it’s more like:

export interface Data {
  lastName: string; // no FormControl
  firstName: string; // no FormControl
}

So how to use the Data model with our FormGroup? Until now, no native solution, we have to use som hack.

I choose to use an intermediate type:

export type FormTyped<T> = {
  [Key in keyof T]: FormControl<T[Key]>;
};

It does not handle sub FormGroup or FormArray but in most of my cases it does the work. If you have any suggestion to improve this, don’t hezitate let me a comment.

Advantage

Type checking, autocompletion.

If you want / need to stay like in the old way you can use the UntypedForm[Control|Group|Array|Builder].

Bind to protected component members

Before ,

only public properties could be accessible from the HTML template. It has often been a bit frustrating for me to make some properties public just because of the template.

@Component({
  template: `{{ myProperty }}`
})
class Component {
  public myProperty?: string;
}

Now ,

we can really choose what to publicly expose from our component:

@Component({
  template: `{{ myProperty }}`
})
class Component {
  protected myProperty?: string;
}

Angular v15

RouterTestingHarness

Since RouterTestingHarness has come, I find it easier to test routing, check guards calls and co.

@Component({standalone: true, template: 'hello {{name}}'})
class TestCmp {
  name = 'world';
}

it('navigates to routed component', async () => {
  TestBed.configureTestingModule({
    providers: [provideRouter([{path: '', component: TestCmp}])],
  });

  const harness = await RouterTestingHarness.create();
  const activatedComponent = await harness.navigateByUrl('/', TestCmp);
  expect(activatedComponent).toBeInstanceOf(TestCmp);
});

Advantage

I use a specific routes.spec.ts file for only testing routing. It makes tests more readable.

Before, I often have seen projects without routing tests. Now, there is no excuse.

Simplify routes files and use Router API

I don’t want to rewrite an app-routing.module.ts… I know you know what I mean. But here how to do now, bonus it’s a lazy load example.

// app.routes.ts
export const appRoutes: Routes = [{
  path: 'lazy',
  loadChildren: () => import('./lazy/lazy.routes')
    .then(routes => routes.lazyRoutes)
}];

// lazy.routes.ts
import {Routes} from '@angular/router';

import {LazyComponent} from './lazy.component';

export const lazyRoutes: Routes = [{path: '', component: LazyComponent}];

// main.tous
bootstrapApplication(AppComponent, {
  providers: [
    provideRouter(appRoutes)
  ]
});

Directive composition API

I have written two articles about it:

Functional router guards

Before ,

we have to define our guard in a specific file like below:

@Injectable({
  providedIn: 'root'
})
export class AuthGuard implements CanActivate {
  constructor(private authService: AuthService, private router: Router){};
  canActivate(...): boolean | UrlTree {
    let isLoggedIn = this.authService.isAuthenticated();

    if (isLoggedIn) return true

    return this.router.createUrlTree(['/contact']);
  }

Now ,

you simply can do it in your routes file:

export const routes = [{
...
  canActivate: [
    (): boolean | UrlTree => {
      const authService = inject(AuthService);

      if (authService.isAuthenticated()) return true;

      return inject(Router).createUrlTree(['/contact']);
    },
  ],
}];

Or you can extract it into a plain function, it depends on your needs:

function isAuthenticated(): boolean | UrlTree {
  const authService = inject(AuthService);

  if (authService.isAuthenticated()) return true;

  return inject(Router).createUrlTree(['/contact']);
};

export const routes = [{
...
  canActivate: [isAuthenticated],
}];

Advantage

More readable, less code. Just what we love.

Self-closing tags

It allows to streamline the HTML code.

<!-- before -->
<app-my-component></app-my-component>

<!-- now -->
<app-my-component/>

Angular v16

Required inputs

How to handle required inputs before Angular v16? You will find the answer in one of my previous article:

How to Handle Required Inputs in Angular

Since v16, no hack is needed, even custom decorators are deprecated, you just have to do this:

@Component({ ... })
class MyComponent {
  @Input({ required: true }) myProp!: string;
}

Passing router data as component inputs

I think this is one of my favourite feature. Why? Because we don’t need to have the ActivatedRoute dependency in our component, we don’t need to handle static or resolved route data, path parameters, matrix parameters, and query parameters no more.

Before

private readonly activatedRoute = inject(ActivatedRoute);

private hero$: Observable<Hero> = this.activatedRoute.queryParams.pipe(
  switchMap(({ heroId }: Params) => this.service.getHero(heroId)),
);

Now

In your component you just have to define the prop with the @Input decorator:

@Input()
set id(heroId: string) {
  this.hero$ = this.service.getHero(heroId);
}

Don’t forget to add this in your routing config:

providers: [
  provideRouter(appRoutes, withComponentInputBinding()),
]

Advantage

Your component is more generic and can be used in all cases.

Conclusion

I don’t talk about signal here. It’s a great feature but for me it will be very interesting from the v16.1 and the add of the transform feature for Inputs.

As we can see, many features to make Angular easier, more accessible and more readable. But yes, I’m like you I’m waiting for all the signals feature. It seems we have to wait until the v17.

If you need more details about a feature let me a comment, don’t hezitate.

Thanks for reading.

Angular testing

Gaëtan Redin — Wed, 01 Mar 2023 10:30:49 +0000

How to mock natively component dependencies

Hey, I know there are many documentation about this but it seems to not be effective. Why? People does not read documentation… Every time I start a new mission, the developers don’t test their components or do it wrong. In the last case, they never mock their component dependencies and that’s a problem because it’s not a unit test anymore.

I think a little reminder is necessary.

Context

I’m developing a CancelButtonComponent. It’s a material button with a specific text and specific mat-button properties.

I’m working on a standalone component.

I’m using jest and snapshot testing to be sure that the genereted HTML is as expected.

How to

@Component({
  selector: 'app-cancel-button',
  standalone: true,
  template: `<button mat-button color="primary">Cancel</button>`,
  imports: [MatButtonModule]
})
export class CancelButton {}

It’s a really simple component and here we just have to control the generated HTML.

Here’s the spec file:

describe('CancelButtonComponent', () => {
  let component: CancelButtonComponent;
  let fixture: ComponentFixture<CancelButtonComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [CancelButtonComponent],
    }).compileComponents();

    fixture = TestBed.createComponent(CancelButtonComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should create', () => {
    expect(fixture.nativeElement).toMatchSnapshot();
  });
});

Here I don’t mock anything.

That’s the generated snapshot:

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`CancelButtonComponent should create 1`] = `
<div
  id="root0"
>
  <button
    class="mdc-button mat-mdc-button mat-primary mat-mdc-button-base"
    color="primary"
    mat-button=""
  >
    <span
      class="mat-mdc-button-persistent-ripple mdc-button__ripple"
    />
    <span
      class="mdc-button__label"
    >
      Cancel
    </span>
    <span
      class="mat-mdc-focus-indicator"
    />
    <span
      class="mat-ripple mat-mdc-button-ripple"
      matripple=""
    />
    <span
      class="mat-mdc-button-touch-target"
    />
  </button>
</div>
`;

I don’t think this snapshot is really relevant. I don’t care about MatButton specific css classes, I don’t care about all generated spans and that make a big snapshot just for one line of HTML to test. Snapshot is a part of your code it MUST be reviewed.

Now, let’s do better with a mock.

Here’s a simple mock for the MatButton:

@Component({
  selector: '[mat-button]',
  standalone: true,
  template: ` <ng-content></ng-content>`,
})
class MatButtonMock {}

I use the projection () to let the button’s text appear in the snapshot.

And that’s how to use it in the test:

beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [CancelButtonComponent],
    })
      .overrideComponent(CancelButtonComponent, {
        remove: {
          imports: [MatButtonModule],
        },
        add: {
          imports: [MatButtonMock],
        },
      })
      .compileComponents();

    ...
  });

We just tell to TestBed to remove the import of MatButtonModule for CancelButtonComponent and to replace it with our MatButtonMock.

Let’s see the snapshot now:

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`CancelButtonComponent should create 1`] = `
<div
  id="root0"
>
  <button
    color="primary"
    mat-button=""
  >
    Cancel
  </button>
</div>
`;

It’s so better. I see only the specifities of my CancelButtonComponent:

usage of a mat-button
set the color to primary
set the text to “Cancel”

It’s more readable, it’s more reviewable and it’s more relevant.

Angular offers other methods to override a component in a test:

overrideComponent
overridePipe
overrideDirective
overrideModule
overrideProviders

I put here the full spec file if you need it:

describe('CancelButtonComponent', () => {
  let component: CancelButtonComponent;
  let fixture: ComponentFixture<CancelButtonComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [CancelButtonComponent],
    })
      .overrideComponent(CancelButtonComponent, {
        remove: {
          imports: [MatButtonModule],
        },
        add: {
          imports: [MatButtonMock],
        },
      })
      .compileComponents();

    fixture = TestBed.createComponent(CancelButtonComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should create', () => {
    expect(fixture.nativeElement).toMatchSnapshot();
  });
});

Conclusion

Never mind, you are using jest, Karma/jasmine or another testing tool. You always must mock your dependencies (components, services, pipes…) to avoid to be impacted by a third party in your test. And also because we are speaking about unit test.

If you need more examples or other testing use case, let me know in comment. I will try to help you.

Thanks for reading.

Learn more

Angular 15: hostDirectives + InjectionToken

Gaëtan Redin — Sun, 27 Nov 2022 16:54:36 +0000

How to avoid duplications and override directive’s inputs value with injection token

Hey, as you know, Angular 15 has been come with a new great feature: hostDirectives.

Since Angular 15 release, I have made some refacto in my angular project and I found this use case: I extend a directive which have an input to handle css classes. In the subsclass, I override the input property and set it a default value. I wanted to remove the extends and find a way to use only the new concept of hostDirectives. And Actually, I found a way which result of the combination of hostDirectives and injection token.

Let’s go for the demo.

Here is a directive which is used to be extended to add some css classes :

@Directive({
  selector: '[typography]',
  standalone: true,
  host: {
    '[class.headline-1]': 'typography === "headline-1"',
    ...
    '[class.headline-6]': 'typography === "headline-6"',
    '[class.subtitle-1]': 'typography === "subtitle-1"',
    '[class.subtitle-2]': 'typography === "subtitle-2"',
    '[class.body-1]': 'typography === "body-1"',
    '[class.body-2]': 'typography === "body-2"',
    '[class.button-typo]': 'typography === "button"',
    '[class.caption]': 'typography === "caption"',
  },
})
export class TypographyDirective {
  @Input('rcTypography') public typography!:
    | 'headline-1'
    | 'headline-2'
    | 'headline-3'
    | 'headline-4'
    | 'headline-5'
    | 'headline-6'
    | 'subtitle-1'
    | 'subtitle-2'
    | 'body-1'
    | 'body-2'
    | 'button'
    | 'caption';
}

And this is how it was used before:

@Component({
  selector: 'my-selector',
  standalone: true,
  template: `...`,
})
export class SubClassComponent extends TypographyDirective {
  public override readonly typography = 'body-2';
}

Why? because I wanted to use the advantage of the directive directly on my component and to not rewrite the css classes handling.

It’s ok, it works, it’s readable.

But what if I need to extend a more functionnal class? I have to use mixins ? yes ok I know it’s possible too. But it needs to write more code each time.

A simple way will be to use the combination of hostDirectives metadata and an injection token.

Let’s do it.

// the injection token
export const TYPOGRAPHY_TOKEN: InjectionToken<TypographyDirective['typography']> = new InjectionToken<
  TypographyDirective['typography']
>('TYPOGRAPHY_TOKEN');

// the updated base directive
@Directive({
  selector: '[typography]',
  standalone: true,
  host: {
    '[class.headline-1]': 'typography === "headline-1"',
    ...
    '[class.headline-6]': 'typography === "headline-6"',
    '[class.subtitle-1]': 'typography === "subtitle-1"',
    '[class.subtitle-2]': 'typography === "subtitle-2"',
    '[class.body-1]': 'typography === "body-1"',
    '[class.body-2]': 'typography === "body-2"',
    '[class.button-typo]': 'typography === "button"',
    '[class.caption]': 'typography === "caption"',
  },
})
export class TypographyDirective {
  @Input('rcTypography') public typography:
    | 'headline-1'
    | 'headline-2'
    | 'headline-3'
    | 'headline-4'
    | 'headline-5'
    | 'headline-6'
    | 'subtitle-1'
    | 'subtitle-2'
    | 'body-1'
    | 'body-2'
    | 'button'
    | 'caption' 
    | null = inject(TYPOGRAPHY_TOKEN, { optional: true });
}

The property will be valued by the Input value of by the token value by default. Here’s the updated subclass:

@Component({
  selector: 'my-selector',
  standalone: true,
  template: `...`,
   hostDirectives: [
    {
      directive: TypographyDirective,
    },
  ],
  providers: [
    {
      provide: TYPOGRAPHY_TOKEN,
      useValue: 'body-2',
    },
  ],
})
export class SubClassComponent {
}

Et voila! My subclass is free to extend another class, the final code is still readable, it’s perfect. Hmm, wait, what if I want to allow to override the typography property with an input ?

Okay, you just have to indicate the input property like this:

@Component({
  selector: 'my-selector',
  standalone: true,
  template: `...`,
   hostDirectives: [
    {
      directive: TypographyDirective,
      inputs: ['typography']
    },
  ],
  providers: [
    {
      provide: TYPOGRAPHY_TOKEN,
      useValue: 'body-2',
    },
  ],
})
export class SubClassComponent {
}

and call it like this:

<my-selector ... [typography]="'subtitle-2'"></my-selector>

Even if the injection token is valued, the input value will have the final word.

I hope this will help someone to simplify his code et to write more readable code.

Thanks for reading.

Angular 15: hostDirectives

Gaëtan Redin — Thu, 24 Nov 2022 10:41:15 +0000

How to avoid duplications and to keep access to properties

Hey, as you know, Angular 15 has been come with a new great feature: hostDirectives.

There are already many articles about it but I never read something about how to keep access to the directives properties yet. I will focus on an explicit example that will all know: disabled state.

Let’s start with an example:

@Component({
  selector: '...',
  host: {
    ...
    '[class.my-disabled-class]': 'disabled',
    '[attr.disabled]': 'disabled || null',
    '[attr.aria-disabled]': 'disabled || null',
    ...
  },
  template: `...`
})
class MyComponent {
  @Input() public disabled = false;

  // many other stuffs
}

This little piece of code is often duplicated. Sometimes, people use mixins to be DRY but you still have to repeat the host part.

So how to do better?

First, we will create the DisabledState directive like as follow:

@Directive({
  selector: '[myDisabledState]',
  standalone: true, // available since Angular 14
  host: {
    '[attr.disabled]': 'disabled || null',
    '[attr.aria-disabled]': 'disabled || null',
    '[class.rc-disabled]': 'disabled',
  },
})
export class DisabledStateDirective {
  @Input() public disabled = false;
}

And now, we can simplify our component like this:

@Component({
  selector: '...',
  host: {
    ...
  },
  hostDirectives: [{
    directive: DisabledStateDirective,
    inputs: ['disabled'],
  }],
  template: `...`
})
class MyComponent {
  // many other stuffs
}

More readable right? And also, better separation of concerns. One point, I loose the access to the disabled property. How to know in my component if it’s disabled or not? Thanks to the great Angular, it’s really easy to do it:

@Component({
  selector: '...',
  host: {
    ...
  },
  hostDirectives: [{
    directive: DisabledStateDirective,
    inputs: ['disabled'],
  }],
  template: `...`
})
class MyComponent {
  private readonly _disabledState: DisabledStateDirective = inject(DisabledStateDirective, { self: true });

  public myFunction(): void {
    if (this.disabledState.disabled) {
      ...
    }
  }
}

We can just use the inject method to get the DisabledStateDirective , we use the self: true to simplify the search to it.

Et voilà (I’m still french sorry).

I hope this little example will help someone to simplify his code et to write more readable code.

Thanks for reading.

Development and Mikado

Gaëtan Redin — Sun, 31 Jul 2022 14:18:09 +0000

When I chose the Mikado method

Image par Willi Heidelbach de Pixabay

Context

During a front-end project in a client (in Angular), we got new directives for our project. One consequence of this was to migrate a lot of components into libraries.

My first reaction was “oh my god, it will take a loooooooong time”.

My second reaction was “Ok let’s go but how to do that without breaking the applications”

My third reaction was “How to do that without disturbing too much all the team”.

After some researches, I found an article about the Mikado method and it was the perfect solution for my situation.

Mikado method

Proposed by Ola Ellnestam and Daniel Brolund in 2012, this method allows to:

visualize the goal of our modification and the steps to reach it
lead our modification with little steps which always produce little green commit that can be merged and delivered.
keep a clean commit’s history

This is a generic representation of a Mikado diagram:

Mikado diagram

Implementation for my use case

So it’s time to start the migration but from where to start? Well a good first step would be to initialize the target library if it does’nt exist. No impact, quick review from the team that’s perfect.

Now, you have to choose one component to migrate into this library.

Our Mikado diagram looks like this:

Step 1

You start to move it inside the library. But wait this component depends on a model:

Step 2

Let’s revert all of our modifications. Why? Well the method recommends to revert the modification to still be in a stable compilation context. Remember one objective of the method is to only produce green commit (all tests passed, no compilation errors…).

Now move the model in the appropriate library. Once it’s done, your code is compiling, all tests and lint passed. You can opened a merge request and merge this modification. It will be fast to review it, the impact on the team development will be probably minimal. That’s perfect.

Let’s go back to the migration of our ContactFormComponent. You move the code and… This component depends on 3 other components:

Step 3

Let’s revert all of our modifications (again). Let’s focus on the first one MobilePhoneField.

Move it. But wait this one depends on a validator which is also a dependency of HomePhoneField.

Step 4

Let’s revert all of our modifications (again and again). Move the validator and open a merge request then merge it. Now ou diagram is like this:

Step 4 bis

Move the MobilePhoneField and only it even if the HomePhoneField has no other dependency. Keep your commit small. Open a merge request then merge it:

Step 5

Keep this logic until the end, one step, one commit, one merge request.

Step 6

Step 7

Step 8

Step 9

Et voilà, you have done with this ContactFormComponent.

Conclusion

This method can be a bit frustrating because of the lot of revert we can do. But keep in mind a good developer is lazy but not too much. The quality must never be neglected. Thanks to this method, your client will thank you to break nothing, your teamates will also thank you to not be a bulldozer which push large commit that can break their developments. More a commit is large, more it takes time to review, more you can get conflicts and more your risk to keep an instable merge request.

This method is really perfect for handling code legacy, refactoring and migration. It’s unappropriate tobug fix.

thanks for reading.

Learn more

Nx + Pnpm + Netlify

Gaëtan Redin — Sat, 30 Jul 2022 17:02:35 +0000

How to deploy an application from a mono repo

Context

Hey, you know when you want to develop an app or a website, there is a time to deploy it.

For several months, I only work with Nx workspace. No need, to explain here all the benefits Nx can bring you but I invit you to visit the web site. In short, it allows you to handle several apps and libs inside the same workspace. You can develop Angular, React and Node projects still in the same workspace.

Last week, I decided to use pnpm instead of npm. I find it so faster. There is no word to define the pleasure to make an install with it.

Today, I want to deploy one of my application thanks to Netlify. I heard good things about it.

But, netlify does not work natively with pnpm and there some tricks to know for mono repos. I will try to help you to do this. To accomplish this, I suppose you already have a mono repo with an app to deploy and you have create an account on netlify.

The steps

I guess, you have an architecture as following:

- apps
    - my-first-app
    - my-second-app
    - ...
- libs

Now, I suppose you want to deploy my-first-app.

First, you need to add a script into your package.

// package.json
"scripts": {
    "build:my-first-app": "nx build my-first-app --outputPath=apps/my-first-app/dist",
}

This will corresponds to the standard dist folder for netlify. This needs to be merged on your main branch (or the branch you decide to deploy).

So go to netlify web site and go to the deploy tab link:

Go to deploy settings:

Go to Build settings and click on Edit settings:

Fill with the information like below:

Put this in the Build command field:

pnpm run build:my-first-app || ( npm install pnpm && pnpm run build:my-first-app )

Click on save. Et voilà (I’m french I can say that too). Trigger a new deploy and it will be ok.

I hope this could help someone.

Thanks for reading.

Learn more

Test your Storybook

Gaëtan Redin — Sat, 12 Feb 2022 13:52:26 +0000

Storybook for Angular

Context

Nx 13 — Angular 13 — Storybook 6.5.0-alpha.36

Why?

More your application grows more you risk to introduce bugs. In a recent project, we have to kind of tests: Unit tests (so many) and some integration tests. We work incrementally and add features during sprints and rework older ones with more functional rules. Even if we test all devs with unit test, there is a moment that you realize you couldn’t test everything with unit testing.

We have develop a Storybook which contains all our components / directives. Sometimes, we check some of it during a development and Ho surprise, it’s broken :-(. Yet All our unit tests are okay…

How?

I was looking for a solution to introduce easily some functional tests without testing the interactions with the backend. Our goal was only to test functionally our HMI.

I already heard talking about Cypress and after doing some research I found a perfect solution for us. Nx offer the possibility to include an e2e application with Cypress configuration for testing our Storybook (Miracle).

I install all the requirements and start to write some functional tests. What a surprise, some tests failed whereas all our unit tests and integration tests works… As a lead dev, it was first a deception, because it means I didn’t guarantee the quality of our application. But, on second thought, what a joy to see I can still learn and discover new things! I’m sure many of us have already be in this situation. So let’s quit chatting, this is how to do it.

Installation

I suppose you already have a Nx — Angular project with Storybook. Here we just talk about Cypress installation for Storybook.

nx generate [@nrwl/storybook](http://twitter.com/nrwl/storybook):cypress-project --name={your_app_name} --linter=eslint --no-interactive

My app is called “storybook” and that’s the result of the command:

nx generate [@nrwl/storybook](http://twitter.com/nrwl/storybook):cypress-project --name=storybook --linter=eslint --no-interactive
UPDATE package.json
CREATE apps/storybook-e2e/cypress.json             
CREATE apps/storybook-e2e/src/fixtures/example.json
CREATE apps/storybook-e2e/src/support/commands.ts  
CREATE apps/storybook-e2e/src/support/index.ts     
CREATE apps/storybook-e2e/tsconfig.json            
CREATE apps/storybook-e2e/project.json             
UPDATE workspace.json                              
CREATE apps/storybook-e2e/.eslintrc.json           
UPDATE nx.json

In the package.json , we can see two more dev dependencies: @nrwl/cypress and cypress , logic.

In the storybook-e2e/tsconfig.json , we have this:

{
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "sourceMap": _false_,
    "outDir": "../../dist/out-tsc",
    "allowJs": _true_,
    "types": ["cypress", "node"]
  },
  "include": ["src/ **/*.ts", "src/** /*.js"]
}

Nothing special, except the type “cypress”.

Now let’s have a look into the storybook-e2e/project.json file:

{
  "root": "apps/storybook-e2e",
  "sourceRoot": "apps/storybook-e2e/src",
  "projectType": "application",
  "targets": {
    "e2e": {
      "executor": "@nrwl/cypress:cypress",
      "options": {
        "cypressConfig": "apps/storybook-e2e/cypress.json",
        "devServerTarget": "storybook:storybook"
      },
      "configurations": {
        "ci": {
          "devServerTarget": "storybook:storybook:ci"
        }
      }
    },
    "lint": {
      "executor": "@nrwl/linter:eslint",
      "outputs": ["{options.outputFile}"],
      "options": {
        "lintFilePatterns": ["apps/storybook-e2e/**/*.{js,ts}"]
      }
    }
  },
  "tags": [],
  "implicitDependencies": ["storybook"]
}

As we can see, the target server is defined with our storybook app "devServerTarget":"storybook:storybook:ci" which is launch in ci mode. So there is an implicit dependency with our Storybook app "implicitDependencies": ["storybook"] .

You already can to try it:

nx e2e {your_app_name}-e2e

It will failed with something like:

Can't run because no spec files were found.

We searched for any files inside of this folder:

...\apps\storybook-e2e\src\integration

Yes, we don’t have write tests yet. If you don’t know how to write cypress tests, you can read the documentation here which is perfect.

This commands is perfect for the testing in terminal. But some of us prefer to see it in a real window. To open cypress and execute the tests on demand, I suggest you to create another cypress.json like this:

// cypress.local.json
{
  "fileServerFolder": ".",
  "fixturesFolder": "apps/storybook-e2e/src/fixtures",
  "integrationFolder": "apps/storybook-e2e/src/integration",
  "modifyObstructiveCode": _false_,
  "supportFile": "apps/storybook-e2e/src/support/index.ts",
  "pluginsFile": _false_,
  "video": _true_,
  "videosFolder": "../../dist/cypress/apps/storybook-e2e/videos",
  "screenshotsFolder": "../../dist/cypress/apps/storybook-e2e/screenshots",
  "chromeWebSecurity": _false_,
  "baseUrl": "http://localhost:4400" // set the url of your local Storybook
}

Add this command into your package.json :

"test:storybook:local": "cypress open --browser ~\\chrome-win\\chrome.exe -C apps/storybook-e2e/cypress.local.json"

Here I use chromium as browser and I specify my local cypress config.

Now you can launch your local storybook and your local cypress:

nx run storybook:storybook
npm run test:storybook:local

It will fail until you will have write some tests.

To help writing test for Storybook, I suggest you to install the following library:

npm i -D cypress-storybook

Then import the helper commands into the support index file:

// apps/storybook-e2e/src/support/index.ts
import 'cypress-storybook/cypress'

Then import that in the storybook preview file, it help storybook to understand the cypress commands:

// apps/storybook/.storybook/preview.js
import 'cypress-storybook/angular'

At last, in your test file what you have to do:

describe('MyComponent', () => {
    beforeEach(() => {
      cy.visitStorybook();
      cy.loadStory('title-of-my-story', 'MyStoryName');
    });

    it('my test', () => {
    ...
    });
});

In the documentation, it’s recommended to wrap the cy.visitStorybook(); in a before and not a beforeEach but when I tried, it does not reset the Story in form cases between each test.

Conclusion

Now you will be more armed to defeat bugs! No excuse, particularly if you use Nx which helps a lot for the configuration. I suggest you to write some commands to simplify writing tests like a fillForm command which get a fixture and a form tag for example. It will make your test more readable.

Thanks for reading.

Learn more

Story for an Angular Directive V2

Gaëtan Redin — Sat, 12 Feb 2022 12:33:20 +0000

Storybook and Angular

Now, I have a bit more experience about making stories for Angular. I would like to share with you how I write a story for an Angular directive. I have already written an article when I started with storybook. I will make here some adjustments.

Context: Angular 13, StoryBook 6.5.0-alpha.36

First draft

I presume you already have installed storybook, if you don’t just go here.

Let’s use this button directive:

// button.directive.ts
@Directive({
  selector: 'button[groButton]',  
host: {
    _class_: 'gro-button',
    '[class.gro-small]': 'size === "small"',
    '[class.gro-medium]': 'size === "medium"',
    '[class.gro-large]': 'size === "large"',
    '[class.gro-outlined]': 'outlined',
    '[class.gro-primary]': 'color === "primary"',
    '[class.gro-accent]': 'color === "accent"',
    '[class.gro-warn]': 'color === "warn"',
  },
})
_export class_ ButtonDirective {
  @Input()
  _public_ size: 'small' | 'medium' | 'large' = 'medium';

  @Input()
  @CoerceBoolean()
  _public_ outlined?: _boolean_;

  @Input()
  _public_ color: 'primary' | 'accent' | 'warn' = 'primary';
}

I know there is a debate about using a directive or a component for button element. But that’s not the point here :-)

Now, this is the minimal story example for it:

// button.stories.ts
_import_ { _Meta_, _Story_ } _from_ '@storybook/angular';
_import_ { ButtonDirective } _from_ './button.directive';

_export default_ {
  title: 'atoms/button',
  component: ButtonDirective,
} _as Meta_<ButtonDirective>;

_const_ template: _Story_<ButtonDirective> = (args: ButtonDirective) => ({
  props: {
    size: args.size,
    outlined: args.outlined,
    color: args.color,
  },
  template: `<button groButton [size]="size" [outlined]="outlined" [color]="color">Click</button>`,
});

_export const_ Default = template.bind({});

With this stories you could test all cases for the button directive.

I suggest you to have a look on the “props” properties for the template. Personally, I use the addon-docs which works with compodoc. It allows to extract the documentation in the “Docs” tab. When you use it, if you set the “props” properties like this:

props: {
  ...args
}

You will get some troubles. In fact, all properties of your directive/component will be overrode, not only the @Input properties. This can lead to some unexpected behaviors. So, you should prefer to only specify the properties you want to set.

That’s what you get with this story:

Final Story

Now, let’s improve this story with some special addons offered by storybook.

addon-controls

Thanks to this addon, we can play with our components/directives from a graphical UI.

// .storybook/main.js
module.exports = {
  stories: [],
  addons: [
    '@storybook/addon-docs',
    '@storybook/addon-essentials', // check this line
  ],
  core: {
    builder: 'webpack5',
  },
  webpackFinal: (config) => {
    _return_ config;
  },
};

Have a look on the argTypes property:

// button.stories.ts
_export default_ {
  title: 'atoms/button',
  component: ButtonDirective,  
argTypes: {
    color: { // directive input name
      control: { type: 'inline-radio' },
    },
    size: { // directive input name
      control: { type: 'inline-radio' },
    },
  },
} _as Meta_<ButtonDirective>;

Thanks to this, that’s what we get in our Storybook:

In all recent version of Storybook, this addon is a part of essentials and is installed by default.

If you want to get more information about it go here.

addon-jest

I use Jest to test my code. It’s sometime useful knowing what is tested without going in the code. For this, you have to install the addon-jest.

To install it:

(yarn|npm) (add|install) -D @storybook/addon-jest

Add the addon:

// .storybook/main.js
module.exports = {
  stories: [],
  addons: [
    '@storybook/addon-docs',
    '@storybook/addon-essentials',
    '@storybook/addon-jest', // check here
  ],
  core: {
    builder: 'webpack5',
  },
  webpackFinal: (config) => {
    _return_ config;
  },
};

In package.json file add the following:

// don't forget to add .jest-test-results.json to .gitignore
"scripts": {
  "test:generate-output": "jest --json --outputFile=.jest-test-results.json"
}

Add test at the global level of your Storybook:

// .storybook/preview.js

import { withTests } from '@storybook/addon-jest';

import results from '../.jest-test-results.json';

export const decorators = [
  withTests({
    results,
  }),
];

In your story:

_export default_ {
  title: 'atoms/button',
  component: ButtonDirective,
  parameters: {
    jest: ['button.directive.spec'], // check here
  },
  argTypes: {
    color: {
      control: { type: 'inline-radio' },
    },
    size: {
      control: { type: 'inline-radio' },
    },
  },
} _as Meta_<ButtonDirective>;

You will now can see this:

That’s the minimal setup I can suggest you. There are a lot of other addons that you can check here. All of them cannot be used for Angular but it’s always noticed.

Conclusion

Now you can have a nice Storybook, and more you can improve it with a lot of other addons. In a next chapter, I will show you how to test your Storybook. Why? Because Storybook is really powerful but when you add code into your applications/libraries you couldn’t know if you have broken something…

To be following…

Thanks for reading.

Learn More

Typescript decorator to handle Unsupported operations

Gaëtan Redin — Sun, 19 Dec 2021 12:39:38 +0000

Simplify your code

Context

Typescript: 4.3.5

In my Angular project, I have a generic class for CRUD services. This class defines all available api calls.

_type IdentifierType_ = _string_ | _number_;

@Injectable()
_export abstract class_ CrudService {
  _protected_ _url!: _string_;

  _protected constructor_(_protected readonly_ _httpClient: HttpClient) {}

  _public_ get<ReturnType>(
    identifier: _IdentifierType_  
): Observable<_Nullable_<ReturnType>> {
    ...
  }

  _public delete_(identifier: _IdentifierType_): Observable<_boolean_> {
    _..._
  }

  _public_ post<ReturnType, BodyType = _Partial_<ReturnType>>(
    body: BodyType
  ): Observable<_Nullable_<ReturnType>> {
    _..._
  }

  _public_ getAll<ReturnType>(
    filters?: _Record_<_string_, _string_ | _number_>
  ): Observable<_Nullable_<ReturnType[]>> {
    ...
  }

  _public_ put<BodyType>(body: BodyType): Observable<_boolean_> {
    ...
  }
}

This is usefull when you have the chance to work with a backend api which has the same behavior for all entities. But it’s not always the case…

Problems

Here’s some cases which corresponds to my project reality, probably you will find here some similarities with your own projects:

An entity cannot be created / deleted, data comes from a reference base or from a configuration base (list of localities, list of products which are not handle by your application…).
An entity cannot be updated / partially updated, you work in a system which needs to historize all
Or simplier, just because your backend api does not offer this possibilities yet. You work on a project from scratch and with iterations.

So how to avoid wasting time to debug or to understand in which case you are when something wrong happened ?

Solution

The first approach will probably be to throw an error in the sub classes’ methods like this:

@Injectable()
_export class Person_CrudService extends CrudService {
  _protected_ _url = '/persons';

  _public override delete_(identifier: _number_): Observable<_boolean_> {
    _throw new Error('Unsupported Operation');_
  }

  _public override_ post<Person>(body: Person): Observable<_Nullable_<Person>> {
    _throw new Error('Unsupported Operation');_
  }
}

Here we forbidden the access to delete and post operations. We need to rewrite the method’s definitions and to throw an error inside both. Now let’s imagine to do that for each entity… As I’m a bit Lazy and I don’t find it elegant, I chose another way: A typescript class decorator.

It simply takes the list of operations which must throw the expected error.

Type corresponds to the class and allows to get autocompletion when you type the operation name(s).

Here’s the corresponding example:

@Injectable()
_@UnsupportedOperations<Person_CrudService>('delete', 'post')  
_export class Person_ CrudService extends CrudService {
  _protected_ _url = '/persons';
}

As you can see, when you write this, you save time and some lines of code.

Conclusion

When something to do is boring, not elegant or take to much time then you should probably find a better way to do it. Maybe this solution will not please everyone but I and my team think that’s effective.

Thanks for reading, feel free to comment. See you

Learn More

Flutter: Rex d’une première Expérience

Gaëtan Redin — Sun, 05 Dec 2021 17:21:34 +0000

Pourquoi et comment?

Contexte

Je suis développeur web depuis quelques années maintenant et avec une grosse appétence front-end. Comme beaucoup, je suis très curieux et j’ai soif d’apprendre. L’ennui et la monotonie sont deux choses qui me terrifies.

Il y’a quelques temps, j’ai entendu parler de Flutter. Un nouveau framework développé par Google. Et là ma première réaction fut:

Pourquoi Google sort un autre framework, alors qu’on dispose déjà d’Angular?!

Bref, je me dis qu’il faut que je creuse le sujet. Je vais donc sur le site officiel et je commence à lire, à me documenter et à décortiquer toute la doc.

Je comprends donc que l’idée n’est pas de remplacer Angular mais de proposer un framework capable de répondre à une problématique :

Comment développer une application accessible quelque soit la plateforme (web, iOS, Android)?

Ni une ni deux ça me donne envie d’essayer tellement ça à l’air simple.

Projet

Durant le premier confinement, j’ai monté une équipe de collègues qui comme moi se sont retrouvés en inter-contrat. On avait développé une application web permettant de visualiser sur une map les clients de notre employeur ainsi que les collègues en mission.

Voici donc mon sujet de projet : essayer de faire une application mobile répondant à ce besoin.

Rex

Installation

Franchement, il suffit de suivre la doc et c’est très simple et très clair. Personnellement, j’utilise IntelliJ sous Windows et ça a été très rapide.

On télécharge le SDK ou on clone le repo git de flutter
Petite mise à jour du path Windows pour faire connaître les commandes spécifiques
Hum on n’oublie pas de redémarrer 😏
Android studio est facultatif si vous n’avez pas dans l’objectif de dev pour Android
IDE: personnellement, j’utilise IntelliJ et il suffit d’installer Deux plugins (Dart et Flutter)

Et voilà on est prêt à commencer 😁

Premier devs

Je crée mon nouveau projet via IntelliJ (Flutter Application). Je découvre un code démo assez basique. J’en profite pour comprendre un peu le fonctionnement, les imbrications de widgets et surtout la syntaxe.

Je commence par essayer de composer ma structure de page. Il m’en faut 4 en tout:

Une concernant les collaborateurs
Une concernant les clients
Une permettant de créer des missions (lien entre un collègue et un client)
Et enfin une pour la map

Je me rends compte que pour ne pas partir trop de travers il faut que je me documente un peu.

Je choisis donc de lire tous les cookbooks de la documentation Flutter. Ça a été un régal, tout à l’air simple et facile à mettre en place. J’ai rarement vu une doc aussi bien faite et complète.

Cependant, je me rend vite compte que je m’emballe un peu. Et oui comment je vais stocker mes données? Je n’ai pas forcément envie de mettre quelque chose de trop complexe en place. Très vite je trouve plein de solutions. Une retiens mon attention: localstore.

C’est compatible avec toutes les plateformes c’est simple à utiliser donc parfait je prends. Je peux donc créer mon petit modèle de données.

Mon petit côté pointilleux reviens à la charge. Hem et les tests unitaires? Ben oui en Angular tu fais du TDD donc là on fait quoi? Certes cette fois je n’avais pas envie de faire du TDD mais j’ai quand même mis en place des TUs. Encore une fois la doc est vraiment très bien faite.

Enfin un dernier point à aborder, qu’est ce qu’on utilise pour la map? Là y a beaucoup de choix, des solutions plus ou moins payantes. Je me suis tourné vers flutter_map. Une solution compatible avec toutes les plateformes et gratuite.

Après quelques semaines (oui je fais ça sur mon temps perso et je suis papa donc pas beaucoup de temps pour faire ça) je finis une V1 de mon appli et là quelle fierté 😁. C’est fonctionnel et sur mon iPhone ça s’utilise très bien.

Vous trouverez le repo git ici et vous pouvez jouer avec l’application ici.

Pour s’en servir en mode web app mobile, pour iOS il suffit d’ouvrir Safari, d’appuyer sur l’icône pour afficher les options de la page puis de cliquer sur « sur l’écran d’accueil ».

Conclusion

Ce fut une excellente expérience, je me vraiment amusé. Flutter est vraiment facile à prendre en main et simplifie beaucoup de comportements communs. Il fournit une sacré liste de widgets qui peut être enrichie avec d’autres librairies.

Quelques bémols:

J’ai été déconcerté par l’absence de «protected» on est soit en privé doit en public.
La syntaxe un peu trop flex à mon goût, je suis plutôt pro typescript très strict.

Je ne suis pas dupe, mon code n’est sûrement pas parfait et peut être amélioré. Mais mon but était de découvrir et ça le fait. C’est également pour ça que j’ai choisi GitHub pages pour déployer l’appli, simple, rapide et répond à mon besoin.

J’ai hâte en tout cas d’avoir une nouvelle idée de projet mobile que cette fois j’essayerai de pousser jusqu’au Store iOS. Affaire à suivre…

Un grand merci pour le temps passé à me lire. C’est la première fois que je fais un article en français. Je veux bien un retour là dessus en plus du reste 🙂

Story for a Component With Content Projection

Gaëtan Redin — Sun, 03 Oct 2021 12:08:46 +0000

Storybook and Angular components

Context : Angular 12, StoryBook 6.3.9

Hey, I started to use Storybook and I would Like to share my experience. Here’s the use case. I have a simple component which only use content projection:

@Component({
  selector: "adr-label",
  template: `<ng-content></ng-content>`,
})
_export class_ LabelComponent {}

Here’s the associated story:

_export default_ {
  title: "atoms/forms/label",
  component: LabelComponent,
  decorators: [**componentWrapperDecorator** (LabelComponent)],
} _as Meta_;

_const_ BasicTemplate: _Story_<LabelComponent> = (args) => ({
  moduleMetadata: { declarations: [InputDirective] },
  **template** : `<adr-label>{{ ngContent }}</adr-label>`,
  props: { ...args },
});

_export const_ Default = BasicTemplate.bind({});
Default.args = {
  **ngContent** : "Un label",
};

The specificity here is to use a componentWrapperDecorator. It allows to wrap our component and to pass it some extras like in my case a text content.

You just have to define a template like in BasicTemplate to emulate the content projection and using it like an input.

In the Default args, I add an ngContent arg to set the content of my label. I choose this name “ngContent” because it appears in the controls list and I find it consistent to let know that’s a content projection in this way.

You can see the result here:

Storybook

You can access to the full code here:

atomic-design/src/components/atoms/forms/label at master · GaetanRdn/atomic-design