2 years of angular: lessons learned

Dirk Luijk
@dirkluijk
#frontend
#angular
#fullstack

About Bingel
● Full lesson support
● Instruction, exercises & testing
● Maths & language courses
● Adaptive learning
● Modern & cross-platform

How it started…
ng new bingel-app$ ng new bingel-student-app

Architecture
student app
tasks module
lessons module
results module

Architecture
student app
tasks module
lessons module
results module
shared module

Architecture
student app
tasks module
lessons module
results module
shared module
teacher app

Architecture
student app
tasks module
lessons module
results module
shared module
teacher app
instruction module
analysis module
shared module

Architecture
student app
tasks module
lessons module
results module
shared module
teacher app
"shared code"
instruction module
analysis module
shared module

Architecture
student app
tasks module
lessons module
results module
shared module
teacher app
ui library
interactions
library
api library common library
instruction module
analysis module
shared module

Architecture
student app
tasks module
lessons module
results module
shared module
teacher app
@p1/ui @p1/interactions @p1/api @p1/common
preview app admin app
instruction module
analysis module
shared module
preview module licensing module
content graph module
@p1/features

Architecture
student app
tasks module
lessons module
results module
shared module
teacher app
@p1/ui @p1/interactions @p1/api @p1/common
preview app admin app
instruction module
analysis module
shared module
preview module licensing module
content graph module
@p1/features
single repository (monorepo)

Nx workspaces
● Builts on top of Angular CLI
● Supports monorepo approach
● Provides "affected builds" option:
○ build only what has been changed
● Better separation of packages

Architecture: lessons learned
1. Consider a monorepo
○ simple versioning & release process
○ easier refactoring
○ well supported by Angular CLI + Nx Workspaces
2. Think in packages and their responsibilities

Routing
[
{
path: 'overview',
loadChildren: 'overview/overview.module#OverviewModule'
},
{
path: 'lessons',
loadChildren: 'lessons/lessons.module#LessonsModule'
},
{
path: 'tasks',
loadChildren: 'tasks/tasks.module#TasksModule'
}
];

Routing guards
{
path: 'tasks',
resolve: {
blocks: BlocksResolver
},
children: [
{
path: '',
canActivate: [TasksRedirectGuard]
},
{
path: 'blocks',
component: TasksBlocksComponent
},
{
path: 'blocks/:blockId/weeks/:weekId',
component: TasksSelectionComponent
}
]
}

Routing in Angular is reactive.

Routing in Angular is reactive.
But not necessarily.

ActivatedRoute
class WeekComponent implements OnInit {
week: Week;
constructor(private route: ActivatedRoute, private weekService: WeekService) {}
ngOnInit(): void {
this.route.paramMap
.pipe(
map(params => params.get('weekId')),
switchMap(weekId => this.weekService.getWeek(weekId))
)
.subscribe(week => {
this.week = week;
});
}
}

ActivatedRoute
class WeekComponent implements OnInit {
week: Week;
ngOnInit(): void {
this.route.paramMap
.pipe(
map(params => params.get('weekId')),
switchMap(weekId => this.weekService.getWeek(weekId))
)
.subscribe(week => {
this.week = week;
});
}
}
reactive!

ActivatedRoute vs. ActivatedRouteSnapShot
class WeekComponent {
week: Week;
ngOnInit(): void {
this.weekService
.getWeek(this.route.snapshot.paramMap.get('weekId'))
.subscribe(week => this.week = week);
}
}

ActivatedRoute vs. ActivatedRouteSnapShot
class WeekComponent {
week: Week;
ngOnInit(): void {
this.weekService
.getWeek(this.route.snapshot.paramMap.get('weekId'))
.subscribe(week => this.week = week);
}
}
not reactive (static)!

Routing: lessons learned
1. Make use of lazy-loaded feature modules
○ Breaks down bundles into smaller chunks
2. Make smart use of guards!
3. Get used to the (reactive) API of Angular Router

Different types of components
Page Components
Routed, fetches data, (almost) no presentation logic1
Feature Components
Specific presentation logic (bound to domain model)2
UI Components
Generic presentation logic (not bound to domain model)3

TasksModule
TaskSelectionComponent
/tasks/blocks/week/:id
TaskDetailsComponent
/tasks/task/:id
LessonsModule
LessonsComponent
/lessons

TasksModule
/tasks/task/:id
SidebarModule
SidebarComponent
AccordionModule CardModule
AccordionComponent CardComponent
LessonsModule
LessonsComponent
/lessons

TasksModule
/tasks/task/:id
SidebarModule
SidebarComponent
AccordionModule CardModule
AccordionComponent CardComponent
TaskPreviewComponent
TaskMenuComponent
LessonsModule
LessonsComponent
/lessons

Only be generic when needed
Page components:
Try to be specific. Duplicate page variants, avoid pages that become fuzzy.
UI components:
Be generic. Don't couple to domain model.

Style encapsulation! 😍
Concept from Web Components
● A component has its own "shadow DOM"
● A component can only style its own elements
● Prevents "leaking" styling and unwanted side-effects
● No conventies like BEM, SMACSS, …, needed anymore

Example
@Component({
selector: 'p1-panel',
template: `
<header>...</header>
`,
styles: [`
header {
margin-bottom: 1em;
}
`]
})
class PanelComponent {}

Don't forget the :host element!

@Component({
template: `
<div class="wrapper">
<footer>...</footer>
</div>
`,
styles: [`
.wrapper {
display: flex;
}
`]
})

@Component({
template: `
<footer>...</footer>
`,
styles: [`
:host {
display: flex;
}
`]
})

Robust default styling
@Component({
template: `
<footer>...</footer>`,
styles: [`
:host {
/* ... */
}
`]
})

@Component({
selector: 'p1-some-page',
template: `
<p1-panel *ngFor="week of weeks"></p1-panel>
`,
styles: [`
p1-panel {
/* ... */
}
`]
})
class SomePageComponent {}
@Component({
template: `
styles: [`
:host {
/* ... */
}
`]
})

@Component({
selector: 'p1-some-page',
template: `
<p1-panel *ngFor="week of weeks"></p1-panel>
`,
styles: [`
p1-panel {
/* ... */
}
`]
})
class SomePageComponent {}
@Component({
template: `
styles: [`
:host {
/* ... */
}
`]
})
More
default styling!
Less
contextual styling!

Component styling vs. global styling 🤔
● Global styling
○ Try to avoid as much as possible!
● Component styling
○ Makes use of style encapsulation.

Awesome feature, :host-context()
@Component({
template: `
`,
styles: [`
header { margin-bottom: 1em; }
:host-context(p1-sidebar) header {
margin-bottom: 0;
}
`]
})
export class PanelComponent {}

Styling: lessons learned
1. Prefer component styling over global styling
2. Prevent using "cheats" like ::ng-deep. It's a smell! 💩
3. Don't forget the :host element!
4. Go for robust and flexible default styling
5. Make use of CSS inherit keyword
6. Use EM/REM instead of pixels

Unit testing
Angular provides the following tools out-of-the-box:
➔ Karma runner with Jasmine as test framework 🤔
➔ TestBed as test API for Angular Components 🤔

TestBed API
describe('ButtonComponent', () => {
let fixture: ComponentFixture<ButtonComponent>;
let instance: ButtonComponent;
let debugElement: DebugElement;
beforeEach(async(() => {
TestBed.configureTestingModule({
declarations: [ ButtonComponent ]
})
.compileComponents();
fixture = TestBed.createComponent(ButtonComponent);
instance = fixture.componentInstance;
debugElement = fixture.debugElement;
}));
it('should set the class name according to the [className] input', () => {
instance.className = 'danger';
fixture.detectChanges();
const button = debugElement.query(By.css('button')).nativeElement as HTMLButtonElement;
expect(button.classList.contains('danger')).toBeTruthy();
expect(button.classList.contains('success')).toBeFalsy();
});
});

TestBed API
let fixture: ComponentFixture<ButtonComponent>;
let instance: ButtonComponent;
let debugElement: DebugElement;
beforeEach(async(() => {
TestBed.configureTestingModule({
declarations: [ ButtonComponent ]
})
.compileComponents();
fixture = TestBed.createComponent(ButtonComponent);
instance = fixture.componentInstance;
debugElement = fixture.debugElement;
}));
instance.className = 'danger';
fixture.detectChanges();
const button = debugElement.query(By.css('button')).nativeElement as HTMLButtonElement;
expect(button.classList.contains('danger')).toBeTruthy();
expect(button.classList.contains('success')).toBeFalsy();
});
});
TL;DR 🤔

Hello @netbasal/spectator! 😎
AWESOME library for component testing in Angular
➔ Simple API
➔ Better typings
➔ Custom matchers
➔ Mocking integration
➔ Simple way of querying

Spectator API
const createComponent = createTestComponentFactory(ButtonComponent);
let spectator: Spectator<ButtonComponent>;
beforeEach(() => {
spectator = createComponent();
});
spectator.component.className = 'danger';
spectator.detectChanges();
expect('button').toHaveClass('danger');
expect('button').not.toHaveClass('success');
});
});

Go for readable test code!
it('should show the pressed key while pointing down', () => {
const keys = spectator.queryAll('.key');
const key1 = keys[0]; // q-key
const key2 = keys[1]; // w-key
spectator.dispatchMouseEvent(key1, 'pointerdown');
expect(key1.classList.contains('key-pressed')).toBe(true);
expect(key2.classList.contains('key-pressed')).toBe(false);
expect(spectator.component.activeKey).toBe('q');
spectator.dispatchMouseEvent(key1, 'pointerup');
expect(spectator.component.activeKey).toBeFalsy();
spectator.dispatchMouseEvent(key2, 'pointerdown');
expect(key2.classList.contains('key-pressed')).toBe(true);
expect(spectator.component.activeKey).toBe('w');
});

const keys = spectator.queryAll('.key');
const keyQ = keys[0];
const keyW = keys[1];
spectator.dispatchMouseEvent(keyQ, 'pointerdown');
expect(keyQ.classList.contains('key-pressed')).toBe(true);
expect(keyW.classList.contains('key-pressed')).toBe(false);
spectator.dispatchMouseEvent(keyQ, 'pointerup');
expect(keyQ.classList.contains('key-pressed')).toBe(false);
spectator.dispatchMouseEvent(keyW, 'pointerdown');
expect(keyW.classList.contains('key-pressed')).toBe(true);
});

const [keyQ, keyW] = spectator.queryAll('.key');
spectator.dispatchMouseEvent(keyQ, 'pointerdown');
spectator.dispatchMouseEvent(keyQ, 'pointerup');
spectator.dispatchMouseEvent(keyW, 'pointerdown');
});

const pointerDown = element => spectator.dispatchMouseEvent(element, 'pointerdown');
const pointerUp = element => spectator.dispatchMouseEvent(element, 'pointerdown');
pointerDown(keyQ);
pointerUp(keyQ);
pointerDown(keyW);
});

const pointerDown = element => spectator.dispatchMouseEvent(element, 'pointerdown');
const pointerUp = element => spectator.dispatchMouseEvent(element, 'pointerdown');
pointerDown(keyQ);
expect(keyQ).toHaveClass('key-pressed');
expect(keyW).not.toHaveClass('key-pressed');
pointerUp(keyQ);
expect(keyQ).not.toHaveClass('key-pressed');
expect(keyW).not.toHaveClass('key-pressed');
pointerDown(keyW);
expect(keyQ).not.toHaveClass('key-pressed');
expect(keyW).toHaveClass('key-pressed');
});

Class testing or component testing?
➔ Discuss it with your team
➔ What means the "unit" in "unit testing"?
➔ What does a class test prove about the quality of a component?
➔ Technical tests vs. functional tests

To mock... or not to mock?
Pure unit tests are run in isolation.
➔ Want to mock components/directives/pipes? Hello ng-mocks!

➔ Pure unit tests are run in isolation.
describe('AudioPlayerComponent', () => {
const createHost = createHostComponentFactory({
component: AudioPlayerComponent,
declarations: [
MockComponent(EbMediaControlsComponent)
],
providers: [
{ provide: AUTOPLAY_DELAY, useValue: 1000 }
]
});

➔ Pure unit tests are run in isolation.
But: nothing wrong with a bit of integration testing!
➔ Discuss with your team how you implement a test pyramid

Organize your testdata
● Consider complete and type-safe testdata
● Organize fixture data in one place
● Useful when using large & complex domain models
● Don't repeat yourself

Hello Jest!
● Fast, robust and powerful test framework
● Replaces Karma/Jasmine
● Simple migration path: compatible with Jasmine syntax (describe/it)
● Integrates very well with Angular (thymikee/jest-preset-angular)
● Integrates very well with Angular CLI (@angular-builders/jest)

Unit testing: lessons learned!
1. Consider Spectator instead of Angular TestBed
2. Consider Jest instead of Karma/Jasmine
3. Make unit testing FUN!
4. Go for functional component testing
- Don't think in methods, but in user events.
- Don't test from component class, but from DOM

Code quality
- Make your TypeScript compiler as strict as possible
- Make your TypeScript linting as strict as possible
- Take a look at Prettier
- Use modern JavaScript APIs and standards
- Don't fear old browsers!
- Embrace polyfills!

Complex stuff
- Take a look at @angular/cdk!
- Look at @angular/material for inspiration, to learn 'the Angular way'
- Use the power of MutationObserver, ResizeObserver, IntersectionObserver
- Don't be afraid to refactor!

Spend time on open-source development
We use open-source stuff every day. We should care about it.
1. Report your issue, and take time to investigate!
○ If you try hard, others will as well!
2. Try to fix it yourself, be a contributor!
○ Open-source projects are for everyone!
3. Improve yourself, read blogs. Know what's going on.

Reduce technical debt
1. Don't go for the best solution the first time!
○ Keep it simple so that you can obtain insights.
○ Prevent "over-engineering".
2. … but always improve things the second time!
○ Don't create refactor user stories, but take your refactor time for every user story!
○ This prevents postponing things and makes it more fun.
3. Too much technical debt? Bring it on the agenda for the upcoming sprint.

2 years of angular: lessons learned

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 2 years of angular: lessons learned

Ähnlich wie 2 years of angular: lessons learned (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

2 years of angular: lessons learned