Trung Vo's RSS Feed

Upgrading to Angular 20: more AI gotcha than I expected

Sun, 19 Apr 2026 06:00:00 GMT

After finishing the Jira Clone upgrade to Angular 20, I opened Angular Spotify and saw it was still on Angular 17. Same problem, different repo.

No Angular upgrade happens in this post. Two things came up during planning that are worth writing about. Claude gave confident answers that turned out to be wrong once I pushed back:

It insisted RxJS 7 was required before Angular 18. It is not, RxJS 6 still works.
It cited a Sentry migration guide for a pattern that is not on that page. The actual reference is in the package README.

If you are using AI for a migration (which is very likely a yes), those two sections are the main point to watch out for.

1. Where Angular Spotify stands today

Angular Spotify has drifted more than Jira Clone had. Current state:

Package	Current	Notes
`@angular/core`	`17.3.2`	Target: `20.x`
`@nx/*`	`18.2.0`	Nx already ahead of Angular, fine
`@ngrx/*`	`17.0.1`	Tracks Angular majors
`ng-zorro-antd`	`15.1.0`	Peer deps `@angular/core@^15.0.1`; highest-risk upgrade
`rxjs`	`6.6.6`	Last release `6.6.7` in 2021; see 3.3
`zone.js`	`0.14.4`	Fine for 17/18
`@sentry/angular`	`7.49.0`	Plus `@sentry/tracing@6.8.0`, deprecated
`jest`	`29.4.3`	Plan to migrate to Vitest at Angular 20
`eslint`	`8.57.0`	Flat config + ESLint 9 at Angular 20
`cypress`	`7.6.0`	Listed as a dep, but no e2e tests exist
`tailwindcss`	`3.3.2`	Stay on v3 (lesson from Jira Clone Part 7)

On the surface it looks fine: Angular 17, Nx 18, NgRx 17. The issue is ng-zorro-antd@15.1.0 where the peer deps only support @angular/core@^15.0.1 and we have been running Angular 17. Yarn tolerated the mismatch silently. If we were using npm, we would not have gone this far 😂

rxjs@6.6.6 also looked like a blocker. Claude said it was, it is not hehe. More on that in 3.3.

Going straight to Angular 20 means upgrading seven or eight packages across three Angular majors in one PR which is too risky. I am doing it as a series instead: 17 → 18 → 19 → 20, one major per PR, one post per step.

Before the Angular upgrade, there are four prep PRs to land first. That is what this post is about.

2. Kicking off Claude Code for planning

Same opening move as Part 7 of Jira Clone. I started with the plan, not the code. First prompt was roughly: Plan Angular 20 migration. I also want to write a blog post. Read my existing post to match the style.

It was back-and-forth, not a one-shot plan. Claude asked questions, I picked options. A few key decisions:

Strategy: Big-bang 17 → 20 in one PR, or stepwise? Went with stepwise. Smaller PRs, easier rollback.
Blog post shape: One giant post or one per Angular upgrade? One per upgrade. Three upgrades in one post loses the per-step detail.
Timing: Write the post as a guide upfront, or as a post-mortem after? Post-mortem. You want to write what actually happened, not what you planned.

Then Claude audited the repo and gave the assessment: which packages block the Angular upgrade, and which are just debt to clean up along the way.

3. Four prep PRs: peer-dependency analysis

Before touching Angular, figure out which other packages are tied to the Angular version and which are not. For example, ng-zorro-antd is tied — it only supports Angular 15. rxjs is not — it works across Angular 17 through 20.

Four packages kept coming up: @sentry/angular, ng-zorro-antd, rxjs, and cypress. For each one, the question was: does this block the Angular upgrade, or is it just debt I want to clean up anyway? One command answers that: npm view <pkg>@<version> peerDependencies.

peerDependencies is how a package tells you which version of its dependencies it expects you to have. For example, ng-zorro-antd@15 expects @angular/core@^15.0.1 — meaning it will might work correctly if you run it with Angular 17 or 18.

After two corrections (more on those below), this is Claude’s final classification:

#	PR	Status	What peer deps say
2.1	Sentry: drop `@sentry/tracing`, bump `@sentry/angular` to v8	Blocker	`@sentry/angular@7.49` caps `@angular/core` at `<= 15.x`
2.2	ng-zorro 15 → 17	Blocker	`ng-zorro-antd@15` caps `@angular/core` at `^15.0.1`
2.3	RxJS 6 → 7	Non-blocker	No peer-dep conflict, see 3.3
2.4	Cypress removal	Non-blocker	No peer-dep conflict

3.1 Sentry (blocker) · PR #112

$ npm view @sentry/angular@7.49.0 peerDependencies
{
  rxjs: '^6.5.5 || ^7.x',
  '@angular/core': '>= 10.x <= 15.x',      # caps at Angular 15
  '@angular/common': '>= 10.x <= 15.x',
  '@angular/router': '>= 10.x <= 15.x'
}

@sentry/angular@7.49.0 caps Angular at 15.x. We have been on Angular 17 for months because yarn allowed the mismatch.

There is also a second issue: @sentry/tracing@6.8.0 has no peer deps so nothing warned, but it pulls @sentry/*@6.8 internals while @sentry/angular@7.49 pulls @sentry/*@7.49. We have been shipping two different Sentry versions in one bundle without knowing it.

3.1.a Gotcha 1: right pattern, wrong source

The Sentry prep PR looked small on paper. Two files: main.ts for the v8 init API, and web-shell.module.ts. I did not expect was a new block in web-shell.module.ts:

{ provide: Sentry.TraceService, deps: [Router] },
{
  provide: APP_INITIALIZER,
  useFactory: () => (): void => undefined,
  deps: [Sentry.TraceService],
  multi: true
}

I asked Claude why the block was there. The answer was confident and came with a URL:

It is the pattern Sentry’s v8 Angular migration guide recommends. See here: https://docs.sentry.io/platforms/javascript/guides/angular/migration/v7-to-v8/

Sounded ok, then I opened the link. There is nothing on that page about TraceService or APP_INITIALIZER.

So I pushed back: “I do not see Sentry.TraceService mentioned on that page, are you sure?” Claude then ran curl against the actual Sentry docs, grepped for the terms, and came back with the correction.

There is actually a mention of TraceService and the APP_INITIALIZER pattern in the Sentry docs, but it is in the README at sentry-javascript/8.55.1/angular/README.md#tracing

What I want to remember from this one.

I treated a URL as confirmation. The URL did not support the claim. A citation is only a citation if you open it. When an AI cites a URL, open the URL.
When an AI adds code that the original did not have, ask why.

3.2 ng-zorro (blocker) · PR #113

$ npm view ng-zorro-antd@15.1.0 peerDependencies
{
  '@angular/core': '^15.0.1',              # caps at Angular 15
  '@angular/forms': '^15.0.1',
  '@angular/common': '^15.0.1',
  '@angular/router': '^15.0.1',
  '@angular/animations': '^15.0.1',
  '@angular/platform-browser': '^15.0.1'
}

Same as Sentry, but worse. ng-zorro-antd@15 pins Angular to ^15.0.1 and we are on Angular 17. It has been running on an unsupported Angular version the whole time.

This is the highest-risk PR. ng-zorro touches around several files: player controls, lyrics toggle, modals, toasts. Bumping 15 → 17 means two majors of breaking changes at once: theme tokens, form control API, modal service signatures, and the usual nz-select template quirks.

Why 17 and not 18? To keep the PR manageable. One ng-zorro major per Angular step: 15 → 17 now, then 17 → 18, 18 → 19, 19 → 20 alongside each Angular upgrade.

3.3 Gotcha 2: RxJS is not actually required for Angular 18 · PR #114

Claude’s first take was confident:

PR A, RxJS 6 → 7. Angular 18 requires it; doing it on 17 isolates RxJS breakage from Angular breakage.

I almost accepted that. But something feel wrong, and to find out I asked for the actual npm view output. That is when it fell apart:

$ npm view @angular/core@17.3.2 peerDependencies
{ rxjs: '^6.5.3 || ^7.4.0', 'zone.js': '~0.14.0' }

$ npm view @angular/core@18.2.13 peerDependencies
{ rxjs: '^6.5.3 || ^7.4.0', 'zone.js': '~0.14.10' }

$ npm view @angular/core@19.2.21 peerDependencies
{ rxjs: '^6.5.3 || ^7.4.0', 'zone.js': '~0.15.0' }

$ npm view @angular/core@20.3.19 peerDependencies
{ rxjs: '^6.5.3 || ^7.4.0', 'zone.js': '~0.15.0' }

Angular 17 through 20 all accept rxjs@^6.5.3 || ^7.4.0. rxjs@6.6.6 is within that range. Claude made up the Angular 18 requirement.

RxJS 6 → 7 is not a blocker. Worth doing anyway since RxJS 6 has not had a release since 2021, .toPromise() is deprecated, and third-party Angular libs are dropping v6 support. But it does not gate the Angular upgrade.

I also grepped apps/ and libs/ for .toPromise( and got zero hits. This PR ends up being just a version upgrade.

What I want to remember from this one. Claude sounded sure. The confidence was not evidence. npm view took ten seconds and settled the question. Without pushing back, I would have shipped this PR based on a made-up requirement.

3.4 Cypress (non-blocker) · PR #115

$ npm view cypress@7.6.0 peerDependencies
(none)

Cypress has no peer deps. No Angular conflict.

But I checked what the repo actually has:

No apps/*-e2e folder
No cypress.config.ts or cypress.json outside node_modules/
No *.cy.ts spec files anywhere in apps/ or libs/
cypress is in package.json, downloaded on every yarn install, and nothing uses it

This is not an upgrade. It is a removal. The plan was updated.

4. Four subagents, one parallel run

Two blockers, two non-blockers, nothing depends on anything else. Good fit for running all four in parallel.

The approach:

Commit the plan and briefs to main first. Every subagent’s worktree starts from the same docs.
Spawn four Claude Code subagents in parallel, one per PR, each in its own git worktree so they do not step on each other.
Each subagent reads its brief, executes, validates, and commits on its branch. No pushes, no PRs. I review before merging.
Merge in order: 2.1 → 2.2 → 2.3 → 2.4. Blockers first. package.json and yarn.lock conflicts are expected, so each PR rebases onto main after the previous one lands.

The briefs are at docs/plans/prep/2.1-sentry-v8.md through 2.4-cypress-remove.md. Each one is self-contained with the scope, current state, exact commands, and a validation checklist. A subagent can start cold without reading anything else.

In the Jira Clone series I ran everything sequentially in one Claude Code session. Here, four sessions run on four branches at the same time.

5. Source

Plan: docs/plans/2026-04-18-angular-20-migration-plan.md
Briefs: docs/plans/prep/
Repo: https://github.com/trungvose/angular-spotify
Jira Clone counterpart: Part 7, Angular 20 with Claude Code

6. Two lessons

Both cases had the same pattern: a confident answer, close to right but not quite, with a plausible-looking source. Both only surfaced because I pushed back.

Three things I am keeping from this:

Run npm view <pkg>@<version> peerDependencies yourself occasionally. Do not accept “requires X” without verifying.
When an AI cites a URL, open it.

This is not an argument against using Claude Code for migrations. Both mistakes were caught in the back-and-forth. The problem is not that the AI makes things up. It is that you accept them without checking.

Pushing back matters more as AI gets better at sounding confident. I wish AI would push back more often 😂

How to hide Agent View by default on startup in Antigravity

Sat, 11 Apr 2026 06:00:00 GMT

I really enjoy using Antigravity so far. I use it mainly as an editor like VS Code, but it has some nice touches. For example, the Save prompt when closing an unsaved file has keyboard-navigable options that you can cycle through without reaching for the mouse. Even though you can always use Cmd + S to save or Cmd + D to discard in VS Code since those are built-in Mac shortcuts, it feels very nice to have full keyboard navigation on the dialog itself.

That said, since I use Claude Code as my primary agent, I don’t need the Agent view that Antigravity opens by default on startup.

Here is how to turn it off.

Steps

Click on the gear/settings icon in the header at the top-right corner, then click on “Open Antigravity User Settings”. A dialog will open.

Under the “Agent” section, scroll down and find Open Agent on Reload.

Turn it off. By default, it is turned on.

That is it. Next time you open Antigravity, the Agent view will no longer appear on startup.

Upgrade to Angular 20 from Angular 13 - Part 7: Angular 20 with Claude Code

Fri, 03 Apr 2026 06:00:00 GMT

We made it. In Part 6, we upgraded Jira Clone from Angular 18 to 19. That was the quietest upgrade in the series: remove standalone: true, bump some versions, done.

Part 7 is the opposite. This is the biggest single upgrade in the entire series, and also the longest Claude Code session at 36 minutes. Not because Angular 20 itself is hard, but because we took the opportunity to modernize everything at once: the build system, the test runner, the linter config, and even cleaned out Storybook.

1. What changed

Here is everything we did in one branch:

Angular 19 to 20 with all ecosystem deps (ng-zorro-antd 20, ngx-quill 28, CDK 20)
Build system migration: dropped @angular-builders/custom-webpack (webpack) and moved to @angular/build:application (esbuild)
TailwindCSS v4 attempt and revert: tried migrating to v4, hit critical incompatibilities with Angular component styles, reverted to v3
Karma to Vitest: removed Karma + Jasmine, migrated all spec files to Vitest
ESLint flat config: .eslintrc.json to eslint.config.js with ESLint 9
Storybook removal: deleted Storybook v6 and all related deps
Deprecated deps cleanup: removed codelyzer, tslint, nz-tslint-rules, protractor

2. Dependency upgrades

Package	Before (v19)	After (v20)
`@angular/core`	`^19.2.20`	`^20.3.18`
`@angular/cli`	`^19.2.22`	`^20.3.21`
`@angular/cdk`	`^19.2.19`	`^20.2.14`
`ng-zorro-antd`	`^19.3.1`	`^20.4.4`
`@ant-design/icons-angular`	`^19.0.0`	`^20.0.0`
`ngx-quill`	`^27.1.2`	`^28.x`
`@angular-eslint/*`	`19.8.1`	`20.7.0`
`eslint`	`^8.57.0`	`^9.28.0`
`tailwindcss`	`^3.0.12`	`^3.4.17`
`typescript`	`~5.8.3`	`~5.8.3`

A lot of packages were added (Vitest, @angular/build) and even more were removed (Karma, Storybook, webpack tooling, deprecated linters). The node_modules got noticeably lighter.

3. Build system and TailwindCSS

3.1 Esbuild migration (success)

The project has used @angular-builders/custom-webpack since Angular 13 purely for TailwindCSS PostCSS processing. That is a lot of webpack baggage for one CSS preprocessor.

Angular 20 with the application builder (esbuild) handles PostCSS natively. So the entire custom webpack setup becomes unnecessary. We dropped @angular-builders/custom-webpack, deleted webpack.config.js, and pointed angular.json at @angular/build:application. Build times improved noticeably with esbuild, though I did not benchmark it.

That part went fine. The TailwindCSS part did not.

3.2 Tailwind v4 attempt (failure)

Claude suggested upgrading TailwindCSS from v3 to v4 as part of the modernization. The agent converted the 500-line tailwind.config.js into CSS @theme blocks inside styles.scss, changed the import to @import 'tailwindcss', and deleted the old config file. The build passed. Tests passed. Everything looked fine in the terminal.

Then I opened localhost:4200. The entire UI was broken. No layout, no colors, no spacing. The Kanban board was just raw text floating on a white page.

3.3 Investigating Tailwind v4

Working with Claude interactively this time, we looked into why things broke. We connected to the running app via Chrome DevTools and found multiple issues stacked on top of each other:

Problem 1: Sass ate the Tailwind import. The global stylesheet was styles.scss. Sass runs before PostCSS, so it resolved @import 'tailwindcss' by inlining the raw CSS file from node_modules. By the time Tailwind’s PostCSS plugin ran, there was nothing left to process. Zero utility classes generated. Fix: rename styles.scss to styles.css.

Problem 2: Missing PostCSS plugin. Angular’s @angular/build needed @tailwindcss/postcss registered in a postcss.config.json file. Not .js, not .mjs. Angular only reads the JSON format.

Problem 3: Component styles need @reference. In Tailwind v4, @apply no longer works globally. Angular component SCSS files that use @apply cannot access the global theme. Each component file needs @reference "path/to/styles.css" at the top, with the correct relative path. We have 15+ component files at different directory depths. I tried building a custom PostCSS plugin to auto-inject the reference, but Angular’s plugin loader made that complicated too.

Problem 4: It is a known issue. I found this GitHub discussion confirming @apply with @reference does not work well in Angular. People report dev server startup times going from 38 seconds to 3+ minutes. There is no official solution from either the Tailwind or Angular team.

3.4 Downgrading to Tailwind v3

After all that, we downgraded to Tailwind v3 (^3.4.17). Restored the old tailwind.config.js from git. Restored styles.scss with v3 directives (@tailwind base, @tailwind components, @tailwind utilities). Removed all the v4 PostCSS config. Everything just worked.

In v3, @apply is global by default. No @reference needed. No custom PostCSS plugins. I updated the purge field to content for current v3 compatibility, and that was it.

We also fixed a few more CSS issues while we were in there. The nz-select custom templates in the create issue modal had a 60px height bug. ng-zorro adds a ::after strut pseudo-element to .ant-select-selection-item that was stacking with the custom template content (30px strut + 30px content = 60px). We tracked this down through Chrome DevTools and fixed it with a display: flex override.

4. Karma to Vitest

Karma is deprecated in Angular 20 and scheduled for removal in v22. We moved to Vitest now rather than waiting.

The migration was more involved than expected. Vitest uses vi.fn() instead of jasmine.createSpy(), and the spy API is different enough that every spec file with mocks needed updating:

Jasmine	Vitest
`jasmine.createSpy('name')`	`vi.fn()`
`spy.and.returnValue(x)`	`spy.mockReturnValue(x)`
`spy.and.callFake(fn)`	`spy.mockImplementation(fn)`
`spy.calls.reset()`	`spy.mockReset()`
`spyOn(obj, 'method').and.callThrough()`	`vi.spyOn(obj, 'method')`

About half the spec files needed these conversions. The rest used only describe/it/expect which work identically in Vitest. All tests passing after the migration.

5. ESLint flat config

ESLint 9 uses a new eslint.config.js format (flat config) instead of the old .eslintrc.json. The legacy format still works in ESLint 9 but will be removed in ESLint 10.

The migration preserved all our existing rules: naming conventions, disabled rules, component selector configs. The flat config format is actually cleaner. No more overrides with file globs nested inside. Everything is top-level.

We also removed three deprecated packages that have been sitting in devDependencies since the Angular 13 days: codelyzer, tslint, and nz-tslint-rules. They were not doing anything.

6. Storybook removal

Storybook v6 has been skipped across four consecutive migrations (Parts 4, 5, 6, and now 7). It stopped working properly after the Angular 17 upgrade and we kept carrying it forward. Time to let go.

Removing Storybook and its transitive dependencies made a surprising reduction in the dependency tree. If we need component documentation in the future, starting fresh with Storybook v8 will be cleaner than upgrading from v6.

7. Claude Code session

This was the longest single Claude Code session in the series at 36 minutes. For context, the Angular 19 upgrade (Part 6) took about 15 minutes.

The extra time was expected. This session covered four major migrations (build, tests, linter, cleanup) on top of the standard version bump.

However, the automated session broke the styling completely. Claude suggested upgrading to Tailwind v4 and the build looked fine, but the actual app was unusable (see section 3). That kicked off a separate interactive session where we connected Claude Code to Chrome DevTools, opened the real browser, and debugged the issues together. We investigated the CSS output, found the root causes, tried fixes, and ultimately downgraded to Tailwind v3. We also found and fixed the ng-zorro select height bug the same way: look at the page, inspect the element, trace the CSS rules, apply the fix, verify in the browser.

This is the part that matters. The initial automated run did not have a way to verify its own work visually. It ran ng build, got a green checkmark, and moved on. Having a feedback loop where AI can verify the result in a real browser is what makes the difference. When we switched to the interactive session with Chrome DevTools, every fix was verified on screen before moving to the next issue. That loop is what turned a broken app into a working one.

8. Deploy output path changed

One thing to watch out for: the new application builder outputs to dist/<project-name>/browser instead of just dist. If your deployment platform is configured to serve from dist, your site will break silently. No build error, no warning. The deploy just serves an empty directory.

I caught this when deploying to Netlify. The build passed, the deploy succeeded, but the site was blank.

The fix is to update the publish directory from dist to dist/browser on Netlify (or whatever hosting you use). It is a one-line config change, but easy to miss because nothing tells you the output path has changed.

9. Source code

https://github.com/trungvose/jira-clone-angular/pull/114

10. What I learned

Angular 20 itself is a smooth upgrade. The framework changes are minimal if your codebase is already standalone with modern control flow. The real work is everything around it: the build tooling, the test runner, the linter.

The biggest lesson from this upgrade is not about Angular or Tailwind. It is about verification loops. The initial Claude Code session ran the build, ran the tests, and reported success. But no one opened the browser. The app was completely broken and no automated check caught it.

When we switched to an interactive session with Claude connected to Chrome DevTools, the workflow changed. Every change was verified on the actual page. We could see what was broken, inspect the CSS, apply a fix, and confirm it worked before moving on. That is the loop that matters. If you are using AI to make changes to your app, give it a way to see the result. A passing build is not the same as a working app.

On Tailwind specifically: v4 and Angular component styles do not play well together right now. @apply needs @reference in every component file, the performance impact is real, and there is no official fix. If your Angular project uses @apply in component styles, stay on v3 until the tooling catches up.

Looking back at the full series:

Part	Key work
#1 \| 13 to 14	Manual dependency resolution
#2 \| 14 to 15	Standalone components begin
#3 \| 15 to 16	Signals introduced, more standalone migration
#4 \| 16 to 17	Massive: new control flow syntax, full standalone
#5 \| 17 to 18	NgModule removal, Quill v2, route config migration
#6 \| 18 to 19	Simplest: remove standalone flag
#7 \| 19 to 20	Build, test, lint modernization

Seven parts, seven versions, one codebase taken from Angular 13 to Angular 20. The journey from a legacy NgModule-based app with *ngIf and Karma to a fully standalone app with @if, esbuild, Vitest, and ESLint 9 flat config.

We are done.

Fuzzy search everywhere on macOS with fzf and fd

Fri, 27 Mar 2026 02:00:00 GMT

I spend a lot of time jumping between project folders. Open a terminal, type cd, tab-complete through nested directories, realise I went the wrong way, backtrack. Repeat.

I wanted something faster. A global shortcut that opens a fuzzy finder, I type a few characters, hit enter, and I am in the right folder with my editor open.

That inspiration came from ThePrimeagen. I watched one of his courses on Frontend Masters last year about setting up the development environment. He mentioned having a global shortcut to open a fuzzy finder to jump to any folder. The tricky part? He did not exactly explain how he configured the workflow.

So I went looking, and found fzf.

What is fzf

fzf is a command-line fuzzy finder. You pipe a list of things into it, it lets you type to filter, and it returns what you pick. That is the whole idea.

Install it with Homebrew:

brew install fzf

After installing, just type fzf in your terminal. It will list every file on your machine and let you search through them.

fzf

You type a few characters, the list narrows down, you press Enter, and it prints the selected path. Simple.

fzf preview

One useful feature is the preview window. You can tell fzf to show the content of whatever file you have highlighted:

fzf --preview 'cat {}'

This opens a split view. The left side is your search list, the right side shows the file content. Useful when you are looking for a specific file but do not remember the exact name.

You can customise the preview command too. For example, if you have bat installed (a cat alternative with syntax highlighting):

fzf --preview 'bat --color=always {}'

What I actually needed

The default fzf experience is nice for searching files. But what I wanted was different. I wanted to search for directories, not files. And when I pick one, I want it to open in my editor. Not print a path. Not cd into it. Just open the project.

So the question became: how do I list only directories, scope the search to folders I care about, and wire it up to a shortcut?

Why fd over find

By default, fzf uses find to list files. It works, but find is slow on large directory trees and has no concept of ignore rules. It will happily crawl through node_modules/, .git/, Library/, and every other folder you never want to see.

fd is a faster alternative to find. Two things make it worth switching:

It is significantly faster, especially on large directory trees
It respects .gitignore and .ignore files by default. See reference

That second point is the real reason. You can define once which folders to include and exclude, and fd will follow those rules every time.

brew install fd

On Debian/Ubuntu the binary is called fdfind, but on macOS via Homebrew it is just fd. If you see tutorials using fdfind, swap it out.

If you just run fd by itself, it lists all files and folders it can find. To list only directories, use the --type d flag:

fd --type d

On its own, that still dumps the full list to the terminal. That is where we pipe it through fzf to get fuzzy search over the results:

fd --type d | fzf

Now you get a searchable list of only directories. Type a few characters, the list narrows, pick one. That is the core of the whole setup.

Control what fd searches with .ignore

By default, fd will crawl everything under your home directory. You do not want that. Thousands of folders inside Library/ will flood your results.

Create a ~/.ignore file. The trick is to block everything first, then allow list the folders you actually care about using !:

To get the list of folder from root, run the following command

cd ~/
ls -d */ | pbcopy

Applications/
Desktop/
Documents/
Library/
Movies/
Music/
Pictures/
Public/
bin/
go/
+ !Downloads/
+ !Source/

Lines without ! are ignored by fd. Lines with ! are re-included. So in this setup, only Downloads/ and Source/ get searched. Clean results, fast searches.

Wire it up in .zshrc

Tell fzf to use fd as its default search command, and add a helper function:

export FZF_DEFAULT_COMMAND="fd . $HOME"
export FZF_DEFAULT_OPTS="--bind 'alt-down:first,alt-up:last'"

fzf-open() {
  local dir=$(fd . $HOME --type d | fzf)
  if [ -n "$dir" ]; then
    agy "$dir"
  fi
}

When you type fzf-open, it lists all directories under $HOME (filtered by .ignore), pipes them into fzf, and opens the selected folder. Replace agy with whatever you use to open projects, could be code, cursor, or just cd.

The FZF_DEFAULT_OPTS line adds Alt+Down to jump to the first result and Alt+Up to jump to the last. On Mac, the default Cmd+Up/Down controls text navigation, so fzf cannot use the Command key directly. There is a section below on how to remap that. Useful when you have scrolled through a long list and want to get back quickly.

iTerm2 hotkey to trigger fzf-open

This is the part that makes it feel seamless. Instead of opening a terminal and typing fzf-open, I wanted a single keyboard shortcut from anywhere on my Mac to open a terminal and run fzf-open automatically.

iTerm2 has a Hotkey Window feature that does exactly this:

Open iTerm2 Settings, go to Profiles
Create a new profile called fzf-open, set the command to zsh -lic 'fzf-open; exec zsh'
Under Keys, check A hotkey opens a dedicated window with this profile
Set your preferred shortcut

Make it fast with a dedicated script

My first attempt was to set the profile command to zsh -lic 'fzf-open; exec zsh'. It worked, but it was slow. Every time I triggered the shortcut, zsh would load my entire .zshrc - oh-my-zsh, powerlevel10k, nvm, asdf, pyenv, plugins, completions. All that just to run fd and fzf.

The fix is to skip .zshrc entirely. Create a minimal script at ~/.fzf-open.sh:

#!/bin/zsh
export PATH="/opt/homebrew/bin:$PATH:$HOME/.antigravity/antigravity/bin"
dir=$(fd . $HOME --type d | fzf --bind alt-down:first,alt-up:last)
[ -n "$dir" ] && agy "$dir"

Make it executable:

chmod +x ~/.fzf-open.sh

Then set the iTerm2 profile command to:

zsh ~/.fzf-open.sh

This script only sets the PATH needed for fd, fzf, and agy. Nothing else loads. The difference is noticeable - fzf appears almost instantly instead of waiting a second or two for the full shell to initialise.

Cmd+Up and Cmd+Down in fzf

fzf does not support the Command key natively. The only modifiers it recognises are ctrl-, alt-, and shift-.

But iTerm2 can remap keys. So I mapped Cmd to send Alt escape sequences:

Go to iTerm2 Settings, Profiles, Keys, Key Mappings
Add Cmd+Down with action Send Hex Code: 0x1b 0x5b 0x31 0x3b 0x33 0x42
Add Cmd+Up with action Send Hex Code: 0x1b 0x5b 0x31 0x3b 0x33 0x41

This part was largely suggested by Claude. I have not checked why it maps to these specific hex codes, but they are the escape sequences for Alt+Down and Alt+Up. iTerm2 intercepts the Cmd keypress and sends what fzf actually understands.

Now Cmd+Down jumps to the first item and Cmd+Up jumps to the last.

Final Result

One keyboard shortcut from anywhere on macOS. A fuzzy search scoped to only the folders I care about. Pick a folder, hit enter, project opens. The whole thing takes maybe two seconds.

The setup is five pieces working together: fd for fast directory listing, .ignore for scoping, fzf for fuzzy matching, a shell function to glue it together, and iTerm2 hotkey window to make it globally accessible.

Such a good way to bring joy to my daily work.

Speed up zsh startup by lazy loading nvm

Tue, 24 Mar 2026 12:00:00 GMT

Every time I opened a new terminal, there was a noticeable delay. About one second of staring at a blank screen before the prompt appeared. Not terrible, but it added up. Open a terminal to run a quick command, wait. Split a new pane for Claude Code, wait. After a while, I decided to figure out what was causing it.

Since I use Claude Code for almost everything now, I started a session and asked it to investigate. It profiled my shell, found the bottleneck, and suggested the fix. Here is what we found.

Profiling with zprof

zsh has a built-in profiler called zprof. It is part of the zsh/zprof module, and it tells you exactly how long each function takes during shell initialisation.

To use it, add this line to the top of your ~/.zshrc:

zmodload zsh/zprof

And this line to the bottom:

zprof

Then restart your shell:

exec zsh

When zsh starts, zprof loads first and starts recording. After everything else in .zshrc finishes, zprof prints a table showing every function that ran and how long it took.

You can also run it as a one-liner without editing your .zshrc:

zsh -c 'zmodload zsh/zprof; source ~/.zshrc 2>/dev/null; zprof'

nvm is the culprit

Here is what my profiling output looked like:

And here is the output of time zsh -i -c exit

zsh -i -c exit 2>&1 < /dev/null  0.39s user 0.60s system 88% cpu 1.122 total

Let me break down the top rows:

#	Function	Time	% of startup	What it does
1	`nvm`	486ms	49.5%	The core nvm function that sets up the correct Node.js version and PATH
2	`nvm_ensure_version_installed`	188ms	19.1%	Checks that the Node version nvm wants to use is actually installed on disk
3	`compinit`	316ms	32.2%	Initialises zsh’s tab completion system, scanning and compiling all completion functions
4	`compdef`	111ms	11.3%	Registers completion functions for specific commands, called 811 times by compinit
5	`nvm_auto`	597ms	60.8%	The entry point that triggers nvm on shell startup, calls `nvm` internally

The time column includes time spent in sub-functions. So nvm_auto (597ms) calls nvm (486ms) which calls nvm_ensure_version_installed (188ms). They overlap, you cannot add them together. The real total for nvm is nvm_auto’s 597ms.

The compinit row looks high here (316ms) because I had just cleared the zsh completion cache before this run. Normally it loads from a cached .zcompdump file and takes around 30ms. So it is not a real concern.

The actual bottleneck is nvm. It accounts for 60% of the total startup time. Every time I opened a terminal, nvm was checking which Node version to use, verifying it was installed, and setting up the environment. All before I even typed anything.

The rest, oh-my-zsh, powerlevel10k, syntax highlighting, were all fast enough that I would never notice them.

Lazy loading nvm

The fix is simple. Instead of loading nvm immediately when the shell starts, load it the first time you actually use it. If you open a terminal just to run git status or docker compose up, there is no reason to wait for nvm.

Replace this in your .zshrc:

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"

With this:

export NVM_DIR="$HOME/.nvm"

# Lazy load nvm - only initialise when first used
nvm() {
  unfunction nvm node npm npx
  [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
  nvm "$@"
}
node() {
  unfunction nvm node npm npx
  [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
  node "$@"
}
npm() {
  unfunction nvm node npm npx
  [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
  npm "$@"
}
npx() {
  unfunction nvm node npm npx
  [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
  npx "$@"
}

Each function is a placeholder. The first time you run node, npm, npx, or nvm, it removes all the placeholder functions, loads the real nvm, and then runs your command. From that point on, nvm is fully loaded and everything works normally.

The unfunction call removes all four placeholders at once. This way, after any one of them triggers the load, the others do not accidentally try to load nvm a second time.

Ater result

After lazy loading (cold start, no completion cache):

#	Function	Time	% of startup	What it does
1	`compinit`	331ms	79.8%	Rebuilds zsh tab completion cache from scratch
2	`compdef`	109ms	26.3%	Registers completion functions, called 810 times
3	`compdump`	79ms	19.0%	Writes the completion cache to disk for next time

zsh -i -c exit  0.19s user 0.25s system 85% cpu 0.508 total

After lazy loading (warm start, completion cache exists):

#	Function	Time	% of startup	What it does
1	`_omz_source`	52ms	59.9%	Loads oh-my-zsh plugins
2	`compaudit`	11ms	13.1%	Checks completion directory permissions
3	`compinit`	19ms	22.0%	Loads zsh tab completion from cache

zsh -i -c exit  0.07s user 0.08s system 84% cpu 0.171 total

nvm is completely gone from both. On a warm start, that is 1.12 seconds down to 0.17 seconds, a 6.5x improvement, just by deferring one tool that I do not need on every shell session.

One thing to watch out for

If you have scripts or tools that expect node or npm to be available immediately when the shell starts, lazy loading might cause issues. In my case, everything that runs Node goes through the terminal interactively, so it is fine. The first npm install or node script.js takes a tiny bit longer because it loads nvm first, but after that, it is instant.

If you use .nvmrc files and rely on nvm automatically switching Node versions when you cd into a project, you will need to trigger the load manually once, or add the auto-switching logic to the lazy loader. For my workflow, I just run nvm use when I need a specific version.

Conclusion

1 second might not sound like much, but when you are opening terminals dozens of times a day, it adds up fast.

Upgrade to Angular 20 from Angular 13 - Part 6: Angular 19 with Claude Code

Sun, 22 Mar 2026 02:00:00 GMT

We are back. In Part 5, we upgraded Jira Clone from Angular 17 to 18 using Claude Code. That was the cleanup release: we removed all remaining NgModules, migrated to provideRouter() with standalone route configs, and upgraded Quill from v1 to v2.

Angular 19 continues the theme of simplification. The headline change: standalone: true is now the default for all components, directives, and pipes. You no longer need to declare it. The flag we added to every single component during the Angular 17 migration? It can all be removed.

Beyond that, Angular 19 requires TypeScript 5.5+ and zone.js 0.15. And the eslint tooling took a significant jump: @angular-eslint v19 requires typescript-eslint v8, up from v6.

1. Approach

Same pattern as every previous part. I gave Claude the previous implementation plans. It generated a plan with the usual structure: upgrade dependencies one at a time, verify builds, push and PR.

The main difference from previous parts: there is no Phase 2. No code migration phase. Angular 19 has no new syntax to adopt, no modules to remove, no control flow to rewrite. The standalone: true removal is handled automatically by the ng update schematic. This is the simplest upgrade in the series so far.

2. Dependency upgrades

Package	Before (v18)	After (v19)
`@angular/core`	`^18.2.14`	`^19.2.20`
`@angular/cli`	`^18.2.21`	`^19.2.22`
`@angular-builders/custom-webpack`	`^18.0.0`	`^19.0.1`
`@angular-eslint/*`	`18.4.3`	`19.8.1`
`@typescript-eslint/*`	`6.21.0`	`^8.0.0`
`@angular/cdk`	`^18.2.14`	`^19.2.19`
`ng-zorro-antd`	`^18.2.1`	`^19.3.1`
`@ant-design/icons-angular`	`^18.0.0`	`^19.0.0`
`ngx-quill`	`^26.0.10`	`^27.1.2`
`typescript`	`~5.4.5`	`~5.8.3`
`zone.js`	`~0.14.10`	`~0.15.1`

The ng update schematic handled Angular core, TypeScript, and zone.js all in one step. That left the ecosystem dependencies to upgrade one at a time.

2.1 `standalone: true` removal

The ng update @angular/core@19 schematic automatically removes standalone: true from all component, directive, and pipe decorators. In Angular 19, standalone is the default. If you have a component that is NOT standalone (i.e., it belongs to an NgModule), the schematic adds standalone: false explicitly.

In our case, all components are standalone. The schematic caught most of them. A few were missed (likely because they had slightly different decorator formatting). I removed the remaining ones manually. A quick grep -r "standalone: true" src/ confirmed zero remaining.

Before:

@Component({
    selector: 'board-dnd',
    templateUrl: './board-dnd.component.html',
    styleUrls: ['./board-dnd.component.scss'],
    standalone: true,
    imports: [BoardDndListComponent]
})

After:

@Component({
    selector: 'board-dnd',
    templateUrl: './board-dnd.component.html',
    styleUrls: ['./board-dnd.component.scss'],
    imports: [BoardDndListComponent]
})

Less boilerplate. Every component file got one line shorter.

2.2 `typescript-eslint` v8 jump

This was the riskiest dependency change. @angular-eslint v19 requires typescript-eslint v8, and we were on v6.21.0. That is a two-major-version jump.

The good news: our .eslintrc.json config is minimal with no custom rules. The upgrade went through cleanly. ng lint passed with zero errors on the first try. If your project has extensive custom eslint rules, you might have more work here.

2.3 `browserTarget` rename

One gotcha: Angular 19 renamed browserTarget to buildTarget in the angular.json serve configuration. The ng update schematic did not catch this because we use @angular-builders/custom-webpack:dev-server instead of the standard builder. Running ng serve immediately failed with:

Error: Schema validation failed with the following errors:
  Data path "" must have required property 'buildTarget'.

A one-line fix in angular.json:

- "browserTarget": "frontend:build:development"
+ "buildTarget": "frontend:build:development"

3. Result

Application compiles, builds, and lints without errors.

Claude also opened Chrome and verified the app in the browser. This matters more than it sounds. An AI that can validate its own work end-to-end — not just compile, but actually click through the UI and check for runtime errors — can work independently without you babysitting each step.

No runtime errors this time. Board view, issue detail with Quill editor, settings page, navigation — all working. The only console messages are pre-existing accessibility warnings about form labels.

4. Source code

https://github.com/trungvose/jira-clone-angular/pull/113

5. What I learned

Angular 19 is the quietest upgrade in this series. No new syntax to learn, no architecture to change, no surprising runtime errors. The standalone: true removal is satisfying but mechanical. The real work was already done in Angular 17 and 18.

The browserTarget → buildTarget rename is the kind of thing that bites you if you use custom builders. The standard Angular CLI schematics handle it automatically, but third-party builders like @angular-builders/custom-webpack get left behind. Always test ng serve after an upgrade, even if ng build passes.

The typescript-eslint v6 → v8 jump looked scary but turned out to be painless for our minimal config. Your mileage may vary depending on how many custom lint rules you have.

One observation across this entire series: each Angular upgrade has been simpler than the last. Part 1 (Angular 14) required manual dependency detective work. Part 4 (Angular 17) was a massive syntax and architecture migration. Part 5 (Angular 18) removed leftover modules. And now Part 6 (Angular 19) is essentially just bumping version numbers and removing a redundant flag. The Angular team’s incremental approach to modernization is working.

6. What’s next

We are at Angular 19. One more step to go: 19 → 20. Angular 20 is the finish line. The codebase is now fully standalone, fully using modern control flow syntax, zero NgModules, and ready for whatever Angular 20 brings.

See you in Part 7, the final part.

Fast terminal navigation for running multiple AI agents in Antigravity

Fri, 20 Mar 2026 12:00:00 GMT

I have been using Claude Code extensively for the past few months. It changed how I work. Most of my coding now happens in the terminal, not in the editor. I write a prompt, Claude does the work, I review the diff. Repeat.

Cursor is great, but it is built around the idea that AI lives inside the editor. Claude Code flips that. The terminal is the interface. Once I accepted that, I realized I needed a code editor that treats the terminal as a first-class citizen.

That is when I switched to Antigravity.

Why Antigravity

Since I am using Claude Code for almost everything now, I do not need most of what Cursor offers. The tab completion with code suggestions? I do not use it. The inline prompt to generate code? I do not use that either. Everything goes through Claude Code in the terminal.

So I asked myself, why am I paying for Cursor when I am not using any of its features?

I wanted to switch back to something free, like VS Code. Then I found Antigravity. It is a good mix of what VS Code already does well, plus some promising features like Agent Manager. And it is free.

Here is the thing. If you are running multiple Claude Code sessions, or running your dev server in one tab and Claude in another, you need to switch between them quickly. Fumbling with the mouse to click on the right terminal tab breaks the flow.

You could use iTerm separately from your IDE. It comes with fantastic shortcuts out of the box. But I prefer the integrated terminal within my IDE because I still need to open files and review diffs generated by Claude. Yes, I still review them.

In the past, I usually had 2 or 3 terminals running at most. One for the API server, one for the frontend, and that was about it. No real need to navigate between them. But with Claude Code, I now have 4 to 5 terminals open at the same time. Fast navigation became a must.

So I spent about an hour setting up these keybindings, and it made a huge difference. You can copy and paste this into your keybindings JSON file.

Here is the full keybindings config:

{
  "key": "cmd+n",
  "command": "workbench.action.terminal.new",
  "when": "terminalFocus"
},
{
  "key": "cmd+w",
  "command": "workbench.action.terminal.kill",
  "when": "terminalFocus"
},
{
  "key": "alt+cmd+down",
  "command": "workbench.action.terminal.focusNext",
  "when": "terminalFocus && terminalHasBeenCreated && !terminalEditorFocus || terminalFocus && terminalProcessSupported && !terminalEditorFocus"
},
{
  "key": "alt+cmd+up",
  "command": "workbench.action.terminal.focusPrevious",
  "when": "terminalFocus"
},
{
  "key": "alt+cmd+right",
  "command": "workbench.action.terminal.focusNextPane",
  "when": "terminalFocus && terminalHasBeenCreated || terminalFocus && terminalProcessSupported"
},
{
  "key": "alt+cmd+left",
  "command": "workbench.action.terminal.focusPreviousPane",
  "when": "terminalFocus && terminalHasBeenCreated || terminalFocus && terminalProcessSupported"
},
{
  "key": "shift+cmd+enter",
  "command": "workbench.action.toggleMaximizedPanel",
  "when": "terminalFocus"
},
{
  "key": "shift+cmd+=",
  "command": "workbench.action.increaseViewSize",
  "when": "terminalFocus"
},
{
  "key": "shift+cmd+-",
  "command": "workbench.action.decreaseViewSize",
  "when": "terminalFocus"
}

A quick breakdown:

Shortcut	What it does
`⌘ N`	New terminal tab
`⌘ W`	Close terminal tab
`⌥ ⌘ Down`	Focus next terminal tab
`⌥ ⌘ Up`	Focus previous terminal tab
`⌥ ⌘ Right`	Focus next pane (split window)
`⌥ ⌘ Left`	Focus previous pane (split window)
`⇧ ⌘ Enter`	Toggle maximize terminal panel
`⇧ ⌘ =`	Increase terminal size
`⇧ ⌘ -`	Decrease terminal size

The idea is simple.

1. Focus into the terminal

⌘ J toggles the terminal panel. ⌃ ` opens a new terminal if none exists, or focuses into the existing one. These are default keybindings, no extra configuration needed.

2. Open and close terminal tabs

⌘ N creates a new terminal tab and ⌘ W closes the current one, just like managing tabs in a browser.

Note that the terminal must be focused for these to work. Otherwise, ⌘ W will close the editor tab, or Antigravity itself if no tab is open.

3. Navigate between tabs

⌥ ⌘ Up/Down moves between terminal tabs. The tabs are arranged vertically in the UI, so up and down feels natural to remember.

4. Navigate between panes within a tab

⌥ ⌘ Left/Right moves between split panes within a single tab. Useful when you have Claude Code running on one side and your dev server on the other.

5. Resize and maximize

⇧ ⌘ Enter toggles the terminal panel to full screen. ⇧ ⌘ = and ⇧ ⌘ - increase and decrease the terminal size.

Once your fingers learn these shortcuts, navigating between multiple terminal sessions becomes second nature. When your workflow is terminal-first with Claude Code, that speed matters.

Upgrade to Angular 20 from Angular 13 - Part 5: Angular 18 with Claude Code

Sat, 14 Mar 2026 02:00:00 GMT

We are back. In Part 4, we upgraded Jira Clone from Angular 16 to 17 using Claude Code. That was the big one: standalone components, new control flow syntax, standalone bootstrap. A lot of code changed, but the Angular CLI schematics did most of the heavy lifting.

Angular 18 is a different kind of upgrade. No new syntax. No big rewrite. Instead, this release is about finishing the cleanup that Angular 17 started. The standalone migration left behind six NgModule wrappers that were kept as lazy-loading entry points. Angular 18 gave us the reason and the tools to finally remove them all.

The other notable change: Quill v1 to v2. Not because Angular 18 requires it, but because ngx-quill 26+ (the only version that supports Angular 18) dropped support for Quill v1. So we had to upgrade both at the same time.

1. The approach

Same pattern as before. I gave Claude the previous blog posts, the implementation plan from Part 4, and the current state of the codebase. It generated a plan with two phases:

Phase 1: Dependency upgrades - the same incremental pattern from Parts 1-4
Phase 2: NgModule cleanup - remove all remaining NgModules, migrate to provideRouter() with standalone route configs

2. Phase 1: Dependency upgrades

Familiar territory by now. Run ng update, then resolve each dependency one at a time, commit after each step.

Package	Before (v17)	After (v18)
`@angular/core`	`^17.3.12`	`^18.2.14`
`@angular/cli`	`^17.3.17`	`^18.2.21`
`@angular-builders/custom-webpack`	`^17.0.2`	`^18.0.0`
`@angular-eslint/*`	`17.5.3`	`18.4.3`
`@angular/cdk`	`^17.3.10`	`^18.2.14`
`ng-zorro-antd`	`^17.4.1`	`^18.2.1`
`@ant-design/icons-angular`	`^17.0.0`	`^18.0.0`
`ngx-quill`	`^24.0.5`	`^26.0.10`
`quill`	`^1.3.7`	`^2.0.3`

TypeScript (~5.4.5) and zone.js (~0.14.10) were already compatible with Angular 18, so no changes needed there.

2.1 The Quill v2 migration

In Part 4, I specifically called out that we stayed on ngx-quill v24 to avoid the Quill v2 migration. That is over now. ngx-quill 26+ is the only version that supports Angular 18, and it requires Quill v2.

The good news: our Quill usage is minimal. Two editor instances (issue description and create issue modal) with a standard toolbar config. No custom modules, no custom formats.

The only concrete change was in angular.json. Quill v2 does not ship quill.min.js - the minified bundle simply does not exist in the v2 distribution. So the scripts entry needed to change:

- "./node_modules/quill/dist/quill.min.js"
+ "./node_modules/quill/dist/quill.js"

The CSS files (quill.core.css and quill.snow.css) kept their paths. The toolbar configuration and <quill-editor> component API were fully compatible. No template or component changes needed.

After all dependency upgrades, npm install ran cleanly without --force. Build passed on the first try.

3. Phase 2: NgModule cleanup

This is the part that made Angular 18 worth writing about.

After the Angular 17 standalone migration, several NgModule files were left behind. They were not doing anything meaningful, they were just wrappers for routing modules, lazy-loaded feature modules, and barrel re-exports.

AppRoutingModule - wrapping RouterModule.forRoot(routes)
ProjectModule - importing standalone components and ng-zorro modules
ProjectRoutingModule - wrapping RouterModule.forChild(routes)
WorkInProgressModule - wrapping a single standalone component
WorkInProgressRoutingModule - wrapping a single route
JiraControlModule - re-exporting standalone components as a barrel

The reason they survived Part 4: Angular’s lazy loading used loadChildren with module references, and the standalone schematics did not convert these automatically.

3.1 Replacing modules with route configs

The fix is straightforward. Instead of wrapping routes in a NgModule with RouterModule.forChild(), export a plain Routes array from a file. Then in the parent route config, use loadChildren to point at that file instead of the old module:

// Before: app-routing.module.ts
{
  path: 'project',
  loadChildren: () => import('./project/project.module').then(m => m.ProjectModule)
}

// After: app.routes.ts
{
  path: 'project',
  loadChildren: () => import('./project/project.routes').then(m => m.PROJECT_ROUTES)
}

The child route file itself becomes a simple export with no NgModule wrapper:

// Before: project-routing.module.ts
@NgModule({
  imports: [RouterModule.forChild(routes)],
  exports: [RouterModule]
})
export class ProjectRoutingModule {}

// After: project.routes.ts
export const PROJECT_ROUTES: Routes = [
  {
    path: '',
    component: ProjectComponent,
    providers: [
      importProvidersFrom(NzIconModule.forChild(NZ_JIRA_ICONS))
    ],
    children: [
      { path: 'board', component: BoardComponent },
      { path: 'settings', component: SettingsComponent },
      { path: `issue/:${ProjectConst.IssueId}`, component: FullIssueDetailComponent },
      { path: '', redirectTo: 'board', pathMatch: 'full' }
    ]
  }
];

The key insight: loadChildren in Angular 18 can resolve either a module or a plain Routes array. No RouterModule.forChild() boilerplate needed. The NzIconModule.forChild(NZ_JIRA_ICONS) is preserved via route-level providers, ensuring the ng-zorro icons are still registered when the project feature loads.

3.2 Replacing AppRoutingModule with provideRouter

In main.ts, the AppRoutingModule inside importProvidersFrom() was replaced with Angular’s provideRouter():

// Before
importProvidersFrom(BrowserModule, ReactiveFormsModule, AppRoutingModule, ...)

// After
provideRouter(appRoutes),
importProvidersFrom(NzIconModule.forRoot([]), AkitaNgRouterStoreModule, QuillModule.forRoot())

While we were at it, we also cleaned up main.ts by removing BrowserModule (automatically included by bootstrapApplication), ReactiveFormsModule (already imported by each standalone component that uses forms), and NzSpinModule (already imported directly in AppComponent).

4. The result

Application compiles, builds, and lints without errors. The lazy chunk names changed from project-project-module to project-project-routes, confirming the module-free routing is working.

5. Source code

https://github.com/trungvose/jira-clone-angular/pull/111

6. The hidden gotcha: service providers

Everything compiled. The build passed. Then I opened the app and hit this:

NullInjectorError: No provider for NzDrawerService!

This is the part that catches you if you are not careful. NgModules do two things: they declare/import components, and they register services. When ProjectModule imported NzDrawerModule, NzModalModule, and NzNotificationModule, those modules registered their services (NzDrawerService, NzModalService, NzNotificationService) in the module’s injector. Standalone components import the component directives directly, but the services still need a provider somewhere.

The fix was to add those modules to the route-level providers:

export const PROJECT_ROUTES: Routes = [
  {
    path: '',
    component: ProjectComponent,
    providers: [
      importProvidersFrom(
        NzIconModule.forChild(NZ_JIRA_ICONS),
        NzDrawerModule,
        NzModalModule,
        NzNotificationModule
      )
    ],
    // ...
  }
];

This is a good reminder that ng build passing does not mean the app works. The compiler cannot catch missing providers. Those are runtime errors. If you are removing NgModules, test the actual features that depend on injected services from those modules. The build will not save you here.

I had already merged the main PR (#111) before catching this, so it went out as a follow-up hotfix (#112). Fortunately I had not yet published this build on Netlify, so no users were affected.

7. What I learned

Angular 18 is the cleanup release. The hard architectural work was done in Angular 17. This release is about removing the leftover wrappers.

The NgModule removal was the most satisfying part. Those six module files were boilerplate that existed only because the lazy loading system used to require them. Replacing them with plain route config arrays made the codebase simpler and easier to understand. No more RouterModule.forChild() boilerplate, no more barrel re-export modules.

The Quill v1 to v2 migration was the biggest risk on paper, but turned out to be a non-issue. For basic toolbar usage, the API is compatible. The only breaking change we hit was a missing file (quill.min.js renamed to quill.js). If your project uses custom Quill modules or formats, your experience would likely be different.

One small thing worth noting: extractCss: true in angular.json is deprecated in Angular 18. The ng update schematic did not remove it automatically, but the build still passed. We removed it manually to stay clean.

8. What’s next

We are at Angular 18. The remaining path is 18 -> 19 -> 20. Angular 19 introduces the new signal-based forms and makes zoneless change detection more accessible. The codebase is now fully standalone with no NgModules, which puts us in a good position for the signal-based future.

See you in Part 6.

Upgrade to Angular 20 from Angular 13 - Part 4: Angular 17 with Claude Code

Thu, 12 Mar 2026 02:00:00 GMT

We are back. In Part 3, we upgraded Jira Clone from Angular 15 to 16 using Claude Code, and the whole thing was mostly just dependency bumps. I mentioned at the end that Angular 17 would be the interesting one. It was.

Angular 17 is not just another version bump. This is the release where standalone components become the default, the new control flow syntax (@if, @for, @switch) replaces structural directives, and there is an entirely new build system available. For the first time in this series, we need actual code changes, not just package.json updates.

1. Approach

Same as Part 3. I gave Claude the previous blog posts and the implementation plan from the Angular 16 upgrade, and asked it to generate a new plan for Angular 17.

The difference this time is that the plan had two phases:

Phase 1: Dependency upgrades - the same proven pattern from Parts 1-3
Phase 2: Code migration - standalone components, standalone bootstrap, and new control flow syntax

Claude produced a plan covering everything from the initial ng update all the way to creating the PR. The full plan is available in the repo.

2. Phase 1: Dependency upgrades

This part was familiar. Same pattern as before:

Run ng update @angular/core@17 @angular/cli@17 --force
Resolve each dependency conflict one at a time
Commit after each step

One nice thing: ng update automatically bumped TypeScript to 5.4.5 and zone.js to 0.14.10 this time, so two tasks from the plan were already done.

The remaining dependencies followed the usual flow:

Package	Before (v16)	After (v17)
`@angular/core`	`^16.2.12`	`^17.3.12`
`@angular/cli`	`^16.2.16`	`^17.3.17`
`typescript`	`~5.1.6`	`~5.4.5`
`zone.js`	`~0.13.3`	`~0.14.10`
`ng-zorro-antd`	`^16.2.2`	`^17.4.1`
`ngx-quill`	`^22.1.1`	`^24.0.5`
`@angular/cdk`	`^16.2.14`	`^17.3.10`
`@angular-eslint/*`	`16.3.1`	`17.5.3`
`@typescript-eslint/*`	`5.11.0`	`6.21.0`

For ngx-quill, it was important to stay on v24.x and not jump to v25+. Version 25 requires Quill v2, which is a completely different API. Version 24 supports Angular 17 while keeping Quill v1. That saved us from a much bigger migration.

After resolving all dependencies, npm install ran cleanly without --force. Build passed on the first try.

3. Phase 2: The real work

This is where it got interesting. Angular 17 provides CLI schematics to automate the three major code migrations:

3.1 Convert to standalone components

npx ng generate @angular/core:standalone --mode convert-to-standalone

This schematic went through all components and directives, added standalone: true to each one, and moved the necessary imports from their parent NgModules into each component’s own imports array.

3.2 Prune NgModules

npx ng generate @angular/core:standalone --mode prune-ng-modules

This removed NgModule classes that were no longer needed. In our case, only SnowModule was fully pruned. The other modules like ProjectModule and WorkInProgressModule were kept because they still serve as entry points for lazy-loaded routes.

There was one issue here. The schematic deleted SnowModule but forgot to add SnowComponent to the imports of AppModule. The build failed with 'j-snow' is not a known element. Quick fix, added the import manually.

3.3 Migrate to standalone bootstrap

npx ng generate @angular/core:standalone --mode standalone-bootstrap

This was the big one. It converted main.ts from:

platformBrowserDynamic().bootstrapModule(AppModule)

to:

bootstrapApplication(AppComponent, {
  providers: [
    importProvidersFrom(BrowserModule, AppRoutingModule, ...),
    provideAnimations(),
    provideHttpClient(withInterceptorsFromDi()),
    // Sentry, Akita, and other providers
  ]
})

And then deleted AppModule entirely. The schematic handled most of it correctly, but missed the import * as Sentry statement that was previously in app.module.ts. Another quick manual fix.

3.4 Migrate control flow syntax

npx ng generate @angular/core:control-flow

This converted all *ngIf and *ngFor directives to the new @if and @for syntax across the template files. For example:

<!-- Before -->
<div *ngIf="isLoading; else content">Loading...</div>

<!-- After -->
@if (isLoading) {
  <div>Loading...</div>
} @else {
  ...
}

The @for syntax requires a track expression, which the schematic handled automatically. No track $index fallbacks needed.

One thing the new control flow exposed: stricter type checking. Two interface classes (IssuePriorityIcon and IssueTypeWithIcon) had their value field typed as string when the methods consuming them expected enum types (IssuePriority and IssueType). The old *ngFor was lenient about this. The new @for was not. Fixed by updating the type definitions to use the correct enum types.

4. ESLint cleanup

The @angular-eslint v17 removed the ng-cli-compat config that the project was using. Replaced it with @angular-eslint/recommended and @typescript-eslint/recommended. Also had to upgrade @typescript-eslint/* from 5.11.0 to 6.21.0 because the old version did not support TypeScript 5.4.

5. Result

Application compiles and serves without errors.

6. Source code

https://github.com/trungvose/jira-clone-angular/pull/110

7. What I learned

The Angular CLI schematics for standalone migration and control flow are surprisingly good. They handled 90% of the work automatically. The remaining 10% were edge cases: a missing import here, a stricter type check there. Nothing that took more than a minute to fix.

The two-phase approach worked well. Phase 1 (dependency upgrades) followed the exact same pattern from the previous three parts. Phase 2 (code migration) was new territory, but the schematics did the heavy lifting.

What surprised me was how much code changed. If I had done this manually, it would have been a full day of tedious find-and-replace work. The schematics turned it into a few commands.

One thing worth noting: the Storybook migration (v6 to v7) was intentionally skipped. Storybook 6.x still works with Angular 17, just with some peer dependency warnings. The v6 to v7 upgrade is a separate, non-trivial migration that deserves its own PR.

8. What’s next

We are at Angular 17. The remaining path is 17 -> 18 -> 19 -> 20. Angular 18 should be relatively smooth since the major architectural changes (standalone, control flow) are already done. The esbuild migration is something we will need to tackle eventually, but that can wait.

See you in Part 5.

Upgrade to Angular 20 from Angular 13 - Part 3: Angular 16 with Claude Code

Sun, 08 Mar 2026 02:00:00 GMT

The task of upgrading Jira Clone to Angular 20 has been sitting on my backlog forever. If you have been following this series, you know the drill. In Part 1 we went from Angular 13 to 14, and in Part 2 we tackled Angular 14 to 15. Each time, the process was mostly the same: run ng update, hit dependency conflicts, resolve them one by one, test, and commit.

It is usually tedious to do those migrations manually. But this time, I tried something different. I used Claude Code to do the whole thing.

1. Idea

I had two detailed blog posts from the previous migrations (Part 1 and Part 2) that documented every step, every error, and every resolution. That is a lot of context. So I thought, what if I just ask Claude to read those posts, understand the pattern, and generate a plan for the Angular 16 upgrade?

I used the superpower workflow to generate a detailed implementation plan.

Claude read through both previous posts, understood the proven pattern (upgrade Angular core first with --force, then resolve each dependency conflict one at a time), and produced a comprehensive plan.

After just a few minutes, the plan was ready. I read through all of it. Looked good.

2. Plan

Here is a summary of the steps Claude generated:

Create a new branch trung/v20-migration-part-3
Run ng update for Angular 16 with --force (same ESLint chicken-and-egg problem as before)
Upgrade TypeScript from ~4.8.4 to ~5.0.4 (Angular 16 requires TS 5.0+)
Upgrade zone.js from ~0.11.4 to ~0.13.0 (significant jump)
Upgrade @angular-builders/custom-webpack to 16.0.0
Upgrade @angular-eslint/* to 16.3.1
Upgrade @angular/cdk to 16.2.14
Upgrade Ant Design packages (ng-zorro-antd to 16.2.2, @ant-design/icons-angular to 16.0.0)
Upgrade ngx-quill from 16.1.2 to 22.1.1 (this was the biggest risk, major version jump)
Upgrade @ngneat/content-loader to 7.0.0
Verify clean npm install
Verify ng serve
Verify ng build
Push and create PR

Claude also identified the key changes in Angular 16 (Signals in developer preview, TypeScript 5.0 support, zone.js bump) and listed potential gotchas, including the ngx-quill major version jump from 16 to 22 since ngx-quill uses its own versioning that does not follow Angular’s.

The full plan is available in the repo.

3. Kicking off the process

Once I reviewed the plan, I kicked off the execution. Claude worked through each task sequentially, following the exact same pattern we established in Parts 1 and 2:

Update the version in package.json
Run npm install --force (since not all dependencies are resolved yet)
Verify with npm view <package>@<version> peerDependencies --json
Commit the changes
Move to the next dependency

The whole process ran for about 20 minutes. I mostly just watched and approved the commands. There was one moment where Claude needed to resolve an unexpected issue with ngx-quill’s API changes, but it handled that by searching the codebase for quill usage and checking compatibility.

4. Result

After all 14 tasks completed, I ran npm start and things worked as expected. The application compiled and served without errors. Board view, issue detail, drag and drop, everything functioned correctly.

Here is the dependency version map for reference:

Package	Before (v15)	After (v16)
`@angular/core`	`^15.2.10`	`^16.2.12`
`@angular/cli`	`^15.2.11`	`^16.2.14`
`typescript`	`~4.8.4`	`~5.0.4`
`zone.js`	`~0.11.4`	`~0.13.0`
`ng-zorro-antd`	`^15.0.0`	`^16.2.2`
`ngx-quill`	`^16.1.2`	`^22.1.1`
`@angular/cdk`	`^15.2.9`	`^16.2.14`

No code changes were needed beyond the dependency upgrades. Angular 16 introduces Signals in developer preview, but there is no migration needed yet. Standalone components and control flow syntax migration are deferred to the Angular 17 step.

5. Source code

https://github.com/trungvose/jira-clone-angular/pull/109

6. What I learned

Doing the first two migrations manually and documenting them thoroughly turned out to be the best investment. Those blog posts became the training data for Claude to understand the exact pattern and replicate it. The third migration took about 30 minutes total: 10 minutes of prompting and reviewing the plan, then a single execution run by Claude. What used to be an hour of hands-on work became mostly watching and approving.

The key is that the pattern was well-established:

Use --force for the initial ng update to bypass the ESLint peer dependency conflict
Resolve each dependency conflict one at a time using npm view to check versions and peer dependencies
Commit after each successful step so you can always roll back
Test with both ng serve and ng build since production builds are stricter

If you have repetitive tasks with a clear pattern, documenting the first few iterations thoroughly and then handing it off to AI is a solid approach.

7. What’s next

We are at Angular 16 now. The remaining path is 16 -> 17 -> 18 -> 19 -> 20. Angular 17 is going to be the interesting one since that is where standalone components and the new control flow syntax (@if, @for, @switch) become the default. That will require actual code changes, not just dependency bumps.

See you in Part 4.

I added synced lyrics to Angular Spotify without writing a single line of code

Sun, 01 Mar 2026 02:30:00 GMT

I have been lately catching up with AI tooling. When exploring AI tooling for work at Ascenda, using Figma MCP to go from design to code was impressive and really opened my eyes on what’s possible. So today, I wanted to try something bigger: implement a feature that was requested years ago for Angular Spotify, synced lyrics display.

With AI-assisted coding, it is becoming so easy to implement something that would have taken me days of research and wiring up. I did the whole thing purely by prompting with Claude Code, and I want to share the step-by-step process.

The feature

Synced lyrics that scroll along with the music, just like you see in the official Spotify app. Click a line to jump to that part of the song. When synced lyrics aren’t available, it falls back to plain lyrics with manual scroll.

I didn’t write any code myself at first. There were two prompts that I sent to Claude:

/init
A prompt starting with Help me to plan this feature to trigger the Superpower workflow that goes through brainstorming, writing plans, and subagent-driven development

Source code

Here is my PR for reference:

https://github.com/trungvose/angular-spotify

Step 1: init command

/init creates a CLAUDE.md file with a high-level summary of the project. I learned that the output by Claude contains enough good information about the project to get started.

However, you should also include one of the most important sections: how to build and verify. After each change, Claude can run those steps to verify things are working.

For example, Claude will by default figure out it needs to run lint/test. But maybe what is more important in your particular project is to run yarn start and see if there are any errors at runtime.

This is crucial for the agent to keep running and correcting itself without needing you in the loop as much.

Step 2: Superpower workflow

2.1 Brainstorm

I sent a prompt to trigger the Superpower workflow that includes several different skills to help me go through brainstorming, design, and implementation:

Help me to plan this feature.

I want to connect to Musixmatch, fetch the lyrics and show it on the screen. As you rewind the song, the lyrics will move to the right place.

Also, if you click into a lyric, it will jump to the right position of the song.

The first line Help me to plan this feature automatically triggers the brainstorm workflow. Claude does research first, then asks me a couple of follow-up questions. The questions it asked were pretty accurate, see below.

2.2 Design

From the screenshot below, you can see there are a few steps in the brainstorming phase:

Explore project context for the lyrics feature
Ask clarifying questions
Propose approaches with trade-offs
Present design and get approval

At step 3, based on all my clarifications, Claude suggested a couple of approaches and I could choose which one I wanted. I chose option A which was also the recommended option.

Next, it produced a detailed design document in markdown covering:

Musixmatch API with plain lyrics (just text lines) and synced/timestamped lyrics
Library structure following the existing Nx conventions
Data models and store design
UI component breakdown
The full data flow from playback state to active lyric line

This design phase was crucial. Instead of jumping straight into code, I got a clear blueprint that I could review and adjust before writing a single line.

If I approve the design, it goes ahead and creates a very detailed implementation plan, also in markdown.

Here is the design doc
Here is the commit where you can see the implementation plan is really long (+1k lines), covering how to generate new libraries, how to structure code, etc. But eventually after a lot of follow-up prompts during implementation, the plan got outdated very quickly. So I deleted it from the final PR.

Step 3: Implementation

After having the implementation plan, I let Claude run and generate all of the code. As you can see from the following commit, the Musixmatch service was being implemented and I just needed to provide an API key at the end to test the app.

However, when I went to the website to log in and get the API key, I realised they had deleted my account. The whole developer portal seemed to have changed since I created an account years ago.

So I asked Claude to do a quick research and find an alternative and it found LRCLIB, a free, open lyrics API that requires no API key. That ended up being what we used in the final PR.

Step 4: Follow-up and debugging

Once the code was generated, I ran the dev server and manually verified how the feature worked. There is a lot of opportunity here to use something like Chrome MCP so Claude can run and verify the feature by itself. But at this stage, the workflow was mainly: I spot a bug or unexpected behavior, prompt Claude about it, and Claude fixes it. A few worth mentioning:

CORS handling. The auth interceptor was attaching the Spotify Authorization header to LRCLIB requests, which LRCLIB’s CORS policy rejects. Claude identified both interceptors (auth + unauthorized) that needed to skip lrclib.net requests.

Position drift. The stateTimestamp needed to be captured in PlaybackService at the moment the SDK fires player_state_changed, before the async getVolume() call. Otherwise there was a 3-4 second delay where the music runs ahead and the lyrics catch up a few seconds later. After a couple of prompts and testing, it was fixed!

2.3 Optional: `--dangerously-skip-permissions`

Claude may ask for many permissions while reading from Figma and your codebase.

I’ve been running with --dangerously-skip-permissions, which means Claude won’t pause to ask before executing certain commands.

So far, I haven’t hit issues, and it keeps the session moving. Without it, the work is interuppted: you step away for a moment, come back, and discover it stopped after 30 seconds to ask a question.

However, --dangerously-skip-permissions is still a security concern, so we should consider configuring setting.json to whitelist commands that we often use.

What I learned

Design first, code second. Having Claude produce a design document before any code was the most valuable step.
AI-assisted coding shines for pattern-heavy work. The lyrics feature mirrors the visualizer’s architecture. Claude recognized the patterns in my codebase and replicated them consistently across all the new files.
You still need to review. I’m not blindly accepting everything. But the feedback loop is much tighter. Instead of writing code and debugging, I’m reviewing code and prompting for adjustments.
Tests matter more than ever. The biggest gap in my Spotify codebase is the lack of unit tests. I still had to manually test every change. If I had a proper unit test suite, or even better e2e tests, Claude could handle a lot of that verification and make the whole process even smoother. That’s something I want to invest in next.
Features that sat in the backlog for years took an afternoon. That’s the real takeaway.

Google TypeScript Style Guide

Sun, 21 Dec 2025 07:00:00 GMT

Just realised my last blog post was in July 2025. Since then, I have attended Google I/O Connect 2025 Shanghai in August, spoke at Øredev 2025 in Sweden in November, and then JSConfJP 2025 just a few days after coming back from Sweden. It has been a busy second half of the year.

In between all the travel and talks, I finally had some quiet time to sit down and read the Google TypeScript Style Guide and picked up quite a few solid lessons along the way. Some points were already familiar, but others helped clear up long standing questions, for example whether iterating objects with for of and Object.keys is actually the right approach, or when to prefer interfaces over type literal aliases. Below are the tips I found most useful. Sharing them here in case they help you as well.

4.3.2 Iterating objects

Iterating objects with for (... in ...) is error prone. It will include enumerable properties from the prototype chain.

Do not use unfiltered for (... in ...) statements:

// ❌ DO NOT USE
for (const x in someObj) {
  // x could come from some parent prototype!
}

Either filter values explicitly with an if statement, or use for (... of Object.keys(...)).

// ✅ USE
for (const x in someObj) {
  if (!someObj.hasOwnProperty(x)) continue;
  // now x was definitely defined on someObj
}
for (const x of Object.keys(someObj)) { // note: for _of_!
  // now x was definitely defined on someObj
}
for (const [key, value] of Object.entries(someObj)) { // note: for _of_!
  // now key was definitely defined on someObj
}

4.4.5 Class members

No #private fields

Do not use private fields (also known as private identifiers):

// ❌ DO NOT USE
class Clazz {
  #ident = 1;
}

Instead, use TypeScript’s visibility annotations:

// ✅ USE
class Clazz {
  private ident = 1;
}

Why?

Private identifiers cause substantial emit size and performance regressions when down-leveled by TypeScript, and are unsupported before ES2015. They can only be downleveled to ES2015, not lower. At the same time, they do not offer substantial benefits when static type checking is used to enforce visibility.

4.5.2 Prefer function declarations for named functions

Prefer function declarations over arrow functions or function expressions when defining named functions.

// Prefer this: function declarations
function foo() {
  return 42;
}

// Over arrow functions
const foo = () => 42;

Arrow functions may be used, for example, when an explicit type annotation is required.

interface SearchFunction {
  (source: string, subString: string): boolean;
}

const fooSearch: SearchFunction = (source, subString) => { ... }

4.5.5 Arrow function bodies

Use arrow functions with concise bodies (i.e. expressions) or block bodies as appropriate.

// Top level functions use function declarations.
function someFunction() {
  // Block bodies are fine:
  const receipts = books.map((b: Book) => {
    const receipt = payMoney(b.price);
    recordTransaction(receipt);
    return receipt;
  });

  // Concise bodies are fine, too, if the return value is used:
  const longThings = myValues.filter(v => v.length > 1000).map(v => String(v));

  function payMoney(amount: number) {
    // function declarations are fine, but must not access `this`.
  }

  // Nested arrow functions may be assigned to a const.
  const computeTax = (amount: number) => amount * 0.12;
}

Only use a concise body if the return value of the function is actually used. The block body makes sure the return type is void then and prevents potential side effects.

// ❌ BAD: use a block body if the return value of the function is not used.
myPromise.then(v => console.log(v));

// ❌ BAD: this typechecks, but the return value still leaks.
let f: () => void;
f = () => 1;

// ✅ GOOD: return value is unused, use a block body.
myPromise.then(v => {
  console.log(v);
});

// ✅ GOOD: code may use blocks for readability.
const transformed = [1, 2, 3].map(v => {
  const intermediate = someComplicatedExpr(v);
  const more = acrossManyLines(intermediate);
  return worthWrapping(more);
});

// ✅ GOOD: explicit `void` ensures no leaked return value
myPromise.then(v => void console.log(v));

Tip: The void operator can be used to ensure an arrow function with an expression body returns undefined when the result is unused.

4.5.7 Prefer passing arrow functions as callbacks

Callbacks can be invoked with unexpected arguments that can pass a type check but still result in logical errors.

Avoid passing a named callback to a higher-order function, unless you are sure of the stability of both functions’ call signatures. Beware, in particular, of less-commonly-used optional parameters.

// ❌ BAD: Arguments are not explicitly passed, leading to unintended behavior
// when the optional `radix` argument gets the array indices 0, 1, and 2.
const numbers = ['11', '5', '10'].map(parseInt);
// > [11, NaN, 2];

Instead, prefer passing an arrow-function that explicitly forwards parameters to the named callback.

// ✅ GOOD: Arguments are explicitly passed to the callback
const numbers = ['11', '5', '3'].map((n) => parseInt(n));
// > [11, 5, 3]

// ✅ GOOD: Function is locally defined and is designed to be used as a callback
function dayFilter(element: string|null|undefined) {
  return element != null && element.endsWith('day');
}

const days = ['tuesday', undefined, 'juice', 'wednesday'].filter(dayFilter);

4.5.10 Parameter initializers

Optional function parameters may be given a default initializer to use when the argument is omitted. Initializers must not have any observable side effects. Initializers should be kept as simple as possible.

function process(name: string, extraContext: string[] = []) {}
function activate(index = 0) {}

// ❌ BAD: side effect of incrementing the counter
let globalCounter = 0;
function newId(index = globalCounter++) {}

// ❌ BAD: exposes shared mutable state, which can introduce unintended coupling
// between function calls
class Foo {
  private readonly defaultPaths: string[];
  frobnicate(paths = defaultPaths) {}
}

Use default parameters sparingly. Prefer destructuring to create readable APIs when there are more than a small handful of optional parameters that do not have a natural order.

4.8.1 String literals

Use single quotes

Ordinary string literals are delimited with single quotes ('), rather than double quotes (").

Tip: if a string contains a single quote character, consider using a template string to avoid having to escape the quote.

No line continuations

Do not use line continuations (that is, ending a line inside a string literal with a backslash) in either ordinary or template string literals. Even though ES5 allows this, it can lead to tricky errors if any trailing whitespace comes after the slash, and is less obvious to readers.

// ❌ Disallowed
const LONG_STRING = 'This is a very very very very very very very long string. \
    It inadvertently contains long stretches of spaces due to how the \
    continued lines are indented.';

// ✅ Instead, write
const LONG_STRING = 'This is a very very very very very very long string. ' +
    'It does not contain long stretches of spaces because it uses ' +
    'concatenated strings.';

const SINGLE_STRING =
    'http://it.is.also/acceptable_to_use_a_single_long_string_when_breaking_would_hinder_search_discoverability';

Template literals

Use template literals (delimited with ```) over complex string concatenation, particularly if multiple string literals are involved. Template literals may span multiple lines.

If a template literal spans multiple lines, it does not need to follow the indentation of the enclosing block, though it may if the added whitespace does not matter.

Example:

function arithmetic(a: number, b: number) {
  return `Here is a table of arithmetic operations:
${a} + ${b} = ${a + b}
${a} - ${b} = ${a - b}
${a} * ${b} = ${a * b}
${a} / ${b} = ${a / b}`;
}

4.8.3 Type coercion

TypeScript code may use the String() and Boolean() (note: no new!) functions, string template literals, or !! to coerce types.

const bool = Boolean(false);
const str = String(aNumber);
const bool2 = !!str;
const str2 = `result: ${bool2}`;

Values of enum types (including unions of enum types and other types) must not be converted to booleans with Boolean() or !!, and must instead be compared explicitly with comparison operators.


enum SupportLevel {
  NONE,
  BASIC,
  ADVANCED,
}

const level: SupportLevel = ...;
// ❌ BAD
let enabled = Boolean(level);

const maybeLevel: SupportLevel|undefined = ...;
enabled = !!maybeLevel;

---

const level: SupportLevel = ...;
// ✅ GOOD
let enabled = level !== SupportLevel.NONE;

const maybeLevel: SupportLevel|undefined = ...;
enabled = level !== undefined && level !== SupportLevel.NONE;

Code must use Number() to parse numeric values, and must check its return for NaN values explicitly, unless failing to parse is impossible from context.

// ✅ GOOD
const aNumber = Number('123');
if (!isFinite(aNumber)) throw new Error(...);

Code also must not use parseInt or parseFloat to parse numbers, except for non-base-10 strings (see below). Both of those functions ignore trailing characters in the string, which can shadow error conditions (e.g. parsing 12 dwarves as 12).

// ❌ BAD
const n = parseInt(someString, 10);  // Error prone,
const f = parseFloat(someString);    // regardless of passing a radix.

Code that requires parsing with a radix must check that its input contains only appropriate digits for that radix before calling into parseInt;

// ✅ GOOD
if (!/^[a-fA-F0-9]+$/.test(someString)) throw new Error(...);
// Needed to parse hexadecimal.
// tslint:disable-next-line:ban
const n = parseInt(someString, 16);  // Only allowed for radix != 10

Use Number() followed by Math.floor or Math.trunc (where available) to parse integer numbers:

// ✅ GOOD
let f = Number(someString);
if (isNaN(f)) handleError();
f = Math.floor(f);

Implicit coercion

Do not use explicit boolean coercions in conditional clauses that have implicit boolean coercion. Those are the conditions in an if, for and while statements.

// ✅ Prefer: implicit coercion
const foo: MyInterface|null = ...;
if (foo) {...}
while (foo) {...}

// ❌ Instead of explicit
const foo: MyInterface|null = ...;
if (!!foo) {...}
while (!!foo) {...}

Other types of values may be either implicitly coerced to booleans or compared explicitly with comparison operators:

// Explicitly comparing > 0 is OK:
if (arr.length > 0) {...}
// so is relying on boolean coercion:
if (arr.length) {...}

4.9.1 Control flow statements and blocks

Control flow statements (if, else, for, do, while, etc) always use braced blocks for the containing code, even if the body contains only a single statement. The first statement of a non-empty block must begin on its own line.

// ✅ GOOD
for (let i = 0; i < x; i++) {
  doSomethingWith(i);
}

if (x) {
  doSomethingWithALongMethodNameThatForcesANewLine(x);
}

// ❌ BAD
if (x)
  doSomethingWithALongMethodNameThatForcesANewLine(x);

for (let i = 0; i < x; i++) doSomethingWith(i);

Exception: if statements fitting on one line may elide the block.

if (x) x.doFoo();

Assignment in control statements

Prefer to avoid assignment of variables inside control statements. Assignment can be easily mistaken for equality checks inside control statements.

// ❌ BAD
if (x = someFunction()) {
  // Assignment easily mistaken with equality check
  // ...
}

// ✅ GOOD
x = someFunction();
if (x) {
  // ...
}

In cases where assignment inside the control statement is preferred, enclose the assignment in additional parenthesis to indicate it is intentional.

while ((x = someFunction())) {
  // Double parenthesis shows assignment is intentional
  // ...
}

Iterating containers

Prefer for (... of someArr) to iterate over arrays. Array.prototype.forEach and vanilla for loops are also allowed:

// ✅ GOOD
for (const x of someArr) {
  // x is a value of someArr.
}

for (let i = 0; i < someArr.length; i++) {
  // Explicitly count if the index is needed, otherwise use the for/of form.
  const x = someArr[i];
  // ...
}
for (const [i, x] of someArr.entries()) {
  // Alternative version of the above.
}

for-in loops may only be used on dict-style objects (see below for more info). Do not use for (... in ...) to iterate over arrays as it will counterintuitively give the array’s indices (as strings!), not values:

for (const x in someArray) {
  // x is the index!
}

Object.prototype.hasOwnProperty should be used in for-in loops to exclude unwanted prototype properties. Prefer for-of with Object.keys, Object.values, or Object.entries over for-in when possible.

// ✅ GOOD
for (const key in obj) {
  if (!obj.hasOwnProperty(key)) continue;
  doWork(key, obj[key]);
}
for (const key of Object.keys(obj)) {
  doWork(key, obj[key]);
}
for (const value of Object.values(obj)) {
  doWorkValOnly(value);
}
for (const [key, value] of Object.entries(obj)) {
  doWork(key, value);
}

4.9.3 Exception handling

Exceptions are an important part of the language and should be used whenever exceptional cases occur.

Custom exceptions provide a great way to convey additional error information from functions. They should be defined and used wherever the native Error type is insufficient.

Prefer throwing exceptions over ad-hoc error-handling approaches (such as passing an error container reference type, or returning an object with an error property).

Instantiate errors using `new`

Always use new Error() when instantiating exceptions, instead of just calling Error(). Both forms create a new Error instance, but using new is more consistent with how other objects are instantiated.

// ✅ Prefer new Error
throw new Error('Foo is not a valid bar.');

// ❌ Instead of just Error
throw Error('Foo is not a valid bar.');

Only throw errors

JavaScript (and thus TypeScript) allow throwing or rejecting a Promise with arbitrary values. However if the thrown or rejected value is not an Error, it does not populate stack trace information, making debugging hard. This treatment extends to Promise rejection values as Promise.reject(obj) is equivalent to throw obj; in async functions.

// ❌ bad: does not get a stack trace.
throw 'oh noes!';
// For promises
new Promise((resolve, reject) => void reject('oh noes!'));
Promise.reject();
Promise.reject('oh noes!');

Instead, only throw (subclasses of) Error:

// ✅ Throw only Errors
throw new Error('oh noes!');
// ... or subtypes of Error.
class MyError extends Error {}
throw new MyError('my oh noes!');
// For promises
new Promise((resolve) => resolve()); // No reject is OK.
new Promise((resolve, reject) => void reject(new Error('oh noes!')));
Promise.reject(new Error('oh noes!'));

Catching and rethrowing

When catching errors, code should assume that all thrown errors are instances of Error.

function assertIsError(e: unknown): asserts e is Error {
  if (!(e instanceof Error)) throw new Error("e is not an Error");
}

try {
  doSomething();
} catch (e: unknown) {
  // All thrown errors must be Error subtypes. Do not handle
  // other possible values unless you know they are thrown.
  assertIsError(e);
  displayError(e.message);
  // or rethrow:
  throw e;
}

Exception handlers must not defensively handle non-Error types unless the called API is conclusively known to throw non-Errors in violation of the above rule. In that case, a comment should be included to specifically identify where the non-Errors originate.

try {
  badApiThrowingStrings();
} catch (e: unknown) {
  // Note: bad API throws strings instead of errors.
  if (typeof e === 'string') { ... }
}

Why?

Avoid overly defensive programming. Repeating the same defenses against a problem that will not exist in most code leads to boiler-plate code that is not useful.

4.9.4 Switch statements

All switch statements must contain a default statement group, even if it contains no code. The default statement group must be last.

switch (x) {
  case Y:
    doSomethingElse();
    break;
  default:
    // nothing to do.
}

Within a switch block, each statement group either terminates abruptly with a break, a return statement, or by throwing an exception. Non-empty statement groups (case ...) must not fall through (enforced by the compiler):

switch (x) {
  case X:
    doSomething();
    // fall through - not allowed!
  case Y:
    // ...
}

Empty statement groups are allowed to fall through:

switch (x) {
  case X:
  case Y:
    doSomething();
    break;
  default: // nothing to do.
}

4.9.5 Equality checks

Always use triple equals (===) and not equals (!==). The double equality operators cause error prone type coercions that are hard to understand and slower to implement for JavaScript Virtual Machines. See also the JavaScript equality table.

// ❌ BAD
if (foo == 'bar' || baz != bam) {
  // Hard to understand behaviour due to type coercion.
}

// ✅ GOOD
if (foo === 'bar' || baz !== bam) {
  // All good here.
}

Exception: Comparisons to the literal null value may use the == and != operators to cover both null and undefined values.

if (foo == null) {
  // Will trigger when foo is null or undefined.
}

4.9.6 Type and non-nullability assertions

Type assertions (x as SomeType) and non-nullability assertions (y!) are unsafe. Both only silence the TypeScript compiler, but do not insert any runtime checks to match these assertions, so they can cause your program to crash at runtime.

Because of this, you should not use type and non-nullability assertions without an obvious or explicit reason for doing so.

Instead of the following:

// ❌ BAD
(x as Foo).foo();

y!.bar();

When you want to assert a type or non-nullability the best answer is to explicitly write a runtime check that performs that check.

// // ✅ GOOD
// assuming Foo is a class.
if (x instanceof Foo) {
  x.foo();
}

if (y) {
  y.bar();
}

Sometimes due to some local property of your code you can be sure that the assertion form is safe. In those situations, you should add clarification to explain why you are ok with the unsafe behavior:

// x is a Foo, because ...
(x as Foo).foo();

// y cannot be null, because ...
y!.bar();

If the reasoning behind a type or non-nullability assertion is obvious, the comments may not be necessary. For example, generated proto code is always nullable, but perhaps it is well-known in the context of the code that certain fields are always provided by the backend. Use your judgement.

Type assertion syntax

Type assertions must use the as syntax (as opposed to the angle brackets syntax). This enforces parentheses around the assertion when accessing a member.

// ❌ BAD
const x = (<Foo>z).length;
const y = <Foo>z.length;

// ✅ GOOD
// z must be Foo because ...
const x = (z as Foo).length;

Double assertions

From the TypeScript handbook, TypeScript only allows type assertions which convert to a more specific or less specific version of a type. Adding a type assertion (x as Foo) which does not meet this criteria will give the error: Conversion of type 'X' to type 'Y' may be a mistake because neither type sufficiently overlaps with the other.

This rule prevents “impossible” coercions like:

const x = "hello" as number;
// Conversion of type 'string' to type 'number' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the  expression to 'unknown' first.

If you are sure an assertion is safe, you can perform a double assertion. This involves casting through unknown since it is less specific than all types.

// x is a Foo here, because...
(x as unknown as Foo).fooMethod();

Use unknown (instead of any or {}) as the intermediate type.

Type assertions and object literals

Use type annotations (: Foo) instead of type assertions (as Foo) to specify the type of an object literal. This allows detecting refactoring bugs when the fields of an interface change over time.

// ❌ Do not use as
interface Foo {
  bar: number;
  baz?: string;  // was "bam", but later renamed to "baz".
}

const foo = {
  bar: 123,
  bam: 'abc',  // no error!
} as Foo;

function func() {
  return {
    bar: 123,
    bam: 'abc',  // no error!
  } as Foo;
}

// ✅ Use the type notation
interface Foo {
  bar: number;
  baz?: string;
}

const foo: Foo = {
  bar: 123,
  bam: 'abc',  // complains about "bam" not being defined on Foo.
};

function func(): Foo {
  return {
    bar: 123,
    bam: 'abc',   // complains about "bam" not being defined on Foo.
  };
}

5.1.1 Naming style

TypeScript expresses information in types, so names should not be decorated with information that is included in the type. (See also Testing Blog for more about what not to include.)

Some concrete examples of this rule:

Do not use trailing or leading underscores for private properties or methods.
Do not use the opt_ prefix for optional parameters.
- For accessors, see accessor rules below.
Do not mark interfaces specially (~~IMyInterface~~ or ~~MyFooInterface~~) unless it’s idiomatic in its environment. When introducing an interface for a class, give it a name that expresses why the interface exists in the first place (e.g. class TodoItem and interface TodoItemStorage if the interface expresses the format used for storage/serialization in JSON).
Suffixing Observables with $ is a common external convention and can help resolve confusion regarding observable values vs concrete values. Judgement on whether this is a useful convention is left up to individual teams, but should be consistent within projects.

5.1.2 Descriptive names

Names must be descriptive and clear to a new reader. Do not use abbreviations that are ambiguous or unfamiliar to readers outside your project, and do not abbreviate by deleting letters within a word.

Exception: Variables that are in scope for 10 lines or fewer, including arguments that are not part of an exported API, may use short (e.g. single letter) variable names.

// ✅ Good identifiers:
errorCount          // No abbreviation.
dnsConnectionIndex  // Most people know what "DNS" stands for.
referrerUrl         // Ditto for "URL".
customerId          // "Id" is both ubiquitous and unlikely to be misunderstood.

// Disallowed identifiers:
n                   // Meaningless.
nErr                // Ambiguous abbreviation.
nCompConns          // Ambiguous abbreviation.
wgcConnections      // Only your group knows what this stands for.
pcReader            // Lots of things can be abbreviated "pc".
cstmrId             // Deletes internal letters.
kSecondsPerDay      // Do not use Hungarian notation.
customerID          // Incorrect camelcase of "ID".

5.1.3 Camel case

Treat abbreviations like acronyms in names as whole words, i.e. use loadHttpUrl, not ~~loadHTTPURL~~, unless required by a platform name (e.g. XMLHttpRequest).

5.2 Rules by identifier type

Most identifier names should follow the casing in the table below, based on the identifier’s type.

Style	Category
`UpperCamelCase`	class / interface / type / enum / decorator / type parameters / component functions in TSX / JSXElement type parameter
`lowerCamelCase`	variable / parameter / function / method / property / module alias
`CONSTANT_CASE`	global constant values, including enum values. See Constants below.
`#ident`	private identifiers are never used.

5.2.3 `_` prefix/suffix

Identifiers must not use _ as a prefix or suffix.

This also means that _ must not be used as an identifier by itself (e.g. to indicate a parameter is unused).

Tip: If you only need some of the elements from an array (or TypeScript tuple), you can insert extra commas in a destructuring statement to ignore in-between elements:
const [a, , b] = [1, 5, 10];  // a <- 1, b <- 10

5.2.5 Constants

Immutable: CONSTANT_CASE indicates that a value is intended to not be changed, and may be used for values that can technically be modified (i.e. values that are not deeply frozen) to indicate to users that they must not be modified.

const UNIT_SUFFIXES = {
  'milliseconds': 'ms',
  'seconds': 's',
};
// Even though per the rules of JavaScript UNIT_SUFFIXES is
// mutable, the uppercase shows users to not modify it.

A constant can also be a static readonly property of a class.

class Foo {
  private static readonly MY_SPECIAL_NUMBER = 5;

  bar() {
    return 2 * Foo.MY_SPECIAL_NUMBER;
  }
}

Global: Only symbols declared on the module level, static fields of module level classes, and values of module level enums, may use CONST_CASE. If a value can be instantiated more than once over the lifetime of the program (e.g. a local variable declared within a function, or a static field on a class nested in a function) then it must use lowerCamelCase.

6.2. Undefined and null

TypeScript supports undefined and null types. Nullable types can be constructed as a union type (string|null); similarly with undefined. There is no special syntax for unions of undefined and null.

TypeScript code can use either undefined or null to denote absence of a value, there is no general guidance to prefer one over the other. Many JavaScript APIs use undefined (e.g. Map.get), while many DOM and Google APIs use null (e.g. Element.getAttribute), so the appropriate absent value depends on the context.

6.2.1 Nullable/undefined type aliases

Type aliases must not include |null or |undefined in a union type. Nullable aliases typically indicate that null values are being passed around through too many layers of an application, and this clouds the source of the original issue that resulted in null. They also make it unclear when specific values on a class or interface might be absent.

Instead, code must only add |null or |undefined when the alias is actually used. Code should deal with null values close to where they arise, using the above techniques.

// ❌ Bad
type CoffeeResponse = Latte|Americano|undefined;

class CoffeeService {
  getLatte(): CoffeeResponse { ... };
}

// ✅ Better
type CoffeeResponse = Latte|Americano;

class CoffeeService {
  getLatte(): CoffeeResponse|undefined { ... };
}

6.2.2 Prefer optional over `|undefined`

In addition, TypeScript supports a special construct for optional parameters and fields, using ?:

interface CoffeeOrder {
  sugarCubes: number;
  milk?: Whole|LowFat|HalfHalf;
}

function pourCoffee(volume?: Milliliter) { ... }

Optional parameters implicitly include |undefined in their type. However, they are different in that they can be left out when constructing a value or calling a method. For example, {sugarCubes: 1} is a valid CoffeeOrder because milk is optional.

Use optional fields (on interfaces or classes) and parameters rather than a |undefined type.

For classes preferably avoid this pattern altogether and initialize as many fields as possible.

class MyClass {
  field = '';
}

6.4 Prefer interfaces over type literal aliases

TypeScript supports type aliases for naming a type expression. This can be used to name primitives, unions, tuples, and any other types.

However, when declaring types for objects, use interfaces instead of a type alias for the object literal expression.

// ✅ Prefer interface
interface User {
  firstName: string;
  lastName: string;
}

// ❌ Over type
type User = {
  firstName: string,
  lastName: string,
}

Why?

These forms are nearly equivalent, so under the principle of just choosing one out of two forms to prevent variation, we should choose one. Additionally, there are also interesting technical reasons to prefer interface. That page quotes the TypeScript team lead: Honestly, my take is that it should really just be interfaces for anything that they can model. There is no benefit to type aliases when there are so many issues around display/perf.

6.7 Mapped and conditional types

TypeScript’s mapped types and conditional types allow specifying new types based on other types. TypeScript’s standard library includes several type operators based on these (Record, Partial, Readonly etc).

These type system features allow succinctly specifying types and constructing powerful yet type safe abstractions. They come with a number of drawbacks though:

Compared to explicitly specifying properties and type relations (e.g. using interfaces and extension, see below for an example), type operators require the reader to mentally evaluate the type expression. This can make programs substantially harder to read, in particular combined with type inference and expressions crossing file boundaries.
Mapped & conditional types’ evaluation model, in particular when combined with type inference, is underspecified, not always well understood, and often subject to change in TypeScript compiler versions. Code can compile or seem to give the right results. This increases future support cost of code using type operators.

accidentally
Mapped & conditional types are most powerful when deriving types from complex and/or inferred types. On the flip side, this is also when they are most prone to create hard to understand and maintain programs.
Some language tooling does not work well with these type system features. E.g. your IDE’s find references (and thus rename property refactoring) will not find properties in a Pick<T, Keys> type, and Code Search won’t hyperlink them.

The style recommendation is:

Always use the simplest type construct that can possibly express your code.
A little bit of repetition or verbosity is often much cheaper than the long term cost of complex type expressions.
Mapped & conditional types may be used, subject to these considerations.

For example, TypeScript’s builtin Pick<T, Keys> type allows creating a new type by subsetting another type T, but simple interface extension can often be easier to understand.

interface User {
  shoeSize: number;
  favoriteIcecream: string;
  favoriteChocolate: string;
}

// ❌ FoodPreferences has favoriteIcecream and favoriteChocolate, but not shoeSize.
type FoodPreferences = Pick<User, 'favoriteIcecream'|'favoriteChocolate'>;

This is equivalent to spelling out the properties on FoodPreferences:

// ✅ GOOD
interface FoodPreferences {
  favoriteIcecream: string;
  favoriteChocolate: string;
}

To reduce duplication, User could extend FoodPreferences, or (possibly better) nest a field for food preferences:

interface FoodPreferences { /* as above */ }
interface User extends FoodPreferences {
  shoeSize: number;
  // also includes the preferences.
}

Using interfaces here makes the grouping of properties explicit, improves IDE support, allows better optimization, and arguably makes the code easier to understand.

Typescript types vs interface

Thu, 18 Dec 2025 07:00:00 GMT

TL;DR

Prefer interface for public object shapes, APIs, and models meant to be extended
- Interface supports declaration merging and open extension
- Interface + extends is preferred over type + intersections for better performance and clearer errors
Use type when you need unions, especially discriminated unions
- Type aliases are closed once defined and cannot be re-opened
Both type and interface exist only in type space and are erased at runtime

Different between type alias and interface

Read the original from TypeScript handbook

Type aliases and interfaces are very similar, and in many cases you can choose between them freely. Almost all features of an interface are available in type, the key distinction is that a type cannot be re-opened to add new properties vs an interface which is always extendable.

Interface

Extending an interface

interface Animal {
  name: string;
}
interface Bear extends Animal {
  honey: boolean;
}
const bear = getBear();
bear.name;
bear.honey;

Adding new fields to an existing interface (declaration merging)

interface Window {
  title: string;
}
interface Window {
  ts: TypeScriptAPI;
}
const src = 'const a = "Hello World"';
window.ts.transpileModule(src, {});

Types

Extending a type via intersections

type Animal = {
  name: string;
}
type Bear = Animal & { 
  honey: boolean;
}
const bear = getBear();
bear.name;
bear.honey;

A type cannot be changed after being created

type Window = {
  title: string;
}
type Window = {
  ts: TypeScriptAPI;
} // Error: Duplicate identifier 'Window'.

But type can do union, especially discriminated union

type NetworkLoadingState = {
  state: "loading";
};
type NetworkFailedState = {
  state: "failed";
  code: number;
};
type NetworkSuccessState = {
  state: "success";
  response: {
    title: string;
    duration: number;
    summary: string;
  };
};
// Create a type which represents only one of the above types
// but you aren't sure which it is yet.
type NetworkState =
  | NetworkLoadingState
  | NetworkFailedState
  | NetworkSuccessState;

Performance

microsoft/Typescript/wiki/Performance#preferring-interfaces-over-intersections

Much of the time, a simple type alias to an object type acts very similarly to an interface.

interface Foo {
  prop: string;
}

type Bar = { prop: string };

However, and as soon as you need to compose two or more types, you have the option of extending those types with an interface, or intersecting them in a type alias, and that’s when the differences start to matter.

Interfaces create a single flat object type that detects property conflicts, which are usually important to resolve! Intersections on the other hand just recursively merge properties, and in some cases produce never. Interfaces also display consistently better, whereas type aliases to intersections can’t be displayed in part of other intersections. Type relationships between interfaces are also cached, as opposed to intersection types as a whole. A final noteworthy difference is that when checking against a target intersection type, every constituent is checked before checking against the “effective”/“flattened” type.

For this reason, extending types with interfaces/extends is suggested over creating intersection types.

- type Foo = Bar & Baz & {
-     someProp: string;
- }

+ interface Foo extends Bar, Baz {
+     someProp: string;
+ }

Reference

interface vs. type doesn’t matter. They’re almost interchangeable. Interfaces can be merged, types are needed for unions, but those are basically the only differences, so just pick one and go with it. - reddit -

Upgrade to Angular 20 from Angular 13 - Part 2: Angular 15

Sat, 19 Jul 2025 05:00:00 GMT

Time really flies! It has been almost a month since I last worked on upgrading my Jira Clone from Angular 13 to 14. Since then, I have been to quite a few exciting events:

Google I/O Extended MienTrung 2025, where I had the chance to connect with the developer community in Vietnam 🇻🇳
SCS Youth Training, where I was a Lead Trainer supporting a group of aspiring Digital Advocates as they prepared to teach digital skills to the public
And on top of that, work has been packed with new projects and challenges

But now I’m back to continue our Angular migration journey! In Part 1, we successfully upgraded from Angular 13 to Angular 14, navigating through various dependency conflicts with ESLint, custom webpack configurations, Ant Design packages, and even Sentry integration. We learned some valuable lessons about using --force flags strategically and checking package compatibility with npm view.

Quick Recap: What We Accomplished in Part 1

For those who missed Part 1, here’s what we tackled:

Started with Angular 13 and planned the incremental upgrade path: 13 → 14 → 15 → 16 → 17 → 18 → 19 → 20
Upgraded to Angular 14 using:

ng update @angular/core@14 @angular/cli@14 --force

Resolved dependency conflicts with:
- @angular-eslint/schematics (upgraded to 14.3.0)
- @angular-builders/custom-webpack (upgraded to 14.1.0)
- @ant-design/icons-angular and ng-zorro-antd (upgraded to 14.1.0)
- @sentry/angular (upgraded to 9.30.0)
Fixed build issues by removing the deprecated --sourceMap=true flag
Successfully deployed to Netlify with a working Angular 14 application

The key takeaway was that incremental upgrades are the way to go, and it’s perfectly fine to use --force during major version transitions as long as you resolve all dependencies before merging.

The Next Challenge: Angular 14 → 15

Now it’s time to tackle the next step in our migration journey. Please note that for now, I will upgrade the Angular version first before running any schematics for migrating to standalone component and control flow (available in Angular v17).

With the lessons learned from Part 1, the upgrade to Angular 15 should be easier to tackle.

Create a New Branch

First things first, I created a new branch to safely experiment:

git checkout -b trung/v20-migration-part-2

Step 1: ng update

I started with the Angular 15 upgrade:

ng update @angular/core@15 @angular/cli@15

Note: If you see the error zsh: command not found: ng, it means you don’t have the Angular CLI installed globally. You have two options:

Install it globally (recommended for frequent Angular development):
```
npm install -g @angular/cli
```
Guide: https://angular.dev/installation#install-angular-cli
Use npx (if you prefer not to install globally):
```
npx ng update @angular/core@15 @angular/cli@15
```

The npx command allows you to run an arbitrary command from an npm package (either installed locally or fetched remotely). If ng doesn’t exist on your machine, npm will fetch it from the registry and execute it.

ng update —force

I ran the command and immediately hit an error that looked very familiar from Part 1:

> npx ng update @angular/core@15 @angular/cli@15

The installed Angular CLI version is outdated.
Installing a temporary Angular CLI versioned 15.2.11 to perform the update.
✔ Packages successfully installed.
Using package manager: npm
Collecting installed dependencies...
Found 70 dependencies.
Fetching dependency metadata from registry...
                  Package "@angular-eslint/schematics" has an incompatible peer dependency to "@angular/cli" (requires ">= 14.0.0 < 15.0.0", would install "15.2.11").
✖ Migration failed: Incompatible peer dependencies found.
Peer dependency warnings when installing dependencies means that those dependencies might not work correctly together.
You can use the '--force' option to ignore incompatible peer dependencies and instead address these warnings later.

The issue is that ESLint requires a specific Angular version. We have a chicken-and-egg problem: if we upgrade ESLint first, it will require Angular 14, but if we upgrade Angular first, ESLint will complain. The solution is to use the --force option to proceed with the Angular upgrade first, then upgrade the dependencies.

After running the command with --force, now all Angular versions are updated to v15.

Step 2: Upgrading @angular-builders/custom-webpack

I committed the changes and tried running npm install, but encountered a compatibility issue:

> npm install

npm error code ERESOLVE
npm error ERESOLVE could not resolve
npm error
npm error While resolving: @angular-builders/custom-webpack@14.1.0
npm error Found: @angular/compiler-cli@15.2.10
npm error node_modules/@angular/compiler-cli
npm error   dev @angular/compiler-cli@"^15.2.10" from the root project
npm error   peer @angular/compiler-cli@"^15.0.0" from @angular-devkit/build-angular@15.2.11
npm error   node_modules/@angular-devkit/build-angular
npm error     dev @angular-devkit/build-angular@"^15.2.11" from the root project
npm error     peer @angular-devkit/build-angular@">=0.8.9 || >= 12.0.0" from @storybook/angular@6.4.19
npm error     node_modules/@storybook/angular
npm error       dev @storybook/angular@"^6.1.11" from the root project
npm error       1 more (@storybook/addon-docs)
npm error   2 more (@ngtools/webpack, @storybook/angular)
npm error
npm error Could not resolve dependency:
npm error peer @angular/compiler-cli@"^14.0.0" from @angular-builders/custom-webpack@14.1.0
npm error node_modules/@angular-builders/custom-webpack
npm error   dev @angular-builders/custom-webpack@"^14.1.0" from the root project
npm error
npm error Conflicting peer dependency: @angular/compiler-cli@14.3.0
npm error node_modules/@angular/compiler-cli
npm error   peer @angular/compiler-cli@"^14.0.0" from @angular-builders/custom-webpack@14.1.0
npm error   node_modules/@angular-builders/custom-webpack
npm error     dev @angular-builders/custom-webpack@"^14.1.0" from the root project
npm error
npm error Fix the upstream dependency conflict, or retry
npm error this command with --force or --legacy-peer-deps
npm error to accept an incorrect (and potentially broken) dependency resolution.

This npm error occurs because @angular-builders/custom-webpack@14.1.0 requires Angular 14’s @angular/compiler-cli, but after upgrading to Angular 15, the project now has Angular 15’s @angular/compiler-cli@15.2.10, creating a version conflict that npm cannot automatically resolve.

Which means we need to also upgrade @angular-builders/custom-webpack to a newer version.

To see what versions were available for @angular-builders/custom-webpack, I ran:

> npm view @angular-builders/custom-webpack versions --json

[
  ...
  "14.1.0",
  "15.0.0-beta.0",
+  "15.0.0",
  "16.0.0-beta.0",
  "16.0.0-beta.1",
  "16.0.0-beta.2",
  "16.0.0",
  ...
]

The list was long, but I could use version 15.0.0. To verify compatibility, I checked the peer dependencies:

> npm view @angular-builders/custom-webpack@15.0.0 peerDependencies --json

{
  "@angular/compiler-cli": "^15.0.0"
}

I updated the package.json to use @angular-builders/custom-webpack@15.0.0 and ran npm install. For sure, there are still a few dependencies we need to resolve before a normal npm install can run successfully. So I ran npm install --force first to generate a new package-lock.json, committed the changes, and moved on to the next error.

Step 3. Upgrade @angular-eslint/schematics

After running npm install again, I saw that @angular-eslint/schematics also needed an upgrade.

I checked the available versions:

> npm view @angular-eslint/schematics versions --json

"15.2.0",
"15.2.1-alpha.0",
"15.2.1-alpha.2",
"15.2.1-alpha.5",
"15.2.1-alpha.9",
"15.2.1-alpha.13",
"15.2.1-alpha.15",
"15.2.1-alpha.18",
+ "15.2.1"

There were many versions available up to 20, so I picked 15.2.1 and updated my package.json for all @angular-eslint/* packages. After that, I ran:

npm install --force

Committed the changes and moved on — now it’s time to tackle @angular/cdk.

Step 4: Upgrade @angular/cdk

Running npm install again, we can see that @angular/cdk is now not compatible. I guess I forgot to update it in Part 1 but it was still compatible previously.

We do the very similar process.

> npm view @angular/cdk versions --json

"15.2.0-next.2",
"15.2.0-next.3",
"15.2.0-next.4",
"15.2.0-rc.0",
"15.2.0",
"15.2.1",
"15.2.2",
"15.2.3",
"15.2.4",
"15.2.5",
"15.2.6",
"15.2.7",
"15.2.8",
+ "15.2.9",
"16.0.0-next.0",
"16.0.0-next.1",
"16.0.0-next.2",
"16.0.0-next.3",
"16.0.0-next.4",

There were many versions available up to 20, so I picked 15.2.9 and updated my package.json for all @angular/cdk. After that, I ran npm install --force as not all dependencies had been resolved. Committed the changes.

"dependencies": {
  "@angular/animations": "^15.2.10",
-  "@angular/cdk": "^13.2.4",
+  "@angular/cdk": "^15.2.9",
  "@angular/common": "^15.2.10",
  "@angular/compiler": "^15.2.10",

Step 5: Upgrading Ant Design Packages

Next, @ant-design/icons-angular was not yet compatible.

I followed the same process and checked available versions:

> npm view @ant-design/icons-angular versions --json

"13.1.0",
"14.1.0",
+ "15.0.0",
"16.0.0-beta.0",
"16.0.0",
"17.0.0-beta.0",
"17.0.0",

I chose version 15.0.0 since it’s the closest version that should be compatible with Angular 15. I noticed ng-zorro-antd needed upgrade as well. And surprisingly, after upgrading those two, running npm install did not show any error.

Done

Running npm start works perfectly as well ✅ Mission complete.

The Angular 15 upgrade is complete. Compared to the Angular 14 upgrade, this round was much smoother and faster. Took about an hour, including screenshots and writing this post 🤣

Here is the PR for reference: https://github.com/trungvose/jira-clone-angular/pull/107

See you in Part 3: Angular 16.

✅ Angular 15 is live on PROD!

Merged and deployed successfully. Everything looks good.

Upgrade to Angular 20 from Angular 13 - Part 1: Angular 14

Fri, 20 Jun 2025 15:30:00 GMT

Recently, Angular 20 has been released with tons of crazy cool features! While everyone’s talking about the major highlights, one of the less-discussed gems is the improved Angular Devtools that let you see simplified stats directly in Chrome DevTools.

I was super excited to try it out, but instead of starting a fresh Angular 20 app, I thought about the applications I published years ago - Jira Clone, Tetris, and Angular Spotify - that are still running on Angular 10 or so 😂. This is the perfect moment to upgrade them to Angular 20 and then explore all the new features!

So let’s start with migrating my Jira Clone from Angular 13 to Angular 20. Spoiler alert: it’s not as straightforward as I initially thought! 😅

The upgrade strategy

Create a new branch

First things first, I created a new branch to safely experiment:

git checkout -b trung/v20-migration-part-1

Plan the upgrade path

Angular does an excellent job guiding us through the upgrade process. I visited angular.dev/update-guide and selected version 13 as the starting point (what Jira Clone is currently running) and version 20 as the target.

Initially, I thought Jira Clone was just a simple project that fetches data from a server and renders it on the client side. But the more I thought about it, I realized there were quite a few workarounds I implemented in Angular 13 to make certain features work. For example, I needed a custom webpack configuration to process SCSS files through postcss-loader with several plugins:

{
  test: /\.scss$/,
  loader: 'postcss-loader',
  options: {
    postcssOptions: {
      ident: 'postcss',
      syntax: 'postcss-scss',
      plugins: ['postcss-import', 'tailwindcss', 'autoprefixer'],
    },
  },
}

This meant the upgrade from Angular 13 to Angular 20 might not be as smooth as I initially anticipated. So I chose “Medium” application complexity to get notified about the tricky steps.

The reality check

As you can see from the suggested steps, the safest route is to upgrade incrementally: 13 → 14 → 15 → 16 → 17 → 18 → 19 → 20 😂

In a real production application, you’d plan these upgrades in advance and tackle one version per sprint. But since this is my side project, I’m going to do it all in one weekend morning (that didn’t happen - I only managed to migrate to Angular 14 in one morning and a bit of night time 🤣)

Pro tip: After each upgrade step, test your changes and commit them if everything works. This way, if the next step fails, you can always roll back to the previous working version. Don’t try to do everything at once and commit at the end - you’ll never know which changes worked and which broke the upgrade.

Step 1: ng update

I started with the Angular 14 upgrade:

ng update @angular/core@14 @angular/cli@14

Note: If you see the error zsh: command not found: ng, it means you don’t have the Angular CLI installed globally. You have two options:

Install it globally (recommended for frequent Angular development):
```
npm install -g @angular/cli
```
Guide: https://angular.dev/installation#install-angular-cli
Use npx (if you prefer not to install globally):
```
npx ng update @angular/core@14 @angular/cli@14
```

@angular-eslint/schematics compatibility

I ran the command and immediately hit an error:

> npx ng update @angular/core@14 @angular/cli@14

The installed Angular CLI version is outdated.
Installing a temporary Angular CLI versioned 14.2.13 to perform the update.
✔ Package successfully installed.
Using package manager: npm
Collecting installed dependencies...
Found 70 dependencies.
Fetching dependency metadata from registry...
                  Package "@angular-eslint/schematics" has an incompatible peer dependency to "@angular/cli" (requires ">= 13.0.0 < 14.0.0", would install "14.2.13").
✖ Migration failed: Incompatible peer dependencies found.
Peer dependency warnings when installing dependencies means that those dependencies might not work correctly together.
You can use the '--force' option to ignore incompatible peer dependencies and instead address these warnings later.

ng update —force

The solution is to use the --force option to proceed with the Angular upgrade first, then upgrade the dependencies.

Step 2: The Custom Webpack Dilemma

After the Angular upgrade, I ran npm start and immediately encountered another error:

This version of CLI is only compatible with Angular versions ^13.0.0 || ^13.3.0-rc.0,
but Angular version 14.3.0 was found instead.

Please visit the link below to find instructions on how to update Angular.
https://update.angular.io/

This was strange because the Angular CLI version was actually 14.2.13. I suspected the issue was with the @angular-devkit versions. Even though @angular-devkit/build-angular was at 14.2.13, other packages like @angular-devkit/core and @angular-devkit/schematics were still at 13.2.5.

To investigate which packages were using different versions of @angular-devkit/build-angular, I ran:

npm ls @angular-devkit/build-angular

The output revealed the culprit:

jira-clone-angular-frontend@1.0.0 /Users/trung.vo/Source/jira-clone-angular
├─┬ @angular-builders/custom-webpack@13.1.0
│ └── @angular-devkit/build-angular@13.3.11
├── @angular-devkit/build-angular@14.2.13
└─┬ @storybook/angular@6.4.19
  └── @angular-devkit/build-angular@14.2.13 deduped

The @angular-builders/custom-webpack@13.1.0 was using @angular-devkit/build-angular@13.3.11, so we needed to upgrade it.

Upgrading @angular-builders/custom-webpack

To see what versions were available for @angular-builders/custom-webpack, I ran:

npm view @angular-builders/custom-webpack versions --json

The list was long, but I could use version 14.1.0. To verify compatibility, I checked the peer dependencies:

npm view @angular-builders/custom-webpack@14.1.0 peerDependencies --json

Output:

{
  "@angular/compiler-cli": "^14.0.0"
}

Perfect! We definitely have compiler-cli 14 in our project, so I updated the package.json to use @angular-builders/custom-webpack@14.1.0.

Step 3: Upgrading @angular-eslint/*

After running npm install again, I saw that @angular-eslint/schematics@13.1.0 also needed an upgrade.

I checked the available versions:

npm view @angular-eslint/schematics versions --json

There were many versions available up to 20, so I picked 14.3.0 and updated my package.json.

Step 4: @ant-design/icons-angular and ng-zorro-antd

Next, @ant-design/icons-angular@13.1.0 was causing issues. I followed the same process and checked available versions:

npm view @ant-design/icons-angular versions --json

I chose version 14.1.0 since it’s the closest version that should be compatible with Angular 14. I also noticed ng-zorro-antd was on 13.1.0, so I upgraded that as well.

Step 5: @sentry/angular

Run npm install again and now @sentry/angular@6.18.1 was throwing an error - which was expected! 😄 The tricky part with Sentry is that it doesn’t follow Angular’s versioning pattern (13, 14, etc.). Instead, it uses its own versioning like 6.18.1, so the next version that supports Angular 14 would likely be version 7.

I checked the available Sentry versions:

npm view @sentry/angular versions --json

Wow, there were many versions! Sentry doesn’t jump per major version as you might expect. I searched for @sentry/angular compatible with angular 14 and found comprehensive documentation from Sentry:

https://docs.sentry.io/platforms/javascript/guides/angular/manual-setup/#which-sdk-version-should-you-use-with-your-angular-version

In its current major version, the Sentry Angular SDK supports Angular 14 and newer.

If you’re using an older version of Angular, you also need to use an older version of the SDK. See the table below for compatibility guidance

I had two options:

Install the latest version using npm install @sentry/angular@latest --force (we need --force because our dependencies aren’t fully resolved yet due to the Sentry package itself)
Manually pick a compatible version from the npm view output

I chose option 2 and picked version 9.30.0. To be safe, I checked the peer dependencies first:

npm view @sentry/angular@9.30.0 peerDependencies --json

Excellent! The peer dependencies were quite broad: >= 14.x <= 20.x, so we were safe to proceed.

Pro tip: npm view <package name> peerDependencies --json is the way to verify package dependencies without going to the npm website or “guessing”!

Finally success with ng serve!

Finally, npm install worked! I ran npm start and the application finally started building.

However, there was still a Sentry error preventing the app from starting:

Since the issue was isolated to Sentry, I temporarily commented out the problematic code. The app compiled successfully!

After the build succeeded, I updated the Sentry code to follow the latest version documentation. ng serve looked good, so I committed the changes and pushed to CI.

Not the end - ng build failed

However, when I pushed the changes to Netlify, the preview build failed with a pretty straightforward error:

5:41:55 PM: $ npm run build
5:41:55 PM: > jira-clone-angular-frontend@1.0.0 build
5:41:55 PM: > ng build --sourceMap=true
5:41:56 PM: Error: Unknown argument: sourceMap
5:41:56 PM: 
5:41:56 PM: "build.command" failed

As you can see in my package.json, the build command was mapped to ng build --sourceMap=true, and I believe this option has been removed in later Angular versions. I removed the --sourceMap=true flag and let the build run through. Since it worked locally, I didn’t expect any surprises when pushing to Netlify - and indeed, it was successful! With that, our journey to migrate to Angular 14 is complete. 🎉

👉 You can check out the full changes in this PR: https://github.com/trungvose/jira-clone-angular/pull/106

✅ Angular 14 is live on PROD!

Merged and deployed successfully. Everything looks good.

What’s Next?

This was just the first step - upgrading to Angular 14. The journey continues with upgrades to versions 15, 16, 17, 18, 19, and finally 20. Each step will likely bring its own challenges and dependencies to resolve.

The key takeaways from this Angular 14 upgrade:

It’s okay to use --force when dealing with peer dependency conflicts during major version upgrades, but make sure to resolve all dependencies before merging to the main branch. Otherwise, CI builds and other developers’ machines will fail to run npm install and they’ll also need to use --force
Check package version using npm view <package> versions --json
Check package compatibility using npm view <package> peerDependencies --json
Upgrade dependencies incrementally and test after each step
Don’t be afraid to temporarily comment out problematic code to isolate issues

Stay tuned for the next part where we upgrade Angular 15!

Typescript this and implement debounce

Sat, 07 Jun 2025 07:45:00 GMT

Back in 2020, I was in an interview and the interviewer asked me to implement a debounce function. I was surprised — I had been using debounce functions for years, mostly from libraries like Lodash, but I never actually had to write one from scratch. I did not solve it back then. Recently I stumbled upon the same question again, and this time I decided to finally sit down and do it.

Let go through it together — what debounce is, why it matters, and how to implement one correctly in TypeScript.

What is debounce?

The idea of debouncing is to control how frequently a function runs over a period of time. You give it a time window, and it ensures the function only gets called once after that window has passed without further calls.

For example:

const sayHello = debounce(() => {
  console.log('hello');
}, 300);

sayHello();
sayHello();
sayHello(); // Only logs once after 300ms

Debouncing makes sure sayHello() only runs after a set delay (300ms) has passed since the last time it was called.

This is useful for scenarios like:

mousemove events: These can fire hundreds of times per second. You do not want to handle every single one.
Search boxes: Instead of sending a request on every keystroke, you wait until the user stops typing for a short moment.

Example for mousemove:

document.addEventListener('mousemove', debounce((event: MouseEvent) => {
  console.log(`Mouse at (${event.clientX}, ${event.clientY})`);
}, 100));

Now the log only shows up at most once every 100ms, no matter how fast you move the mouse.

Step 1: Basic implementation

Let start with the function signature:

export default function debounce(func: Function, wait: number): Function {
}

It takes two inputs: a function to debounce and a wait time in milliseconds. It returns a new function that wraps the original.

A basic version looks like this:

export default function debounce(func: Function, wait: number): Function {
  let timer: any = null;
  function debounceFn() {
    if (timer) {
      clearTimeout(timer);
    }
    timer = setTimeout(() => {
      func();
    }, wait);
  }
  return debounceFn;
}

How this works:

The first time you call debounceFn, it sets a timer.
If you call it again before the timer finishes, it clears the old timer and starts a new one.
The original func only gets executed once the calls stop for wait milliseconds.

Test case:

const sayHello = debounce(() => {
  console.log('hello');
}, 300);

sayHello(); // Sets a timer

setTimeout(() => {
  sayHello(); // Resets the timer after 200ms
}, 200);

// Result: 'hello' logs after 500ms total

Step 2: `this` test failed

Life is not that easy, one test failed 😂

test('callbacks can access `this`', (done) => {
  const increment = debounce(function (this: any, delta: number) {
    this.val += delta;
  }, 10);

  const obj = {
    val: 2,
    increment,
  };

  expect(obj.val).toBe(2);
  obj.increment(3);
  expect(obj.val).toBe(2); // still 2, not yet updated

  setTimeout(() => {
    expect(obj.val).toBe(5); // expect 2 + 3
    done();
  }, 20);
});

But the result was wrong. The value stayed at 2.

Why?

Two reasons:

The this inside the original function was lost.
Arguments like delta were not passed through at all.

In our earlier version:

setTimeout(() => {
  func(); // no context, no arguments
}, wait);

That func() call is missing both this and the original parameters. Time to fix both.

Step 3: Fix `this` and arguments using `apply`

To preserve this and the function parameters, I updated the debounce to use .apply.

apply lets you call a function with a specific this value and pass arguments as an array.

Also, TypeScript needs a little help to understand the use of this inside the function. You can explicitly annotate it as the first argument like this:

function (this: any, ...args: any[])

This is a TypeScript-specific feature that was introduced in version 2.0 — more details Specifying the type of this for functions.

So now the code looks like:

export default function debounce(func: Function, wait: number): Function {
  let timer: any = null;
  return function debounceFn(this: unknown, ...args: any[]) {
    if (timer) {
      clearTimeout(timer);
    }
    timer = setTimeout(() => {
      func.apply(this, args); // pass this and args correctly
    }, wait);
  };
}

Final Result

Now we have a debounce that works:

It delays execution properly
It preserves this context
It forwards all arguments

This version passed all my tests.

const increment = debounce(function (this: any, delta: number) {
  this.val += delta;
}, 10);

const obj = {
  val: 2,
  increment,
};

obj.increment(3);

// After 10ms, obj.val === 5

That was a fun exercise for sure! You can practice it here at greatfrontend.com

Classnames implementation in TypeScript

Sat, 31 May 2025 14:00:00 GMT

Still the same conversation with my friend who recently went for an interview. After the Python indentation task, the next challenge was another familiar one for front end engineers — implement the classnames utility, or the newer clsx used in React apps.

If you have used React, you have probably written code like this:

<div className={classNames('btn', isActive && 'active')} />

This utility helps combine class names conditionally and neatly, now let’s see how simple it is to implement it.

Requirement

classnames is a commonly-used utility in modern front end applications to conditionally join CSS class names together. If you’ve written React applications, you likely have used a similar library.

Implement the classnames function.

Examples

classNames('foo', 'bar'); // 'foo bar'
classNames('foo', { bar: true }); // 'foo bar'
classNames({ 'foo-bar': true }); // 'foo-bar'
classNames({ 'foo-bar': false }); // ''
classNames({ foo: true }, { bar: true }); // 'foo bar'
classNames({ foo: true, bar: true }); // 'foo bar'
classNames({ foo: true, bar: false, qux: true }); // 'foo qux'

Arrays will be recursively flattened as per the rules above.

classNames('a', ['b', { c: true, d: false }]); // 'a b c'

Values can be mixed.

classNames(
  'foo',
  {
    bar: true,
    duck: false,
  },
  'baz',
  { quux: true },
); // 'foo bar baz quux'

Falsey values are ignored.

classNames(null, false, 'bar', undefined, { baz: null }, ''); // 'bar'

In addition, the returned string should not have any leading or trailing whitespace.

Thought process

I have solved similar problems before, like converting snake_case to camelCase, which taught me to check the type first — if the value is a string, object, or array — and then deal with each case properly.

This problem is about combining class names based on rules. The tricky part is dealing with mixed types, recursive arrays, and ignoring falsey values like null, undefined, false, and ''.

I broke the problem into smaller pieces:

1. If the input is a string

Use the string as-is (after trimming).

if (typeof input === 'string') {
  return input.trim();
}

2. If the input is a number

Just convert it to string.

if (typeof input === 'number') {
  return input.toString();
}

3. If the input is an array

Recursively flatten each value inside the array.

if (Array.isArray(input)) {
  return input.map(flattenClass).join(' ');
}

4. If the input is an object

Pick only the keys that have truthy values.

if (typeof input === 'object') {
  return Object.entries(input)
    .filter(([_, value]) => Boolean(value))
    .map(([key]) => key)
    .join(' ');
}

Ignore everything else (null, false, undefined, empty string). After applying all these steps, collect the results and join with a space.

Final implementation

export type ClassValue =
  | string
  | number
  | boolean
  | null
  | undefined
  | ClassDictionary
  | ClassArray;

export type ClassDictionary = Record<string, any>;
export type ClassArray = Array<ClassValue>;

export default function classNames(...args: ClassValue[]): string {
  return args.map(flattenClass).filter(Boolean).join(' ').trim();
}

function flattenClass(input: ClassValue): string {
  if (!input) return '';
  if (typeof input === 'string') return input.trim();
  if (typeof input === 'number') return input.toString();
  if (Array.isArray(input)) return input.map(flattenClass).join(' ');
  if (typeof input === 'object') {
    return Object.entries(input)
      .filter(([_, value]) => Boolean(value))
      .map(([key]) => key)
      .join(' ');
  }
  return '';
}

Results

You can practice this question here

Validating Python Indentation in TypeScript

Sun, 18 May 2025 14:00:00 GMT

A friend of mine recently went for a coding interview and was given a small but tricky challenge: validate if a block of Python code has the correct indentation.

The catch? You cannot run the code. You are not supposed to validate syntax either. You just need to tell if the indentation structure is valid.

We were chatting and I thought — actually, this is a nice little puzzle. So I decided to write a validator in TypeScript just for fun.

Scope

This is a structural check only. We do not validate Python syntax or runtime behaviour. Just indentation.

Assumptions

To keep things simple and deterministic:

Indentation uses 4 spaces only
No mixing tabs and spaces
Any line ending with : should be followed by a more indented line

Example

Valid Code

number = 5
if number > 0:
    print("Positive number")
    if number % 2 == 0:
        print("Even number")
    else:
        print("Odd number")

Invalid Code Examples

Missing indentation after :

number = 5
if number > 0:
print("Positive number")  # not indented

Inconsistent indentation

number = 5
if number > 0:
    print("Positive number")
  print("This line has wrong indentation")  # 2 spaces instead of 4

Invalid dedent

number = 5
if number > 0:
    print("Positive number")
        print("Too much indentation")  # 8 spaces when only 4 is valid

Missing indentation in nested block

number = 5
if number > 0:
    if number % 2 == 0:
    print("Missing indentation")  # should be indented with 8 spaces

Implementation

Ideas

When reading the requirement, my thought process was pretty straightforward:

Split the code by newlines
Skip empty lines or lines with only comments
For each non-empty line:
- Count the number of leading spaces
- Compare with the current expected indent
- If the line ends with a colon (:), expect an indent increase on the next line. This is different from the valid parenthesis problem where it’s more straightforward - if the string starts with an opening bracket ({, [, or (), you know exactly what the expected closing bracket (}, ], or )) should be
- Use a stack to track indent levels - push new levels when we enter a block, pop when we leave
- If the indent does not match any level in the stack, it is invalid

Step #1: Basic Structure

Let’s start with the basic structure:

const TAB_SIZE = 4

export function validatePythonIndentation(input: string): boolean {
  if (!input) {
    return false;
  }
  const indents: number[] = [0];
  const lines = input.split('\n');
  for (const rawLine of lines) {
    const line = rawLine.trimEnd();
    // DO THE REAL STUFF
  }
}

function countSpacesFromBeginning(line: string): number {
  return line.length - line.trimStart().length;
}

function isLineStartNewBlock(line: string): boolean {
  return line.endsWith(':');
}

Step #2: Handling Indentation Nesting

Now we add the logic to handle indentation nesting:

Check the current line’s indentation against the expected levels stored in a stack (indents)
If the current indentation is less than the top of the stack, it means we are leaving one or more blocks — so we pop those indentation levels until the current indent matches the new top (I know it is yet clicked, the see the example below)
If the current indentation does not match the new top after popping, it is invalid
If the line ends with :, push a new expected indentation (current + 4 spaces) to the stack

The tricky part is the pop loop that handles dedents:

const TAB_SIZE = 4

export function validatePythonIndentation(input: string): boolean {
  if (!input) {
    return false;
  }
+  // Start with [0] because the first line should have no indentation
+  // This represents the base level of indentation (0 spaces)  
+  const indents: number[] = [0];
  const lines = input.split('\n');
  for (const rawLine of lines) {
    const line = rawLine.trimEnd();
    if (line === '') {
      continue // skip empty line;
    }

    const currentIndent = countSpacesFromBeginning(line);
+    while (indents.length && currentIndent < indents[indents.length - 1]) {
+      indents.pop();
+    }
    const expectedIndent = indents[indents.length - 1];

    if (currentIndent !== expectedIndent) {
      return false;
    }

    if (isLineStartNewBlock(line)) {
      const nextExpectedIndent = currentIndent + TAB_SIZE;
      indents.push(nextExpectedIndent);
    }
  }
+  return true;
}

function countSpacesFromBeginning(line: string): number {
  return line.length - line.trimStart().length;
}

function isLineStartNewBlock(line: string): boolean {
  return line.endsWith(':');
}

What is going on here?

The stack stores allowed indentation levels, starting with [0]
When a line has less indent than the last recorded indent, it means we must close some blocks
The loop pops those bigger indents until the top matches or is less than or equal to the current indent

Why return true?

Our validator checks every line. If no line violates the expected indent, the input is valid.

So return true at the end means:

I saw no mistake, so I approve.

How It Works: A Concrete Example

Let’s walk through this Python snippet using our indentation validator:

number = 5
if number > 0:
    if number % 2 == 0:
        print("Even")
    else:
        print("Odd")
print("done")

We assume TAB_SIZE = 4.

Initial Setup

indents = [0] Starts with 0 to mean top-level code should have no indentation.

Line-by-line

number = 5
- Indent = 0
- Top of stack = 0 → valid
- Does not end with : → no new block
- indents = [0] (unchanged)
if number > 0:
- Indent = 0
- Top of stack = 0 → valid
- Ends with : → push 0 + 4 = 4
- indents = [0, 4]
if number % 2 == 0:
- Indent = 4
- Top of stack = 4 → valid
- Ends with : → push 4 + 4 = 8
- indents = [0, 4, 8]
print("Even")
- Indent = 8
- Top of stack = 8 → valid
- No : → no push
- indents = [0, 4, 8] (unchanged)
else:
- Indent = 4
- Top of stack = 8 → mismatch, but less than top → Pop until top is 4
- After pop: indents = [0, 4]
- Top = 4 → match
- Ends with : → push 4 + 4 = 8
- indents = [0, 4, 8]
print("Odd")
- Indent = 8
- Top = 8 → match
- No : → no push
- indents = [0, 4, 8]
print("done")
- Indent = 0
- Top = 8 → pop to 4 → pop to 0
- Top = 0 → match
- No : → done
- indents = [0]

No invalid indentation found

So at the end, we never returned false. That means the indentation is valid, so we return true.

Playground

Try it out in the TypeScript Playground.

React Aria Components - Slider with filled background

Wed, 30 Apr 2025 01:30:00 GMT

Even though I’ve been an Engineering Manager for the past two years, I still love getting my hands dirty with code! Recently, I helped my team with a cool UI challenge - customizing React Aria’s Slider component to show a filled background between two thumbs.

Before & After

Let’s see how the slider looks with and without the fill effect:

Slider without filled background

Basic slider without fill effect - just the track and thumb

Slider with filled background

Enhanced slider with fill effect - notice the white background

Source Code & Demo

The Challenge

React Aria’s Slider component is awesome for accessibility, but it doesn’t come with a built-in way to show the filled portion of the slider. When you have a range slider (two thumbs), you might want to visually indicate the selected range with a filled background.

The Solution

One thumb slider

First, let’s look at a basic single-thumb slider:

import {Label, Slider, SliderOutput, SliderThumb, SliderTrack} from 'react-aria-components';

<Slider defaultValue={30}>
  <Label>Basic Slider</Label>
  <SliderOutput />
  <SliderTrack>
    <SliderThumb />
  </SliderTrack>
</Slider>

⚠️ Important: The above code will only render a label and a circle without any styling. You’ll need to add CSS to make it look good.

Since our project uses Tailwind CSS, here’s our styled version:

import {
  Label,
  Slider,
  SliderOutput,
  SliderThumb,
  SliderTrack,
} from 'react-aria-components';

export function OneThumbSlider() {
  return (
    <div className="bg-linear-to-r from-purple-600 to-pink-600 p-12 rounded-lg flex justify-center">
      <Slider defaultValue={30} className="w-[250px]">
        <div className="flex text-white">
          <Label className="flex-1 text-left">Basic Slider</Label>
          <SliderOutput />
        </div>
        <SliderTrack className="relative w-full h-7">
          {() => (
            <>
              <div className="absolute h-2 top-[50%] translate-y-[-50%] w-full rounded-full bg-white/40" />
              <SliderThumb className="h-7 w-7 top-[50%] rounded-full border border-solid border-purple-800/75 bg-white transition dragging:bg-purple-100 outline-hidden focus-visible:ring-2 ring-black" />
            </>
          )}
        </SliderTrack>
      </Slider>
    </div>
  );
}

Here’s how it looks:

This implementation is based on the React Aria Opacity Slider example from Adobe’s React Spectrum documentation.

Now, let’s add the filled background. We’ll create a new prop to toggle this feature:

+ interface OneThumbSliderProps {
+   fill: boolean;
+ }

export function OneThumbSlider({ fill }: OneThumbSliderProps) {
  return (
    <div className="bg-linear-to-r from-purple-600 to-pink-600 p-12 rounded-lg flex justify-center">
      <Slider defaultValue={30} className="w-[250px]">
        <div className="flex text-white">
          <Label className="flex-1 text-left">Basic Slider</Label>
          <SliderOutput />
        </div>
        <SliderTrack className="relative w-full h-7">
          {({ state }) => (
            <>
              <div className="absolute h-2 top-[50%] translate-y-[-50%] w-full rounded-full bg-white/40" />
+              {fill && (
+                <div
+                  className="absolute h-2 top-[50%] translate-y-[-50%] rounded-full bg-white"
+                  style={{ width: state.getThumbPercent(0) * 100 + '%' }}
+                />
+              )}
              <SliderThumb className="h-7 w-7 top-[50%] rounded-full border border-solid border-purple-800/75 bg-white transition dragging:bg-purple-100 outline-hidden focus-visible:ring-2 ring-black" />
            </>
          )}
        </SliderTrack>
      </Slider>
    </div>
  );
}

Let’s break down the key parts:

The CSS classes absolute h-2 top-[50%] translate-y-[-50%] rounded-full bg-white: Positions and styles the fill element - absolute positioning, 8px height, using vertically centered trick of translate-y-[50%], rounded corners, and white background
The width calculation:

state.getThumbPercent(0) returns the position of the first thumb as a decimal (0 to 1)
* 100 converts the decimal to a percentage
This creates a dynamic width that matches the thumb’s position

For example, if the slider value is 30 (out of 100):

state.getThumbPercent(0) returns 0.3 (30%)
0.3 * 100 = 30
30 + '%' = “30%”
So the fill div will be 30% of the track’s width

And here’s the result:

Two thumbs slider

For a range slider with two thumbs, we need to:

Pass an array of two values as defaultValue
Map through the values to render multiple thumbs and format the output

Here’s how we implement it:

export function TwoThumbsSlider({ fill }: TwoThumbsSliderProps) {
  return (
    <div className="bg-linear-to-r from-blue-600 to-yellow-600 p-12 rounded-lg flex justify-center">
+      <Slider defaultValue={[30, 65]} className="w-[250px]">
        <div className="flex text-white">
          <Label className="flex-1 text-left">Two Thumbs Slider</Label>
+          <SliderOutput>
+            {({ state }) =>
+              state.values
+                .map((_, i) => state.getThumbValueLabel(i))
+                .join(' – ')
+            }
+          </SliderOutput>
        </div>
        <SliderTrack className="relative w-full h-7">
          {({ state }) => (
            <>
              <div className="absolute h-2 top-[50%] translate-y-[-50%] w-full rounded-full bg-white/40" />
              {fill && (
                <div
                  className="absolute h-2 top-[50%] translate-y-[-50%] rounded-full bg-white"
                  style={getSliderFillStyles(state)}
                />
              )}
+              {state.values.map((_, i) => (
+                <SliderThumb
+                  className="h-7 w-7 top-[50%] rounded-full border border-solid border-purple-800/75 bg-white transition 
+                    dragging:bg-purple-100 outline-hidden focus-visible:ring-2 ring-black"
+                  key={i}
+                  index={i}
+                />
+              ))}
            </>
          )}
        </SliderTrack>
      </Slider>
    </div>
  );
}

Key differences from the single thumb slider:

defaultValue is now an array [30, 65] for two thumbs
SliderOutput uses map to show both values joined with a dash
SliderThumb is rendered using map with an index prop
The fill background uses getSliderFillStyles to calculate width and position between thumbs

Here’s the magic function that handles the fill styles for both single and double thumbs:

function getSliderFillStyles(state: SliderState) {
  if (state.values.length === 1) {
    return {
      width: state.getThumbPercent(0) * 100 + '%',
      left: '0%',
    };
  }

  return {
    width: (state.getThumbPercent(1) - state.getThumbPercent(0)) * 100 + '%',
    left: state.getThumbPercent(0) * 100 + '%',
  };
}

Let’s break down how it works with our example values [30, 65]:

For two thumbs, it calculates:
- width: (0.65 - 0.30) * 100 = 35% (fills 35% of the track)
- left: 0.30 * 100 = 30% (starts at 30% from the left)
This creates a fill that spans exactly between the two thumbs

And here’s the result:

💡 Note: In this demo, I’ve separated the single and double thumb sliders into different components (OneThumbSlider and TwoThumbsSlider) to make the differences clearer. In a real application, you can use a single slider component that handles both cases - just pass either a single value or an array of two values to defaultValue.

Why This Matters

As an Engineering Manager, I believe in leading by example and helping my team solve technical challenges. This kind of UI enhancement might seem small, but it makes a big difference in user experience. Plus, it’s a great way to stay connected with the technical side of things while supporting my team’s growth!

Learn Angular Signals by implementing your own

Tue, 01 Apr 2025 14:00:00 GMT

Angular Signals mark a major shift in how change detection works in Angular. They give Angular a proper reactivity system — no longer relying heavily on Zone.js.

But what is reactivity, really?

At its core, reactivity is about keeping your data and UI in sync. When data changes, the UI should update. When the UI triggers a change, the data should reflect that. It is a two-way relationship.

Signals are Angular’s new primitive for managing this relationship. A signal wraps a value and notifies anything that depends on it when that value changes.

In Angular’s own words: A signal is a lightweight wrapper around a value. Angular tracks where signals are read and when they are updated. This allows Angular to respond to state changes and update the DOM efficiently. This behaviour is what we call reactivity.

A basic Signals usage in Angular looks like this:

const count = signal(0);

// Signals are getter functions — calling them reads their value
console.log('The count is: ' + count());

// Update the value
count.set(3);

// Update based on the previous value
count.update(value => value + 1);

There is also computed() for derived values:

const count = signal(0);
const doubleCount = computed(() => count() * 2);

These are lazily evaluated and memoised — Angular only re-calculates doubleCount when count changes.

Let implement a minimal version of signal and computed from scratch to understand how they work.

Building a simple Signals

Step 0: Define types

We use TypeScript to define two types:

type Signal<T> = () => T;

type WritableSignal<T> = Signal<T> & {
  set: (value: T) => void;
};

A Signal<T> is just a getter function. A WritableSignal<T> is one that also has a set() method.

Step 1: A basic signal()

This is a signal that holds a value, lets you read it

function signal<T>(initial: T): WritableSignal<T> {
  let value = initial;

  const getValue = () => value;

  getValue.set = (newValue: T) => {
    value = newValue;
  };

  return getValue
}

getValue is just a function that returns the current value.
We attach a set method to it so it can also update the value.
This works because in JavaScript, functions are objects. You can attach extra properties to a function just like you would with any object. In this case, getValue.set is just a property we add to the function.

With the above code, the following example will work

const count = signal(0);

function logCount() {
  console.log('Count is:', count());
}

logCount(); // Count is: 0

count.set(3);

logCount(); // Count is: 3

Here is your cleaned up and reflowed Step 2, with duplications removed and the structure improved for easier reading:

Step 2. Implement computed

A computed signal derives its value from other signals. It is a read-only signal whose value is calculated by a function you provide.

function computed<T>(fn: () => T): Signal<T> {
  let value: T = fn();
  const getValue = () => value;
  return getValue;
}

In this implementation:

We invoke fn() once during creation:
```
let value: T = fn();
```
This means the computed value is calculated only once when computed() is called, and the result is cached in value.
The returned getValue() function always returns this cached value.

You might wonder: why not write const getValue = () => fn(); and let it recalculate every time?

Here is why we do not:

Real computed signals cache their values and recalculate only when dependencies change.
If we call fn() inside getValue(), it will re-run on every access, even if the underlying signals have not changed.
It removes any form of caching or memoisation, causing redundant computations.
Most importantly, it breaks the reactive model — in signals, updates are pushed (by dependency changes), not pulled (by re-accessing).

Here is an example:

const count = signal(1);
const doubleCount = computed(() => count() * 2);

console.log(doubleCount()); // 2

count.set(5);

console.log(doubleCount()); // 2 (still old value!)

Why does doubleCount() still return 2 after updating count?

Because fn() ran only once, and we are always returning the cached value.
The computed signal has no way of knowing that count changed — signals do not notify anyone yet.

To fix this, we need to:

Let signals track who depends on them
Notify those dependents (subscribers) when the value changes

That is what we will address in Step 3.

Step 3. Add subscriber tracking

In Step 2, we saw that even after updating the original signal, the computed value does not change. To make this reactive, we need to:

Keep track of which computed function depends on which signals
Notify those functions when a signal’s value changes

Let update our signal and computed implementations to support that.

First, we define a global currentSubscriber variable. When a computed function runs, it registers itself as the currentSubscriber. Then when a signal is read, it stores this subscriber in its list.

let currentSubscriber: (() => void) | null = null;

Update signal():

function signal<T>(initial: T): WritableSignal<T> {
  let value = initial;
  const subscribers = new Set<() => void>();

  const getValue = () => {
+    if (currentSubscriber) {
+      subscribers.add(currentSubscriber);
+    }
    return value;
  };

  getValue.set = (newValue: T) => {
    value = newValue;
+    for (const sub of subscribers) {
+      sub();
+    }
  };

  return getValue as WritableSignal<T>;
}

Now update computed():

function computed<T>(fn: () => T): Signal<T> {
  let value: T;

+  const recompute = () => {
+    currentSubscriber = recompute;
+    value = fn();
+    currentSubscriber = null;
+  };

+  recompute();

  const getValue = () => value;

  return getValue;
}

Usage:

const count = signal(1);
const doubleCount = computed(() => count() * 2);

console.log(doubleCount()); // 2

count.set(5);

console.log(doubleCount()); // 10

Why this works

When computed(fn) runs, it sets currentSubscriber to its recompute function.
Any signals accessed during fn() will store recompute as a subscriber.
Later, when count.set(5) is called, the count signal notifies its subscribers, which includes recompute.
So recompute() is called, and value is updated.
Now doubleCount() will return the updated value.

This is the minimal reactive system: signals track dependencies via subscriptions, and computed values get updated automatically.

Source Code

References

Learn Angular Signals By Writing Your Own | Corbin Crutchley

Cursor: Customize Your Sidebar Like VS Code

Sun, 02 Mar 2025 01:30:00 GMT

If you’re transitioning from VS Code to Cursor Editor and miss the familiar sidebar layout, you’re not alone. In VS Code, the sidebar is on the left side and has that small but helpful git icon that shows how many files have been changed. In Cursor, if you collapse the sidebar, you can’t access it anymore since it moves to the top.

Let’s compare the default Cursor layout with VS Code’s interface:

1. Open Up Cursor Settings

Launch Cursor Editor
Press ⌘ Shift P and type in Preferences: Open User Settings

Search for activity bar in the settings search box
Look for the Activity Bar: Orientation setting
Switch it from horizontal to vertical

3. Check It Out

Now your sidebar sits on the left, just like in VS Code!

Bonus Tip: Make Cursor Look More Like VS Code

I found Cursor’s default theme (Anysphere Dark) a bit too dark for my taste. If you’re like me and prefer VS Code’s look, here’s how to change it:

1. Get to the Theme Settings

Open up the command palette again (⌘ Shift P) and look for Preferences: Color Theme

2. Pick VS Code’s Theme

Choose Dark+ (Default Dark+) from the list

And there you have it! Now your Cursor looks pretty much identical to VS Code

bundle install: Could not find MIME type database in the following locations

Wed, 26 Feb 2025 13:30:00 GMT

Problem

I am running bundle install on a Ruby project and I got the following error:

Using dry-validation 1.10.0
Installing mimemagic 0.4.3 with native extensions
Installing rmagick 5.5.0 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    current directory: /Users/trung.vo/.asdf/installs/ruby/3.1.5/lib/ruby/gems/3.1.0/gems/mimemagic-0.4.3/ext/mimemagic
/Users/trung.vo/.asdf/installs/ruby/3.1.5/bin/ruby -I/Users/trung.vo/.asdf/installs/ruby/3.1.5/lib/ruby/3.1.0 -rrubygems
/Users/trung.vo/.asdf/installs/ruby/3.1.5/lib/ruby/gems/3.1.0/gems/rake-13.2.1/exe/rake
RUBYARCHDIR\=/Users/trung.vo/.asdf/installs/ruby/3.1.5/lib/ruby/gems/3.1.0/extensions/arm64-darwin-24/3.1.0/mimemagic-0.4.3
RUBYLIBDIR\=/Users/trung.vo/.asdf/installs/ruby/3.1.5/lib/ruby/gems/3.1.0/extensions/arm64-darwin-24/3.1.0/mimemagic-0.4.3
rake aborted!
Could not find MIME type database in the following locations: ["/usr/local/share/mime/packages/freedesktop.org.xml", "/opt/homebrew/share/mime/packages/freedesktop.org.xml",
"/opt/local/share/mime/packages/freedesktop.org.xml", "/usr/share/mime/packages/freedesktop.org.xml"]

Ensure you have either installed the shared-mime-info package for your distribution, or
obtain a version of freedesktop.org.xml and set FREEDESKTOP_MIME_TYPES_PATH to the location
of that file.

Tasks: TOP => default
(See full trace by running task with --trace)

rake failed, exit code 1

Gem files will remain installed in /Users/trung.vo/.asdf/installs/ruby/3.1.5/lib/ruby/gems/3.1.0/gems/mimemagic-0.4.3 for inspection.
Results logged to /Users/trung.vo/.asdf/installs/ruby/3.1.5/lib/ruby/gems/3.1.0/extensions/arm64-darwin-24/3.1.0/mimemagic-0.4.3/gem_make.out

Here’s what the error looks like in the terminal:

Solution

First, install the shared-mime-info package using Homebrew:

brew install shared-mime-info

After fixing the MIME type issue, you might encounter another error related to RMagick:

An error occurred while installing rmagick (5.5.0), and Bundler cannot continue.

To fix this, install ImageMagick:

brew install imagemagick

Output

After installing both required packages, running bundle install again should complete successfully:

Using mustermann 3.0.0
Using mimemagic 0.4.3
Using rubocop 1.63.2
Using listen 3.9.0
Using rspec 3.13.0
Using aws-sdk-s3 1.147.0
Using sidekiq-scheduler 5.0.3
Using elasticsearch 7.13.0
Using dry-validation 1.10.0
Using sinatra 3.2.0
Using guard 2.18.1
Using sinatra-contrib 3.2.0
Using guard-rack 2.2.1
Using guard-bundler 3.0.1
Using guard-sidekiq 0.1.0
Installing rmagick 5.5.0 with native extensions
Bundle complete! 50 Gemfile dependencies, 157 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

Wow, it works!

Netlify Redirects vs Gatsby Redirects: My Traffic Drop 90%

Fri, 10 Jan 2025 10:30:00 GMT

This blog was originally built with Jekyll, but due to the challenges of running and maintaining it locally, I migrated to Gatsby. Initially, I retained the /experience/:slug path for my blog posts to avoid losing traffic. However, I later decided to change the path to /blog/:slug, which unfortunately led to a significant 90% drop in traffic. Here’s what happened and how I attempted to fix it.

In early December 2024, I naively added createRedirect in gatsby-node.js to redirect the old path to the new one.

createPage({
-  path: `/experience/${slug}`,
+  path: `/blog/${slug}`,
  component: slash(postTemplate),
  context: { slug },
})
// Redirect from /experience/slug to /blog/slug
+ createRedirect({
+   fromPath: `/experience/${slug}`,
+   toPath: `/blog/${slug}`,
+   isPermanent: true,
+   redirectInBrowser: true,
+ });

I suspect the traffic drop was due to Google indexing the old /experience/:slug paths and returning 404 errors because Gatsby redirects happen on the client side.

When you curl the page, it still returns a 404. In a browser, you see a 404 momentarily before being redirected to the new page. The 404 errors likely caused Google to remove the experience pages from search results, significantly impacting my traffic.

To resolve this, I needed to ensure that Google indexing the old /experience/:slug paths would return a 301 redirect to the new /blog/:slug paths. I decided to use Netlify redirects, which are easy to implement. I added the new redirect rules to the _redirects file in the static folder.

+ /experience/*              /blog/:splat

This redirects paths like /experience/image-lazy-load to /blog/image-lazy-load at the hosting level, returning a proper 301 HTTP code. Learn more about Netlify wildcard redirects here.

For now, I will push the changes and monitor the traffic to see if it recovers.

The second attempt

After completing the blog, I realized that a 301 status code would still prevent Google from indexing the page. Therefore, I needed another solution.

I decided to rewrite the URL from /experience/:slug to /blog/:slug using Netlify’s _redirects file. Here’s how I did it:

When you assign an HTTP status code of 200 to a redirect rule, it becomes a rewrite. This means that the URL in the visitor’s address bar remains the same, while Netlify’s servers fetch the new location behind the scenes.

- /experience/*              /blog/:splat
+ /experience/*              /blog/:splat  200

This is similar to the redirect rule, but by adding the status code 200, it becomes a rewrite. This means that when I curl the page, it will return a 200 status code and could potentially be indexed by Google.

It appears that after implementing the changes, the traffic is starting to recover. I’m not certain if this improvement is due to the rewrite or merely coincidental. I will keep monitoring the traffic and update this blog with any new developments.

Update Feb 2025

Traffic is recovering; I am now getting about 90 clicks per day compared to peak periods of 160 clicks in the past six months.

Understanding staleTime and gcTime (cacheTime) in React Query

Tue, 24 Dec 2024 12:30:00 GMT

In React Query, two key options control the freshness and caching duration of query results: staleTime and gcTime (formerly cacheTime).

Here’s a brief explanation of each:

staleTime: The duration a query result is considered fresh. While fresh, data is read from the cache only, with no network requests. Once stale (default is instantly), data is still read from the cache, but a background refetch can happen under certain conditions.
gcTime: The duration inactive queries remain in the cache before being removed. This defaults to 5 minutes. Queries become inactive when no components are observing them.

Typically, you may need to adjust staleTime more often than gcTime.

staleTime

To understand staleTime, consider a simple example of a hook to fetch a single vehicle:

export const useFetchVehicle = (vehicleId: string | undefined) => {
  const [vehicle, setVehicle] = useState<Vehicle | null>(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);
  useEffect(() => {
    const init = async () => {
      try {
        const data: Vehicle = await fetchVehicle(vehicleId);
        setVehicle(data);
      } catch (err) {
        setError((err as Error).message);
      } finally {
        setLoading(false);
      }
    };
    init();
  }, [vehicleId]);
  return { vehicle, loading, error };
};

Using React Query, we can simplify this with the useQuery hook, eliminating the need for useState and useEffect:

import { useQuery } from '@tanstack/react-query’;

export const useFetchVehicle = (vehicleId: string | undefined) => {
  return useQuery({
    queryKey: ['vehicle', vehicleId],
    queryFn: () => fetchVehicle(vehicleId),
  });
};

Default `staleTime` of `0`

In the above code, useQuery manages the loading, error, and data states. The queryKey uniquely identifies the query, and queryFn fetches the data. Since staleTime is not set, it defaults to 0.

Notice how selecting the first item triggers an API call for /vehicle/1. Returning to the list and selecting the first item again triggers another API call. The UI renders immediately with cached data, but a background refetch happens due to the default staleTime of 0.

In DevTools, ['vehicle', '1'] is considered stale immediately with staleTime set to 0.

A background refetch can happen when:

New instances of the query mount
The window is refocused
The network is reconnected
The query is configured with a refetch interval

Setting `staleTime` to another value

Consider setting staleTime to 30 seconds (30 * 1000 milliseconds):

export const useFetchVehicle = (vehicleId: string | undefined) => {
  return useQuery({
    queryKey: ['vehicle', vehicleId],
    queryFn: () => fetchVehicle(vehicleId),
+   staleTime: 30 * 1000,
  });
};

Now, selecting the first item triggers an API call for /vehicle/1. Returning to the list and selecting the first item again does not trigger an API call. The UI renders immediately with cached data, considered fresh for 30 seconds, with no background refetch.

In DevTools, ['vehicle', '1'] is considered fresh for 30 seconds with staleTime set to 30 seconds.

Why the default `staleTime` is `0`

Quoted from UI Dev Data Synchronization.

The default staleTime of 0 means every query is instantly considered stale. This “aggressive but sane default” ensures frequent refetching, which is generally safer than fetching too infrequently.

The docs define this as “aggressive but sane defaults”.

Aggressive, because it means we might be refetching from the server more often than we need to, but sane because fetching too often is the lesser evil of the two options.

It’s a bit like re-renders in React. Yes, we all want to minimize our application’s re-renders, but having too many is significantly better than having too little where your view could be out of sync with your application’s state.

Also, if the default value weren’t 0, what would be a better default? 20 seconds? 30? 1 minute? It’s one of those cases that you can’t reliably set up for every possible situation. The answer is always it depends.

Specifically, it depends on the resource in question: How often is it updated? How accurate does the data displayed on your screen need to be? How collaborative is the environment you’re working in?

The answer to these questions should be decided by developers on a case by case basis.

If we fetch a Twitter post with all its likes and comments, it’s likely stale pretty fast. On the other hand, if we fetch exchange rates that update on a daily basis, well, our data is going to be quite accurate for some time even without refetching.

cacheTime (gcTime)

cacheTime does nothing while a query is in use. It activates once the query becomes unused, removing data from the cache after the specified duration (default is 5 minutes).

The time in milliseconds that unused/inactive cache data remains in memory. When a query’s cache becomes unused or inactive, that cache data will be garbage collected after this duration. When different garbage collection times are specified, the longest one will be used.

Defaults to 5 * 60 * 1000 (5 minutes) or Infinity during SSR.
Note: the maximum allowed time is about 24 days. See more at useQuery.
If set to Infinity, garbage collection is disabled.
gc refers to “garbage collect” time, a common term in computer science.

For example, the ['vehicle', '1'] query is removed from the cache after 5 minutes of inactivity.

In React Query v5, the cacheTime option has been renamed to gcTime.

Reference

Creating Fast-Feeling Web Apps

I recently gave a 30-minute version of my talk, Creating Fast-Feeling Web Apps, at JSConfJP in Tokyo, one of the largest web developer events in Japan. The feedback from attendees was fantastic. During the talk, I covered topics like staleTime in React Query and how to use initialData to deliver an instant user experience. You can check out the slides and the recorded talk for more details

Chrome DevTools Performance Panel: Analyze Your Website's Performance

Thu, 14 Nov 2024 14:30:00 GMT

The Performance panel in Chrome DevTools allows you to record and analyze CPU performance profiles of your web applications. Use it to identify performance bottlenecks and optimize resource usage.

Key Features of the Performance Panel

Record a performance profile.
Adjust capture settings.
Analyze performance reports.

Opening the Performance Panel

To open the Performance panel, launch DevTools and select the Performance tab.

Alternatively, you can use the Command menu:

Open DevTools.
Open the Command menu:

macOS: Command+Shift+P
Windows, Linux, ChromeOS: Control+Shift+P

Type Performance, select Show Performance panel, and press Enter.

Monitoring Core Web Vitals Live

Upon opening the Performance panel, it immediately displays your local Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics, along with their scores (good, needs improvement, or bad).

Interacting with your page also captures your local Interaction to Next Paint (INP) score, providing a comprehensive overview of your page’s Core Web Vitals.

Under the Interactions and Layout shifts tabs, you can find detailed tables of captured interactions and layout shifts, including elements, timings, phases (for interactions), and scores (for layout shifts). To clear these lists, click Clear.

Comparing Local Metrics with User Experience

You can fetch field data from the Chrome UX Report to compare your site’s user experience with your local metrics.

To add field data:

In Performance > Next steps > Field data, click Set up.

In the Configure field data fetching dialog, review the Privacy disclosure, and click Ok.

With field data fetching enabled, the Performance panel compares your local metric scores with those experienced by your users. The collection period is displayed in the Field data section on the right.

If your website data is not fully available in the Chrome UX Report, you might see limited metrics, such as a CLS score of 0.

For other sites like web.dev, you can see a detailed comparison between local metrics and field data:

Configuring Your Environment to Match User Conditions

Expand the Consider your local test conditions section.

Typical user environments:

Device: 79% mobile, 21% desktop
Network: 75th percentile similar to Slow 4G throttling

In the Environment settings section, set the Network drop-down to Slow 4G.
Reload the page, interact with it to capture your local INP, and compare the metric scores again.

Improving Core Web Vitals

Start optimizing your website’s Core Web Vitals:

References

Chrome DevTools Performance panel

Configuring Cloudflare Images and fixing ERROR 9421: Too many redirects

Tue, 29 Oct 2024 14:30:00 GMT

Modern websites are rich with images, videos, and other media, making image optimization crucial for faster load times. Images can be part of your codebase or sourced externally, such as hotel images from suppliers stored on cloud services like AWS S3.

For images from your design team, request compression before use if possible. However, sometimes you might forget to optimize images before uploading. For external images, third-party services like Cloudflare Images or Cloudinary can help.

Using Cloudflare Images with my domain trungvose.com, I leveraged two features:

Efficient storage and delivery of images with dynamic variants.
Optimization of externally stored images via transformation requests.

With GatsbyJS and my images deployed on Netlify, I use Cloudflare Images to optimize externally stored images.

Enable Transformation

Transformations let you optimize images stored outside of Cloudflare Images. Cloudflare will automatically cache every transformed image on its global network, so you only need to store the original image at your origin.

Log in to the Cloudflare dashboard and select your account.
Go to Images > Transformations.
Select the domain where you want to enable transformations.
Click Enable.

After clicking Enable, the button will change to Disable, indicating that transformations are now enabled for your domain.

Transform Images

After enabling transformations, you can now transform images using two approaches:

Using a specially-formatted URL.
Through Cloudflare Workers.

Supported Input Formats

JPEG
PNG
GIF (including animations)
WebP (including animations)
SVG

Using a Specially-Formatted URL

To get started, I’ll use a specially-formatted URL. You can read more here.

You can convert and resize images by requesting them via a specially-formatted URL. This way, you do not need to write any code, only change the HTML markup of your website to use the new URLs. The format is:

https://<ZONE>/cdn-cgi/image/<OPTIONS>/<SOURCE-IMAGE>

<ZONE>: Your domain, e.g., trungvose.com.
/cdn-cgi/image/: A fixed prefix that identifies this as a special path handled by Cloudflare’s built-in Worker. This path will work when you have enabled transformations for your domain.
<OPTIONS>: A comma-separated list of options such as width, height, and quality.
<SOURCE-IMAGE>: The URL of the original image.

Example

I have this image inside my source code, uploaded to Netlify:

https://trungvose.com/img/speaking/2024-10-19-javascript-bangkok-01.jpg

Applying the above, the optimized image URL with a width of 1280px would be:

https://trungvose.com/cdn-cgi/image/format=auto,width=1280/img/speaking/2024-10-19-javascript-bangkok-01.jpg

Error 9421: Too Many Redirects

After opening the above image URL in the browser, I encountered this error:

Error 9421: Too many redirects

Searching Google, I found a Cloudflare community post that explains the issue.

Cloudflare Community Post: Pages&Images: ERROR 9421: Too many redirects

The post mentioned:

If your site’s SSL/TLS mode is set to “Flexible”, change it to “Full (strict)”. Pages does not work with plain HTTP traffic, only HTTPS.

I changed the SSL/TLS mode to Full (strict), and the issue was resolved.

Result and Comparison

Before

The original image:

https://trungvose.com/img/speaking/2024-10-19-javascript-bangkok-01.jpg

Size: 3.8MB
Dimensions: 4032 x 3024
Format: image/jpeg

After

The optimized image:

https://trungvose.com/cdn-cgi/image/format=auto,width=1280/img/speaking/2024-10-19-javascript-bangkok-01.jpg

Size: 243KB
Dimensions: 1280 x 960
Format: image/avif

Cloudflare Dashboard

In the Cloudflare dashboard, you can view detailed metrics for transformed images, including:

Bandwidth Saved: The amount of data saved by using optimized images.
Original Size: The size of the image before transformation.
Resized: The size of the image after transformation.

Conclusion

Cloudflare Images is a powerful tool to optimize images stored outside of Cloudflare. By enabling transformations, you can resize, convert, and optimize images on the fly. If you encounter ERROR 9421: Too many redirects, check your SSL/TLS mode and ensure it is set to Full (strict).

While URL transformation is straightforward, it lacks the flexibility of Cloudflare Workers, which allow for custom image transformations. In a future article, I’ll explore using Cloudflare Workers. Here are some advantages:

Custom URL schemes: Use preset names like thumbnail and large instead of pixel dimensions.
Hide original image locations: Store images in an external S3 bucket or a hidden server folder without exposing URLs.
Content negotiation: Dynamically adapt image sizes, formats, and quality based on device and network conditions.

Sharing my go-to Gmail filter to clean up unnecessary Calendar notifications

Wed, 25 Sep 2024 02:10:00 GMT

We don’t need to receive notifications when attendees Accepted invites. It’s more useful to be notified if they Decline, Tentatively Accept, or Propose a new time. With this filter, all Calendar notifications will be tagged with a Calendar label, and Accepted notifications will automatically be archived, keeping your inbox cleaner.

How to set it up:

In the search bar, paste this:

filename:invite.ics AND "accepted" -{"tentatively" OR "proposed" OR "appointment booked" OR "updated invitation"}

Click the Show search options button.
When the panel open, click Search button

Set the following options:

Skip the Inbox (Archive it)
Mark as read
Apply the label: Create a label called “Calendar”
Apply the filter to all matching conversations to clean up previous emails as well.

Then click Create filter

Now, all Accepted calendar notifications will be automatically archived so they won’t clutter your inbox.

Reference

Day 1: Essential Gmail Filters for Focus by Jeff Su

TypeScript is Operator for Type Narrowing

Sun, 22 Sep 2024 08:30:00 GMT

Problem

TypeScript’s Control Flow Analysis is generally effective at narrowing types. For instance, starting from TypeScript 4.4, type guards can influence control flow more effectively. Consider the following example:

// In TS 4.3 and below
function foo(arg: unknown) {
  const argIsString = typeof arg === "string";
  if (argIsString) {
    console.log(arg.toUpperCase());
    //              ~~~~~~~~~~~
    // Error! Property 'toUpperCase' does not exist on type 'unknown'.
  }
}

In earlier versions of TypeScript, even though argIsString is assigned the result of a type guard (typeof arg === "string"), TypeScript would lose that information, resulting in an error. In TypeScript 4.4 and above, the control flow is improved, and this issue is resolved:

// In TS 4.4 and above
function foo(arg: unknown) {
  const argIsString = typeof arg === "string";
  if (argIsString) {
    console.log(arg.toUpperCase()); // No error, TypeScript knows arg is a string now.
  }
}

However, there are still situations where TypeScript’s type inference falls short. For example, when filtering an array that contains undefined, null, or other falsy values, TypeScript can’t determine whether the filtered array is completely truthy.

const fruits = ['apple', undefined, 'banana', undefined, 'cherry']; // (string | undefined)[]

const filteredFruits = fruits.filter(item => !!item); // (string | undefined)[]

Even though the undefined values have been filtered out, TypeScript still thinks the result is of type (string | undefined)[], instead of string[]. This can lead to type issues down the line, requiring manual type assertions or dealing with incorrect type assumptions.

Solution

To resolve this, you can use a custom type guard with TypeScript’s is operator, which explicitly informs TypeScript of the correct type. Here’s how to create an isTruthyPredicate function:

export function isTruthyPredicate<SomeType>(
  item: SomeType | boolean | null | undefined,
): item is SomeType {
  return !!item;
}

This predicate ensures that TypeScript understands when an item is truthy. By using this function in a filter operation, you can ensure TypeScript infers the correct type:

const filteredFruitsOnlyTruthy = fruits.filter(isTruthyPredicate); // string[]

Now, filteredFruitsOnlyTruthy is correctly inferred as string[], eliminating the need for type assertions and making the code safer.

Why use the is Operator for Type Narrowing?

When searching, I found this answer is sensible too.

https://stackoverflow.com/q/51124837/3375906

In TypeScript, a boolean is just a data type that can be either true or false, whereas the is operator is specifically used for type-testing. It tells TypeScript that a particular condition not only checks a value but also narrows down its type. Let’s take a look at an example to understand the difference:

type Species = 'cat' | 'dog';

interface Pet {
    species: Species;
}

class Cat implements Pet {
    public species: Species = 'cat';
    public meow(): void {
        console.log('Meow');
    }
}

function petIsCat(pet: Pet): pet is Cat {
    return pet.species === 'cat';
}

function petIsCatBoolean(pet: Pet): boolean {
    return pet.species === 'cat';
}

const p: Pet = new Cat();

p.meow(); // ERROR: Property 'meow' does not exist on type 'Pet'.

if (petIsCat(p)) {
    p.meow(); // Now the compiler knows for sure that 'p' is of type Cat, and it has a 'meow' method
}

if (petIsCatBoolean(p)) {
    p.meow(); // ERROR: Property 'meow' does not exist on type 'Pet'.
}

In this example:

petIsCat is a custom type guard using the is operator. It tells TypeScript that if the condition is true, the pet is of type Cat, and thus, the meow method is available.
petIsCatBoolean only returns a boolean, and while it performs the same check, it doesn’t narrow the type. As a result, TypeScript doesn’t know that p is a Cat and throws an error when trying to access meow.

Playground Example

You can see the full example in the TypeScript playground here.

Conclusion

While TypeScript’s Control Flow Analysis has improved over the years, as seen in features introduced in TypeScript 4.4, there are still cases, like filtering out falsy values, where the type inference doesn’t work as expected. In such situations, custom type predicates using the is operator can be a clean and effective solution to ensure TypeScript narrows types properly, improving both safety and developer experience.

nvm keeps "forgetting" node version in new VSCode terminal sessions

Tue, 10 Sep 2024 15:50:00 GMT

Problem

In my project, we define engines in package.json like this:

"engines": {
  "node": ">=20.10.0",
  "pnpm": "9.9.0"
}

Recently, when I run a pnpm command, I encountered this error:

Your Node version is incompatible with "/Users/trung.vo/project-a".

Expected version: >=20.10.0
Got: v18.19.1

This is happening because the package's manifest has an engines.node field specified.
To fix this issue, install the required Node version.

I checked the Node version on my machine:

node -v
v18.19.1

I then installed the correct version of Node using nvm and set the default version to 20.10.0:

nvm install 20.10.0
nvm alias default 20.10

However, when I opened a new terminal session in VSCode, the Node version reverted to 18.19.1. See the following gif for more details:

Solution

After exploring multiple Stack Overflow questions, I finally found a working solution.

You need to add the following line at the TOP of your .bashrc or .zshrc file, before anything else:

PATH="/usr/local/bin:$(getconf PATH)"

In my case, I am using oh-my-zsh and the VSCode integrated terminal. Adding the line above to my .zshrc file resolved the issue.

The reason, as explained in the answers below:

Apparently, nvm does not get along with integrated terminals or subshells in these editors. When loading them, the environment variable $PATH is modified internally. According to a comment by one of the contributors of this package in the issue reported NVM fails to load within nested shell #1652:

@charsleysa I know why nvm is throwing this error. In your subshell, somehow the /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin part of your PATH has been moved from the end of the PATH to the start. When nvm is then started, it calls nvm_change_path (my contribution changed it to this from nvm_prepend_path), which modifies the nvm-relevant part of the path in place.

After adding the line above to my .zshrc file, I ran nvm alias default 20.10 again. Upon opening a new terminal session in VSCode, the Node version was correctly set to 20.10.0.

Improve Interaction to Next Paint (INP)

Wed, 14 Aug 2024 08:30:00 GMT

Imagine you’re at a restaurant. You place your order, and the waiter immediately acknowledges it with a nod or a smile. This quick response reassures you that your order is being processed. Now, think about a situation where the waiter ignores you for a while before acknowledging your order. You might feel frustrated or think that your order wasn’t taken. This is similar to how web pages should respond to user interactions.

Understanding INP

Chrome usage data shows that 90% of a user’s time on a page is spent after it loads. Thus, careful measurement of responsiveness throughout the page lifecycle is important. This is what the INP metric assesses.

Good responsiveness means that a page responds quickly to interactions. When a page responds to an interaction, the browser presents visual feedback in the next frame that it paints. Visual feedback tells you if, for example, an item you add to an online shopping cart is indeed being added, whether a mobile navigation menu has opened, if a login form’s contents are being authenticated by the server, and so forth.

Some interactions naturally take longer than others, but for especially complex interactions, it’s important to quickly present some initial visual feedback to tell the user that something is happening. The next frame that the browser will paint is the earliest opportunity to do this.

Therefore, the intent of INP is not to measure all the eventual effects of an interaction—such as network fetches and UI updates from other asynchronous operations—but the time that the next paint is being blocked. By delaying visual feedback, users may get the impression that the page is not responding quickly enough, and INP was developed to help developers measure this part of the user experience.

In the following video, the example on the right gives immediate visual feedback that an accordion is opening. Poor responsiveness is demonstrated in the example on the left, and how it can create poor user experiences.

An example of poor versus good responsiveness. On the left, long tasks block the accordion from opening. This causes the user to click multiple times, thinking the experience is broken. When the main thread catches up, it processes the delayed inputs, resulting in the accordion opening and closing unexpectedly. On the right, a more responsive page opens the accordion quickly and without incident.

First Input Delay (FID)

As of March 2024, Interaction to Next Paint (INP) will replace the First Input Delay (FID) as a new Core Web Vital.

First Input Delay is a web performance metric that measures the time between a user’s very first interaction with a web page and the time when the browser’s main thread is able to start processing that interaction event.

When a user interacts with a web page, an event is added to a queue to be processed by the browser’s main thread. However, if the main thread is already busy doing other tasks like parsing HTML, executing JavaScript, or handling other event listeners, the new event has to wait in the queue.

The FID metric captures the duration of this waiting time, which tells us how long it takes for the browser to respond to the user’s first input while the main thread is busy.

However, the First Input Delay (FID) metric has some shortcomings:

FID only considers the delay of the first input event, ignoring subsequent interactions that may also be slow or even slower.
Other factors can contribute to a longer visual feedback delay between user interactions, which FID doesn’t measure. This includes the time it takes to process event handlers and recalculate the layout before providing visual feedback to the user.

Interaction to Next Paint (INP)

To address these limitations, the Interaction to Next Paint (INP) metric will replace First Input Delay. INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page. The final INP value is the longest interaction observed, ignoring outliers.

While FID only measured the input delay, which is the time between user input and the browser starting to execute the event handler, INP measures:

Input Delay: the time between user interaction and the time the browser is able to process the event, similar to FID.
Processing Delay: the time it takes the browser to process the event handlers.
Presentational Delay: the time it takes the browser to recalculate the layout and paint the pixels to the screen.

Additionally, whereas FID only measured the very first user interaction, the INP score is measured when the user leaves the page by aggregating all interactions the user made with the page throughout the page’s lifetime and returning the worst-measured score.

With INP, we no longer have to focus solely on optimizing event queuing times and main thread availability, as was the case with FID. Now, it is also crucial to address the entire lifecycle of a user interaction. This includes processing event handlers, recalculating layouts, and painting updates to the screen, all of which are critical components of the INP metric.

What is a good INP score?

Pinning labels such as “good” or “poor” on a responsiveness metric is difficult. On one hand, you want to encourage development practices that prioritize good responsiveness. On the other hand, you must account for the fact that there’s considerable variability in the capabilities of devices people use to set achievable development expectations.

To ensure you’re delivering user experiences with good responsiveness, a good threshold to measure is the 75th percentile of page loads recorded in the field, segmented across mobile and desktop devices:

An INP below or at 200 milliseconds means a page has good responsiveness.
An INP above 200 milliseconds and below or at 500 milliseconds means a page’s responsiveness needs improvement.
An INP above 500 milliseconds means a page has poor responsiveness.

What is an interaction?

For the purposes of INP, only the following interaction types are observed:

Clicking with a mouse.
Tapping on a device with a touchscreen.
Pressing a key on either a physical or onscreen keyboard.

Interactions can consist of multiple events. For example, a keystroke includes the keydown, keypress, and keyup events. Tap interactions contain pointerup and pointerdown events. The event with the longest duration within the interaction is what contributes to the interaction’s total latency.

The most important: Avoiding long tasks

Common advice for keeping JavaScript apps fast tends to boil down to the following advice:

“Don’t block the main thread.”
“Break up your long tasks.”

This is great advice, but what work does it involve? Shipping less JavaScript is good, but does that automatically equate to more responsive user interfaces? Maybe, but maybe not.

To understand how to optimize tasks in JavaScript, you first need to know what tasks are, and how the browser handles them.

What is a task?

A task is any discrete piece of work that the browser does. That work includes rendering, parsing HTML and CSS, running JavaScript, and other types of work you may not have direct control over. Of all of this, the JavaScript you write is perhaps the largest source of tasks.

A task started by a click event handler in, shown in Chrome DevTools’ performance profiler.

Tasks associated with JavaScript impact performance in a couple of ways:

When a browser downloads a JavaScript file during startup, it queues tasks to parse and compile that JavaScript so it can be executed later.
At other times during the life of the page, tasks are queued when JavaScript does work such as responding to interactions through event handlers, JavaScript-driven animations, and background activity such as analytics collection.

All of this stuff—with the exception of web workers and similar APIs—happens on the main thread.

What is the main thread?

The main thread is where most tasks run in the browser, and where almost all JavaScript you write is executed.

The main thread can only process one task at a time. Any task that takes longer than 50 milliseconds is a long task. For tasks that exceed 50 milliseconds, the task’s total time minus 50 milliseconds is known as the task’s blocking period.

A long task as depicted in Chrome’s performance profiler. Long tasks are indicated by a red triangle in the corner of the task, with the blocking portion of the task filled in with a pattern of diagonal red stripes.

To prevent the main thread from being blocked for too long, you can break up a long task into several smaller ones.

A visualization of a single long task versus that same task broken up into five shorter tasks.

Task management strategies

A common piece of advice in software architecture is to break up your work into smaller functions:

function saveSettings () {
  validateForm();
  showSpinner();
  saveToDatabase();
  updateUI();
  sendAnalytics();
}

In this example, there’s a function named saveSettings() that calls five functions to validate a form, show a spinner, send data to the application backend, update the user interface, and send analytics.

Conceptually, saveSettings() is well-architected. If you need to debug one of these functions, you can traverse the project tree to figure out what each function does. Breaking up work like this makes projects easier to navigate and maintain.

A potential problem here, though, is that JavaScript doesn’t run each of these functions as separate tasks because they are executed within the saveSettings() function. This means that all five functions will run as one task.

In the best case scenario, even just one of those functions can contribute 50 milliseconds or more to the task’s total length. In the worst case, more of those tasks can run much longer—especially on resource-constrained devices.

In this case, saveSettings() is triggered by a user click, and because the browser isn’t able to show a response until the entire function is finished running, the result of this long task is a slow and unresponsive UI, and will be measured as a poor Interaction to Next Paint (INP).

Manually defer code execution

To make sure important user-facing tasks and UI responses happen before lower-priority tasks, you can yield to the main thread by briefly interrupting your work to give the browser opportunities to run more important tasks.

One method developers have used to break up tasks into smaller ones involves setTimeout(). With this technique, you pass the function to setTimeout(). This postpones execution of the callback into a separate task, even if you specify a timeout of 0.

function saveSettings () {
  // Do critical work that is user-visible:
  validateForm();
  showSpinner();
  updateUI();

  // Defer work that isn't user-visible to a separate task:
+  setTimeout(() => {
    saveToDatabase();
    sendAnalytics();
+  }, 0);
}

This is known as yielding, and it works best for a series of functions that need to run sequentially.

However, your code may not always be organized this way. For example, you could have a large amount of data that needs to be processed in a loop, and that task could take a very long time if there are many iterations.

function processData () {
  for (const item of largeDataArray) {
    // Process the individual item here.
  }
}

Using setTimeout() here is problematic because of developer ergonomics, and after five rounds of nested setTimeout()s, the browser will start imposing a minimum 4 millisecond delay for each additional setTimeout().

A dedicated yielding API: scheduler.yield()

scheduler.yield() is an API specifically designed for yielding to the main thread in the browser. Currently supported on Chrome 129.

It’s not language-level syntax or a special construct; scheduler.yield() is just a function that returns a Promise that will be resolved in a future task. Any code chained to run after that Promise is resolved (either in an explicit .then() chain or after awaiting it in an async function) will then run in that future task.

In practice: insert an await scheduler.yield() and the function will pause execution at that point and yield to the main thread. The execution of the rest of the function—called the continuation of the function—will be scheduled to run in a new event-loop task. When that task starts, the awaited promise will be resolved, and the function will continue executing where it left off.

async function saveSettings () {
  // Do critical work that is user-visible:
  validateForm();
  showSpinner();
  updateUI();

  // Yield to the main thread:
  await scheduler.yield()

  // Work that isn't user-visible, continued in a separate task:
  saveToDatabase();
  sendAnalytics();
}

The real benefit of scheduler.yield() over other yielding approaches, though, is that its continuation is prioritized, which means that if you yield in the middle of a task, the continuation of the current task will run before any other similar tasks are started.

This avoids code from other task sources from interrupting the order of your code’s execution, such as tasks from third-party scripts.

Cross-browser support

scheduler.yield() is not yet supported in all browsers, so a fallback is needed.

function yieldToMain () {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }

  // Fall back to yielding with setTimeout.
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

Conclusion

Managing tasks is challenging, but doing so ensures that your page responds more quickly to user interactions. There’s no one single piece of advice for managing and prioritizing tasks, but rather a number of different techniques. To reiterate, these are the main things you’ll want to consider when managing tasks:

Yield to the main thread for critical, user-facing tasks.
Use scheduler.yield() (with a cross-browser fallback) to ergonomically yield and get prioritized continuations

References

An error occurred while installing pg (1.5.6), and Bundler cannot continue (when running rails new)

Sat, 20 Jul 2024 06:50:00 GMT

I am installing rails to demonstrate how a traditional server-side rendered web application works on my Mac M2, Sonoma 14.5.

I have followed the instructions from here

Install Ruby

git clone https://github.com/excid3/asdf.git ~/.asdf
echo '. "$HOME/.asdf/asdf.sh"' >> ~/.zshrc
echo '. "$HOME/.asdf/completions/asdf.bash"' >> ~/.zshrc
echo 'legacy_version_file = yes' >> ~/.asdfrc
exec $SHELL

asdf plugin add ruby
asdf install ruby 3.3.3
asdf global ruby 3.3.3

Confirm that the default Ruby version matches the installed version:

which ruby
#=> /Users/username/.asdf/shims/ruby
ruby -v
#=> 3.3.3

Installing Rails

To install Rails, run the following command:

gem install rails -v 7.1.3.4
rails -v
# Rails 7.1.3.4

Create a new Rails app

To create a new Rails app, use the following command:

rails new music-rails --database=postgresql

Here, I encountered the following error as mentioned on the blog title:

Fetching gem metadata from https://rubygems.org/.........
Installing pg 1.5.6 with native extensions
+ Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    current directory: /Users/trung.vo/.asdf/installs/ruby/3.3.3/lib/ruby/gems/3.3.0/gems/pg-1.5.6/ext
/Users/trung.vo/.asdf/installs/ruby/3.3.3/bin/ruby extconf.rb
Calling libpq with GVL unlocked
checking for pg_config... no
checking for libpq per pkg-config... no
Using libpq from 
checking for libpq-fe.h... no
Can't find the 'libpq-fe.h header
*****************************************************************************

+ Unable to find PostgreSQL client library.

Please install libpq or postgresql client package like so:
  brew install libpq

or try again with:
  gem install pg -- --with-pg-config=/path/to/pg_config

or set library paths manually with:
  gem install pg -- --with-pg-include=/path/to/libpq-fe.h/ --with-pg-lib=/path/to/libpq.so/

*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

*** removed for brevity ***

+ An error occurred while installing pg (1.5.6), and Bundler cannot continue.

In Gemfile:
  pg
     run  bundle lock --add-platform=x86_64-linux
Writing lockfile to /Users/trung.vo/Source/view-transitions-demo/music-rails/Gemfile.lock
     run  bundle lock --add-platform=aarch64-linux
Writing lockfile to /Users/trung.vo/Source/view-transitions-demo/music-rails/Gemfile.lock
     run  bundle binstubs bundler
Could not find pg-1.5.6 in locally installed gems
     rails  importmap:install
Could not find pg-1.5.6 in locally installed gems
Run `bundle install` to install missing gems.
     rails  turbo:install stimulus:install
Could not find pg-1.5.6 in locally installed gems
Run `bundle install` to install missing gems.

Solution

Based on the error message, it is necessary to install libpq:

Please install libpq or postgresql client package like so:
  brew install libpq

Follow these steps to resolve the issue:

Step 1. Install `libpq`

To resolve the issue, follow these steps:

Install libpq by running the following command:

brew install libpq

After successful installation, you will see the following message:

libpq is keg-only, which means it was not symlinked into /opt/homebrew,
because conflicts with postgres formula.

If you need to have libpq first in your PATH, run:
  echo 'export PATH="/opt/homebrew/opt/libpq/bin:$PATH"' >> ~/.zshrc

For compilers to find libpq you may need to set:
  export LDFLAGS="-L/opt/homebrew/opt/libpq/lib"
  export CPPFLAGS="-I/opt/homebrew/opt/libpq/include"

Step 2. Add `libpq` to the PATH

To add libpq to the PATH, you have two options:

Run the following command as suggested above:

echo 'export PATH="/opt/homebrew/opt/libpq/bin:$PATH"' >> ~/.zshrc

Alternatively, you can run the link command:

brew link --force libpq

The link command ensures that the library is correctly linked to the path. Without running the link command, the same error will occur.

The link command symlinks the installed package (located in /usr/local/Cellar) to /usr/local. So when you type, for example: $ <name-of-binary> in your terminal (e.g., $ rvm), the package installed via brew is executed.

Conclusion

After performing the above two steps, run the rails new command again, and it should work.

Copy Code with Syntax Highlighting from VSCode to PowerPoint

Fri, 19 Jul 2024 14:40:00 GMT

Problem

When preparing presentations with code snippets, I often encounter two annoying issues when copying code from VSCode to PowerPoint:

The copied code includes the background color from VSCode.
The indentation of the code is not preserved.

To better understand the problem, refer to the following images:

Solutions

Let’s address each problem individually:

1. Remove background color

To remove the background color, simply copy the code from VSCode to PowerPoint, select the code, and set the Text Highlight Color to No Colour.

2. Preserve indentation (tab, space)

Preserving indentation can be a bit tricky. Although I couldn’t find a direct way to copy code with preserved indentation, I discovered a solution on GitHub. According to vscode/issues/31829#issuecomment-592138395, it used to be possible to preserve indentation in VSCode version 1.39.2, but it stopped working in later versions.

To overcome this, you can download VSCode 1.39.2 and use it specifically when you need to copy code with preserved indentation to PowerPoint. Even on a Mac with an M2 chip, selecting the VSCode Intel version should work fine.

So, the next time you need to copy code from VSCode to PowerPoint, remember these two simple solutions to make your life easier.

Notion: Rounding to 2 Decimal Places

Tue, 02 Jul 2024 14:32:00 GMT

Notion is an exceptional tool that I have been using for quite some time. Its underlying database structure, which resembles a table, offers customization options with various views such as gallery, board, list, and calendar.

Recently, I created a simple database to track my team’s sprint progress on a weekly basis. The database includes fields for the sprint name, date, number of closed tickets, number of open tickets, and a formula column to automatically calculate the percentage of closed tickets.

The formula is straightforward: closed tickets / (closed tickets + open tickets). In Notion, you can directly reference column names in formulas. For example, I have a formula like "Complete" / ("Complete" + "Open"), which is represented as prop("Complete") / (prop("Complete") + prop("Open")) when copied and pasted.

To visualize the result, I have included screenshots below:

As you can see, the result is a long decimal number. To round it to two decimal places, we can use a workaround similar to rounding numbers in JavaScript.

Formula

Here’s the formula to round to two decimal places:

round(prop("Some column") * 100) / 100

You can adjust the number of zeros to round to the desired decimal places. For example, to round to one decimal place, use 10; to round to three decimal places, use 1000.

This is how it appears on the Notion page:

Why does this work?

Let’s take an example where the result of the formula is 0.531914893617. When you multiply it by 100, it becomes 53.1914893617. Rounding it gives you 53. Finally, dividing it by 100 gives you 0.53.

Here’s the updated result:

Adding "loading=lazy" to GIF files on my 7-year-old Gatsby blog (with ChatGPT assistance)

Sun, 23 Jun 2024 08:32:00 GMT

My blog was built a long time ago using Gatsby. I vaguely remember cloning it from a template, but I can’t recall the exact name.

Over the years, I have added various features, such as the talks page, as I started giving talks.

The blog was initially built with Gatsby 1 and has been upgraded to Gatsby 2, where it has remained ever since. Although Gatsby 2’s support ended in 2021, I have procrastinated upgrading to the latest version, Gatsby 5. Since my blog is still functional and allows me to add new articles and talks, I haven’t felt a strong urge to perform a complete revamp or refactoring. It has become somewhat of a legacy system that continues to serve its purpose.

Here is the current package.json:

"dependencies": {
  "@sentry/gatsby": "^5.29.2",
+ "gatsby": "2.32.13",
  "gatsby-plugin-canonical-urls": "2.9.0",
  "gatsby-plugin-catch-links": "^2.0.4",
  "gatsby-plugin-feed": "^2.0.8",
  "gatsby-plugin-google-analytics": "^2.0.6",
  "gatsby-plugin-google-fonts": "latest",
  "gatsby-plugin-next-seo": "^1.6.1",
  "gatsby-plugin-offline": "^2.0.6",
  "gatsby-plugin-react-helmet": "^3.0.0",
  "gatsby-plugin-sass": "^2.0.1",
  "gatsby-plugin-sharp": "^3.15.0",
  "gatsby-plugin-sitemap": "^2.0.1",
  "gatsby-remark-autolink-headers": "^2.1.17",
  "gatsby-remark-copy-linked-files": "^2.0.5",
+ "gatsby-remark-images": "^6.12.1",
  "gatsby-remark-prismjs": "^3.0.2",

Perhaps one day, I will migrate the blog to Astro, but that remains a future endeavor. As a first step, I plan to migrate all my markdown files to a Notion database and connect my blog to fetch content from Notion instead of using the current markdown files. This change alone would be quite helpful. So, what’s the issue at hand?

In a recent article, I highlighted the awesomeness of the loading='lazy' property for images. I want to ensure that my blog also benefits from this feature. I recall adding the loading: 'lazy' option to gatsby-remark-images, which should apply the loading='lazy' attribute to all images by default.

{
  resolve: 'gatsby-transformer-remark',
  options: {
    tableOfContents: {
      maxDepth: 4,
    },
    plugins: [
      'gatsby-remark-autolink-headers',
      'gatsby-remark-lazy-gif',
      {
        resolve: 'gatsby-remark-images',
        options: {
          maxWidth: 960,
+         loading: 'lazy',
          linkImagesToOriginal: true,
        },

However, upon reviewing my latest article, I noticed that the GIF files do not have the loading='lazy' property. Consequently, when visiting the page, the GIF files load immediately, resulting in a significant amount of data being loaded, especially for larger GIF files. Since many of my blog posts include GIF files to showcase visual content, this issue needs to be addressed. For example, the Angular v17’s View Transitions: Navigate in Elegance contains several GIF files and at the moment, when you enter the page, all 12 GIF files are loaded immediately, costing about 70mb of data.

Current Setup

While I have configured gatsby-remark-images to include the loading='lazy' property by default for most images, GIF files are not processed by this plugin. For example, the following JPG file has the loading='lazy' property:

But the GIF file does not have the loading='lazy' property. The img tag below only has the src and alt attributes:

<img src="/0a94a1f59b4ffa9c061154716bd42de2/angular-view-transitions-07.gif" alt="Customised Transition">

The reason why GIFs are excluded can be found in the gatsby-remark-images documentation and some related issues:

Approach

What I want is simple: adding the loading='lazy' property to GIF files. Since gatsby-remark-images doesn’t support GIFs, I need to find an alternative solution.

- <img src="/0a94a1f59b4ffa9c061154716bd42de2/angular-view-transitions-07.gif" alt="Customised Transition">
+ <img src="/0a94a1f59b4ffa9c061154716bd42de2/angular-view-transitions-07.gif" alt="Customised Transition" loading="lazy">

Searching Google doesn’t yield any straightforward solutions.

Thus, I decided to ask ChatGPT for help. Here is the conversation:

See the full conversation here.

Attempt 1: GPT suggests updating `gatsby-config.js` for `gatsby-remark-images`

Basically, ChatGPT suggested updating the gatsby-config.js that utilise wrapperStyle from gatsby-remark-images. This custom transformer will add the loading="lazy" attribute to .gif images.

// gatsby-config.js

module.exports = {
  siteMetadata: {
    // Your site metadata
  },
  plugins: [
    {
      resolve: 'gatsby-transformer-remark',
      options: {
        plugins: [
          {
            resolve: 'gatsby-remark-images',
            options: {
              maxWidth: 800,
              loading: 'lazy', // Default loading for images
+              wrapperStyle: (fluidResult) =>
+                fluidResult.src.endsWith('.gif') ? 'loading="lazy"' : '',
+            },
          },
        ],
      },
    },
    // Other plugins
  ],
}

However, as gatsby-remark-images doesn’t support GIFs, this approach won’t work because the wrapperStyle function is only applied to images processed by gatsby-remark-images. GIFs are not processed by this plugin.

So I asked for a follow-up, and ChatGPT suggested writing a custom plugin to handle GIFs.

Attempt 2: Write a custom plugin to handle GIFs

Below are the steps suggested by ChatGPT:

If gatsby-remark-images is filtering out .gif images and you need to add loading="lazy" to them, you can use a custom plugin to directly modify the markdown AST before gatsby-remark-images processes it. Here’s how you can achieve this:

Create the custom plugin directory structure:

mkdir -p plugins/gatsby-remark-lazy-gif

Inside gatsby-remark-lazy-gif, create an index.js file with the following content:

// plugins/gatsby-remark-lazy-gif/index.js

const visit = require('unist-util-visit');

module.exports = ({ markdownAST }) => {
  visit(markdownAST, 'image', node => {
    if (node.url.endsWith('.gif')) {
      node.data = node.data || {};
      node.data.hProperties = node.data.hProperties || {};
      node.data.hProperties.loading = 'lazy';
    }
  });
  return markdownAST;
};

Update your gatsby-config.js to use the custom plugin before gatsby-remark-images:

// gatsby-config.js

module.exports = {
  siteMetadata: {
    // Your site metadata
  },
  plugins: [
    {
      resolve: 'gatsby-transformer-remark',
      options: {
        plugins: [
+         'gatsby-remark-lazy-gif', // Add the custom plugin here
          {
            resolve: 'gatsby-remark-images',
            options: {
              maxWidth: 800,
            },
          },

I followed the instructions and created the custom plugin. Then, I updated the gatsby-config.js to include the custom plugin before gatsby-remark-images. However, it threw an error:

Plugin gatsby-remark-lazy-gif requires a package.json file

I asked for further guidance, and ChatGPT suggested creating a package.json file for the plugin, as seen in the conversation below:

And voila! It works! Now all my GIF files have the loading='lazy' property. As you scroll down the page, the GIF files are loaded dynamically, reducing the initial data load.

Conclusion

To boost website performance, add loading='lazy' to the img tag. While Gatsby’s default image transformer, gatsby-remark-images, doesn’t support GIFs, we can create a custom plugin to handle them.

ChatGPT has been super helpful in creating the plugin and solving this problem. I am a daily use of AI tools such as Copilot, ChatGPT and others and I really appreciate the value they bring to my work. This article was also written with ChatGPT’s help for grammar and suggestions.

Angular v17’s View Transitions: Navigate in Elegance

Sat, 22 Jun 2024 15:32:00 GMT

Angular View Transitions

As users navigate through your site, they’ll appreciate the smooth and polished transitions that keep them engaged. Angular v17 introduces integrated support for the innovative View Transitions API. This API simplifies DOM changes in a single step while generating an animated transition between the two states. You can explore this feature in depth by following Smooth transitions with the View Transition API.

Angular’s Router now includes an optional feature that uses the document.startViewTransition callback to activate and deactivate route, ensuring smooth transitions when navigating between pages. This feature also gracefully handles browsers that do not support view transitions, providing a consistent navigation experience.

To enable view transitions in Angular, there are two approaches. If you are using RouterModule.forRoot, simply set enableViewTransitions to true in the router configuration:

@NgModule({
  imports: [
    CommonModule,
    WebLayoutModule,
    IconModule,
    NoopAnimationsModule,
    RouterModule.forRoot(webShellRoutes, {
      scrollPositionRestoration: 'top',
+     enableViewTransitions: true
    }),
    StoreModule.forRoot(rootReducers),
    EffectsModule.forRoot([ApplicationEffects, PlaylistsEffect, PlaylistTracksEffect]),
    SettingsModule,
    ...extModules

Alternatively, if you are using provideRouter, you can add the withViewTransitions option:

@NgModule({
  exports: [RouterModule],
  providers: [
    provideRouter(
      webShellRoutes,
+     withViewTransitions()
    )
  ],

And just like that, pages cross-fade. The screenshots below demonstrate the view transition effect.

Before

Previously, the page would render immediately when a link was clicked and the route changed

After

However, after enabling view transitions, you can see the faded effect during the transition.

How Do These Transitions Work?

Angular Implementation

When you enable view transitions with enableViewTransitions: true in Angular, it uses withViewTransitions under the hood, as shown in the code snippet below.

packages/router/src/router_module.ts#L157.

static forRoot(routes: Routes, config?: ExtraOptions): ModuleWithProviders<RouterModule> {
  return {
    ngModule: RouterModule,
    providers: [
+      config?.enableViewTransitions ? withViewTransitions().ɵproviders : [],
    ],
  };

withViewTransitions returns a routerFeature with a highlight on createViewTransition.

export function withViewTransitions(
  options?: ViewTransitionsFeatureOptions,
): ViewTransitionsFeature {
  const providers = [
+    {provide: CREATE_VIEW_TRANSITION, useValue: createViewTransition},
    {
      provide: VIEW_TRANSITION_OPTIONS,
      useValue: {skipNextTransition: !!options?.skipInitialTransition, ...options},
    },
  ];
  return routerFeature(RouterFeatureKind.ViewTransitionsFeature, providers);
}

createViewTransition calls document.startViewTransition, but the DOM isn’t updated within the transition callback as usual. Instead, it synchronously activates and deactivates routes during the transition. This is the only place in the Angular codebase where document.startViewTransition is used.

packages/router/src/utils/view_transition/view_transition.ts#L121

/**
 * A helper function for using browser view transitions. This function skips the call to
 * `startViewTransition` if the browser does not support it.
 *
 * @returns A Promise that resolves when the view transition callback begins.
 */
export function createViewTransition(
  injector: Injector,
  from: ActivatedRouteSnapshot,
  to: ActivatedRouteSnapshot
): Promise<void> {
  const transitionOptions = injector.get(VIEW_TRANSITION_OPTIONS)
  const document = injector.get(DOCUMENT)
  // Create promises outside the Angular zone to avoid causing extra change detections
  return injector.get(NgZone).runOutsideAngular(() => {
    if (!document.startViewTransition || transitionOptions.skipNextTransition) {
      transitionOptions.skipNextTransition = false
      // The timing of `startViewTransition` is closer to a macrotask. It won't be called
      // until the current event loop exits so we use a promise resolved in a timeout instead
      // of Promise.resolve().
      return new Promise(resolve => setTimeout(resolve))
    }

    let resolveViewTransitionStarted: () => void
    const viewTransitionStarted = new Promise<void>(resolve => {
      resolveViewTransitionStarted = resolve
    })
    const transition = document.startViewTransition(() => {
      resolveViewTransitionStarted()
      // We don't actually update dom within the transition callback. The resolving of the above
      // promise unblocks the Router navigation, which synchronously activates and deactivates
      // routes (the DOM update). This view transition waits for the next change detection to
      // complete (below), which includes the update phase of the routed components.
      return createRenderPromise(injector)
    })
    const { onViewTransitionCreated } = transitionOptions
    if (onViewTransitionCreated) {
      runInInjectionContext(injector, () =>
        onViewTransitionCreated({ transition, from, to })
      )
    }
    return viewTransitionStarted
  })
}

In Angular, a single-document view transition is applied for SPAs, as it runs within a single document, animating changes to the DOM when navigating between routes. However, when using server-side rendering (SSR), we may need to incorporate cross-document view transitions.

To achieve cross-document view transitions, we can utilize the document.startViewTransition method and pass a callback that updates the DOM. The transition is considered complete when the callback returns a promise that resolves once the DOM has been fully updated.

View Transition API

To trigger a same-document view transition in JS, we use:

function handleClick(e) {
  if (!document.startViewTransition) {
    updateTheDOMSomehow()
    return
  }

  document.startViewTransition(() => updateTheDOMSomehow())
}

When invoked, the browser captures snapshots of all elements with a view-transition-name CSS property. After the callback updates the DOM, it takes snapshots of the new state and constructs a pseudo-element tree like this:

::view-transition
└─ ::view-transition-group(root)
   └─ ::view-transition-image-pair(root)
      ├─ ::view-transition-old(root)
      └─ ::view-transition-new(root)

These snapshots transition smoothly from their old to new states, while their content crossfades. The ::view-transition sits as an overlay on the page, useful for setting a background colour for the transition.

::view-transition-old(root) is a screenshot of the old view, and ::view-transition-new(root) is a live representation of the new view. The old view animates from opacity: 1 to opacity: 0, while the new view animates from opacity: 0 to opacity: 1, creating a crossfade. All animations are performed using CSS, allowing for customisation.

How Long is the Default Crossfade Transition Animation?

The default crossfade transition animation in Angular lasts 250ms, according to the W3C documentation. You won’t easily find this information on Google, but it is specified in the 5. User Agent Stylesheet.

:root {
  view-transition-name: root;
}

:root::view-transition {
  position: fixed;
  inset: 0;
}

:root::view-transition-group(*) {
  position: absolute;
  top: 0;
  left: 0;

+ animation-duration: 0.25s;
  animation-fill-mode: both;
}

You can customise the duration of the crossfade transition using CSS, as explained in the next section.

Using CSS to Customise Transitions

All view transition pseudo-elements can be targeted with CSS. Since the animations are defined using CSS, you can modify them using existing CSS animation properties. For instance, to slow down the animation to 5 seconds, use the following CSS:

::view-transition-old(root),
::view-transition-new(root) {
  animation-duration: 5s;
}

This change makes the fade much slower. As shown in the video below, the ::view-transition appears on top of the page.

Customising `::view-transition-old`

If you want to customise the transition for the old view only, apply changes to the ::view-transition-old(root) pseudo-element. Note that extending the old view’s duration can cause visual issues, such as a flashing effect when the old view disappears while the new view appears quickly.

::view-transition-old(root) {
  animation-duration: 5s;
}

Customising `::view-transition-new`

Similarly, you can customise the transition for the new view only. This is useful if you want the new view to appear slowly. In this case, the new view will appear in 5 seconds while the old view disappears in 250ms default duration. However it creates a black screen before the new view fully appears.

::view-transition-new(root) {
  animation-duration: 5s;
}

Further Customising the Transition

You can customize the animations using CSS instead of using the default fade-in and fade-out animation. If you’re curious about how the default fade-in animation works, you can read more about it in the -ua-view-transition-fade-in.

To apply a slide effect, you can use the following CSS:

@keyframes slide-from-right {
  from {
    transform: translateX(300px);
  }
}

@keyframes slide-to-left {
  to {
    transform: translateX(-300px);
  }
}

::view-transition-old(root) {
  animation: slide-to-left 5s ease;
}

::view-transition-new(root) {
  animation: slide-from-right 5s ease;
}

Notice that the entire page shifts, causing a double side nav bar effect during the transition. To avoid this, either animate the content only or use a less disruptive animation. The Chrome team provides an example of a fancy animation.

@keyframes fade-in {
  from {
    opacity: 0;
  }
}

@keyframes fade-out {
  to {
    opacity: 0;
  }
}

@keyframes slide-from-right {
  from {
    transform: translateX(30px);
  }
}

@keyframes slide-to-left {
  to {
    transform: translateX(-30px);
  }
}

::view-transition-old(root) {
  animation: 90ms cubic-bezier(0.4, 0, 1, 1) both fade-out, 300ms cubic-bezier(
        0.4,
        0,
        0.2,
        1
      ) both slide-to-left;
}

::view-transition-new(root) {
  animation: 210ms cubic-bezier(0, 0, 0.2, 1) 90ms both fade-in, 300ms
      cubic-bezier(0.4, 0, 0.2, 1) both slide-from-right;
}

Transitioning Multiple Elements

To avoid transitioning the entire page, you can animate specific elements separately by assigning a view-transition-name to the element.

.media-cover {
  view-transition-name: media-cover;
}

The view-transition-name must be unique on the page, following the specs

For example, on a listing page with 10 playlists, each displayed with an ID from 1 to 10, you can’t use the same view-transition-name for every playlist cover. Here are two ways to handle this unique name issue:

1. Set Each Element’s Name Dynamically

For example, on the listing page, assign the name based on the playlist ID.

@for (playlist of playlists.items; track playlist) {
  <as-card
+   [style.view-transition-name]="'media-cover' + playlist.id"
    [title]="playlist.name"
    [uri]="playlist.uri"

This way, each playlist cover on the listing page will have a unique name. On the detail page, there will only be a single media cover displayed with the name media-cover-1, for example.

2. Assign the Name Dynamically During the Transition

Alternatively, when the user clicks on an playlist cover, the name will be assigned dynamically. For example, by default, no cover on the listing page will have view-transition-name. When an playlist is clicked, the name media-cover will be assigned to the current active playlist cover, making the transition apply only to the active cover.

The pseudo-code looks like this:

thumbnail.onclick = async () => {
  thumbnail.style.viewTransitionName = 'media-cover'

  document.startViewTransition(() => {
    thumbnail.style.viewTransitionName = ''
    updateTheDOMSomehow()
  })
}

Using `onViewTransitionCreated` in Angular

We will try to implement the second approach in Angular.

Angular’s withViewTransitions feature can be used with an options object that includes an onViewTransitionCreated callback. This callback runs in an injection context and receives a ViewTransitionInfo object.

Here’s an example using onViewTransitionCreated:

bootstrapApplication(App, {
  providers: [
    provideRouter(
      routes,
      withComponentInputBinding(),
+     withViewTransitions({ onViewTransitionCreated })
    ),
  ],
})

function onViewTransitionCreated(info: ViewTransitionInfo) {
  console.log(info)
  const currentTransitionService = inject(CurrentTransitionService)
  currentTransitionService.currentTransition.set(info)
  info.transition.finished.finally(() => {
    currentTransitionService.currentTransition.set(null)
  })
}

@Injectable({
  providedIn: 'root',
})
export class CurrentTransitionService {
  readonly currentTransition = signal<ViewTransitionInfo | null>(null)
}

Now you have the currentTransition object, which contains the from and to routes. You can use this information to dynamically assign the view-transition-name to the element you want to transition.

@for (playlist of playlists.items; track playlist) {
  <as-card
+   [ngClass]="viewTransitionName(playlist)"
    [title]="playlist.name"

viewTransitionName(item: SpotifyApi.PlaylistObjectSimplified) {
  const transition = this.transitionService.currentTransition();
  const transitionAlbumId = getViewTransitionParamValue(
    transition,
    RouterUtil.Configuration.PlaylistId
  );
  const withViewTransition = transitionAlbumId === item.id;
  return withViewTransition ? 'with-view-transition' : '';
}

I used the with-view-transition class on the parent element of the media-cover component instead of directly on the media-cover component itself. This allows me to reuse the media-cover component in multiple places without applying the view transition directly to it.

I learn this approach from github.com/Charca/view-transitions-live/src/styles/styles.css#L1

.with-view-transition as-media-cover {
  view-transition-name: media-cover;
}

The complex part is getViewTransitionParamValue, considering how Angular Spotify is structured. Here’s the relevant code comment:

/*
  The reason for accessing the third firstChild is due to the route structure. For example, when rendering AlbumComponent:
  AppComponent
    LayoutComponent
      /album (lazy loadChildren)
        /:albumId (lazy loadChildren)
  Thus, when receiving transition.from or transition.to, only the AppComponent route snapshot is received.
  Therefore, accessing transition?.from.firstChild?.firstChild?.firstChild allows accessing the params.
  In this case, the albumId param is available.
*/
export function getViewTransitionParamValue(
  transition: ViewTransitionInfo | null,
  param: string
) {
  if (!transition) {
    return null
  }

  return (
    transition.from.firstChild?.firstChild?.firstChild?.paramMap.get(param) ||
    transition.to.firstChild?.firstChild?.firstChild?.paramMap.get(param)
  )
}

For more details, see my PR #97 - View Transition Playground.

Result

Regardless of whether you choose to set the name dynamically or during the transition, the outcome remains the same: only the active album cover will transition, while the others remain static.

Even if JavaScript is disabled in the browser, the transition will still work as expected since it relies on the browser’s built-in capabilities.

When debugging with the animation panel, the timeline of media-cover looks like this:

Notice the new ::view-transition-group with the name media-cover, which only contains the active album cover, and the built-in animation name ua-mix-blend-mode-plus-lighter defined in the W3C documentation.

According to 7.3.3. Setup transition pseudo-elements in the documentation, the above animation in the timeline follows the algorithm steps precisely. You’ll see:

Step 6: The -ua-view-transition-group-anim-media-cover
Step 8: -ua-view-transition-fade-out, -ua-mix-blend-mode-plus-lighter for ::view-transition-old(media-cover) and ::view-transition-new(media-cover)

As we observed, ::view-transition-old(media-cover) captures the media cover moving from the listing page to the detail page, which is a great start. However, we can further enhance the transition by applying a custom animation to the media-cover element. For example, if we add a spin animation to the media-cover element, the result will be as follows:

@keyframes spin {
  0% {
    transform: rotate(0deg);
  }
  100% {
    transform: rotate(360deg);
  }
}

::view-transition-new(media-cover) {
  animation: spin 500ms;
}

Demo & Source code

Feel free to give it a ⭐️.

trungvose/angular-spotify#97

Official W3C Documentation

As I have went through the ocean of resources before publishing this articles, I would the W3C should be still a single source of truth to truly understand the View Transitions API with some niche questions you might have in mind e.g how long is the default animation duration and the like. Here are the links to the official documentation

For same view transitions, you can refer to the CSS View Transitions Module Level 1 documentation
For cross-document view transitions, you can refer to the CSS View Transitions Module Level 2 documentation
Check out Angular’s support for the View Transitions API

Conclusion

Angular v17’s View Transitions API is a powerful tool that enables you to create smooth transitions between pages. By enabling view transitions in Angular, you can provide users with a more engaging and polished experience as they navigate through your site. While the Angular implementation is straightforward, there is much more to explore and discover with the View Transitions API. I hope this article has provided you with a solid foundation to dive deeper into this exciting feature.

Improving Website Performance with Browser-Level Image Lazy Loading (simply add loading="lazy")

Wed, 12 Jun 2024 15:32:00 GMT

Problem

Images are often the largest assets on websites, consuming significant bandwidth. On average, sites send over 5 MB of images on desktop and mobile, making image optimization crucial for improving website performance.

In my Gatsby blog, the talks page contains numerous images, but I haven’t implemented any image optimization techniques. As a result, when the page loads, all the images are loaded at once, totaling almost 50 MB. This negatively impacts user experience and website performance.

The loading attribute

To address this issue, we can utilize the loading="lazy" attribute on the images. This attribute instructs the browser to load the image only when it enters the viewport. By implementing lazy loading, we can significantly improve the performance of our site with minimal effort.

Previously, developers had two options for deferring the loading of off-screen images:

Using the Intersection Observer API
Utilizing scroll, resize, or orientationchange event handlers

While these options allowed for lazy loading, many developers relied on third-party libraries to simplify the implementation.

With browser-level lazy loading support, there is no longer a need for external libraries. Additionally, browser-level lazy loading ensures that images still load even if the client disables JavaScript, although loading is only deferred when JavaScript is enabled.

For more information on this attribute, refer to the web.dev documentation.

Adding loading="lazy" to the image tag is a straightforward process:

<img
  className="talk-image"
  src={`/img/speaking/${featureImage}.jpg`}
+ loading="lazy"
  alt={title}
/>

Here are the supported values for the loading attribute:

lazy: Defer loading of the resource until it reaches a calculated distance from the viewport. Chromium’s implementation of lazy loading tries to ensure that offscreen images are loaded early enough that they finish loading by the time the user scrolls to them by fetching them well before they become visible in the viewport.
eager: Default loading behavior of the browser, which is the same as not including the attribute and means the image is loaded regardless of where it’s located on the page. This is the default, but it can be useful to set explicitly if your tooling automatically adds loading=“lazy” when there’s no explicit value, or if your linter complains if it isn’t explicitly set.

Result

After adding the loading="lazy" attribute to the images, the images are loaded only when they are in the viewport. Notice how the first load, only 2mb worth of images are loaded.

The rest of the images are loaded as you scroll down the page. This reduces the amount of data that needs to be loaded when the page is loaded, which improves the performance of the site.

Next step

Adding loading="lazy" is a simple yet effective way to enhance your site’s performance. However, there are additional optimizations you can consider. Since the original images may have a high resolution and file size, you can leverage an image transformation service like Cloudinary to further resize and optimize the images. By adding the width attribute to the image tag, you can specify the desired dimensions of the image. Additionally, you can explore using more efficient image formats like WebP or AVIF. These optimizations can significantly reduce the file size and improve the loading speed of your images.

<img
  className="talk-image"
- src={`/img/speaking/${featureImage}.jpg`}  
+ src={`/img/speaking/${featureImage}.jpg?w=200`}
  loading="lazy"
  alt={title}
/>

Can I use it?

As of June 2024, the loading="lazy" attribute is supported by all major browsers, including Chrome, Firefox, Safari, and Edge. Firefox has supported it since December 2023 and Safari since March 2023. You can check current browser support on Can I use. If a browser doesn’t support it yet and you haven’t implemented other lazy load methods, it simply won’t have any effect.

Improve Cumulative Layout Shift (CLS)

Thu, 16 May 2024 08:30:00 GMT

It was really busy in Mar and Apr as we welcome our new family member to the world. I am back to the world of Web Performance now. In this article, we will explore how to improve Cumulative Layout Shift (CLS), after we covered First Contentful Paint (FCP) and Largest Contentful Paint (LCP) in the previous articles.

We did mentioned the basic of CLS in the Core Web Vitals article. CLS measures the visual stability of a page. It is the sum of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page. A layout shift occurs any time a visible element changes its position from one rendered frame to the next. The score is calculated by multiplying the impact fraction by the distance fraction. Let’s look at how we calculate the CLS score.

CLS Score Calculation

To calculate the layout shift score, the browser looks at the viewport size and the movement of unstable elements in the viewport between two rendered frames. The layout shift score is a product of two measures of that movement: the impact fraction and the distance fraction (both defined below).

layout shift score = impact fraction * distance fraction

impact fraction: the area of the viewport affected by the layout shift (impact size / viewport size)
distance fraction: the distance the unstable element moved in the viewport (distance / viewport size)

Impact fraction

The impact fraction measures how unstable elements impact the viewport area between two frames.

The impact fraction for a given frame is a combination of the visible areas of all unstable elements for that frame and the previous frame, as a fraction of the total area of the viewport.

In this case, the impact size = 700 and the view port size = 936. The impact fraction = 700 / 936 ~ 0.75.

Distance fraction

The other part of the layout shift score equation measures the distance that unstable elements have moved relative to the viewport. The distance fraction is the greatest horizontal or vertical distance any unstable element has moved in the frame divided by the viewport’s largest dimension (width or height, whichever is greater).

In this case, the distance = 234 and the view port size = 936. The distance fraction = 234 / 936 = 0.25.

The the layout shift score = (700 / 936) * (234 / 936) = 0.75 * 0.25 = 0.1875.

Example

Another example is the layout shift score for a mobile view:

What is a good CLS score?

To provide a good user experience, sites should strive to have a CLS score of 0.1 or less. To ensure you’re hitting this target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.

How to improve CLS?

Layout shifts are caused by elements that move unexpectedly in the viewport. Here are some common causes of layout shifts:

Images without specified dimensions
Ads, embeds, and iframes without specified dimensions
Dynamically injected content

To improve CLS, follow these steps:

Always add width and height attributes to images, videos, and iframes.
Reserve space for dynamically injected content using CSS.
Use absolute positioning for advert banners to prevent layout shifts.

Images without dimensions

When an image is loaded without specified dimensions, the browser doesn’t know how much space to allocate. Once the image loads, the browser shifts the content to make space, causing a layout shift.

For example, on my blog’s Talks page, the CLS score was 0.09 without specified image dimensions.

After specifying dimensions, the CLS score improved to 0.01.

With the new advancement if CSS, you can use aspect-ratio to specify the aspect ratio of an element instead of the fixed width and height. This is useful for responsive images and videos.

img {
  aspect-ratio: 16 / 9;
}

Ads, embeds, and iframes without dimensions

Ads, embeds, and iframes without specified dimensions can cause significant layout shifts. For example, on the New York Times website, content shifts when ads load without dimensions, leading to a poor user experience.

Another example is when you try to click a link, but an ad loads and shifts the content, causing you to click the ad instead.

Custom fonts with side-adjust

Custom fonts can also cause layout shifts when they load. The following video shows layout shifts caused by font loading.

To mitigate this, use side-adjust to match the fallback font to the custom font. Visit Automatic font matching for minimal CLS tool for more information.

Remember, Layout Shift is measured cumulatively

Layout Shift is measured as the sum of all shifts (horizontal and vertical) throughout the page’s lifespan. It is a continuous measurement.

References

Enhancing Cross-Document Navigation with the View Transitions API

Sat, 27 Apr 2024 13:00:00 GMT

Source code

Demo: https://view-transitions.trungvose.com/
Github: https://github.com/trungvose/view-transitions-api

Understanding the View Transitions API

The View Transitions API helps developers create smooth animations when moving between different parts of a webpage. You’ll often notice this when going from one page to another (like from /page-1 to /page-2), but it can also make updates within the same page more dynamic.

Historically, achieving seamless animations during significant state changes has posed challenges, with full-page load transitions largely dependent on browser capabilities.

Last year, during Web Directions Code, I heard John Allsopp mention the View Transitions API, and its potential for simplifying this process immediately caught my attention. By leveraging CSS and a dash of JavaScript, it facilitates effortless transitioning of elements or entire pages across navigation. Initially aimed at single-page apps (SPAs), the API has evolved into a W3C Candidate Recommendation and now supports multi-page apps (MPAs) with the draft for cross-document navigation currently in public working draft status.

What does this mean for developers? It signifies the ability to achieve native-like animation experiences directly within the browser. Presently, the View Transitions API can be applied in the following scenarios:

Transitioning between pages in traditional multi-page apps, including those built with server-side rendering frameworks like ASP.NET MVC, PHP, Ruby, or static site generators such as Jekyll or Hugo.
Enhancing transitions within single-page applications (SPAs) crafted with frameworks like Angular, React, or Vue.
Dynamically transitioning DOM changes within any web page.

This guide will look into into multi-page apps initially, followed by documentation for single-page apps in subsequent parts.

Conventionally, when navigating from one page to another (domain.com/page-1 to domain.com/page-2), the browser loads a fresh HTML document for the new page, replacing the existing one. Essentially, the previous HTML is discarded, and the new one is rendered.

The following code snippets, adapted from this source with minor adjustments, illustrate this process.

<!-- page-1.html -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <link rel="icon" href="https://glitch.com/favicon.ico" />
    <title>Cross fade demo</title>
    <link rel="stylesheet" href="/styles.css" />
  </head>
  <body>
    <header class="main-header">View Transitions Demo</header>
    <main class="content">
      <h1 class="content-title">Page 1</h1>
      <p>This is the content for page 1.</p>
      <p>Why not check out <a href="./page-2.html">page 2</a>?</p>
      <div class="circle small" style="background-color: red"></div>
    </main>
  </body>
</html>

<!-- page-2.html -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <link rel="icon" href="https://glitch.com/favicon.ico" />
    <title>Cross fade demo</title>
    <link rel="stylesheet" href="/styles.css" />
  </head>
  <body>
    <header class="main-header">
      <a href="./page-1.html" class="back-and-title">
        <svg class="back-icon" viewBox="0 0 24 24">
          <path
            d="M20 11H7.8l5.6-5.6L12 4l-8 8 8 8 1.4-1.4L7.8 13H20v-2z"
          ></path>
        </svg>
        <span>View Transitions Demo</span>
      </a>
    </header>
    <main class="content">
      <h1 class="content-title">Page 2</h1>
      <p>This is the content for page 2.</p>
      <ol>
        <li>It</li>
        <li>also</li>
        <li>has</li>
        <li>a</li>
        <li>list!</li>
      </ol>
      <p>
        Ok, that's enough fun, you can go back to
        <a href="./page-1.html">page 1</a>.
      </p>
      <div
        class="circle large"
        style="background-color: blue; position: absolute; top: 300px; left: 700px;"
      ></div>
    </main>
  </body>
</html>

See Demo: MPA without View Transitions

When served via an HTTP server, clicking links between these pages results in straightforward page loads.

As of April 8, 2024, CSS View Transitions Module Level 2 has been drafted and implemented in Chrome Canary, enabling smooth transitions between pages in multi-page apps.

Enabling View Transitions in Chrome Canary

To begin utilizing View Transitions, enable the feature in Chrome Canary by navigating to:

chrome://flags/#view-transition-on-navigation

Select Enabled and restart the browser.

Incorporating `@view-transition` Directive

As per the draft, the @view-transition rule is pivotal for triggering view transitions during navigation. It should be included in both source and destination documents. Here’s an example:

/* In both documents */
@view-transition {
  navigation: auto;
}

With this directive in place, page transitions, such as crossfades, become seamlessly integrated across the site.

See Demo: MPA with View Transitions: Default fade-in animation

Understanding `-ua-view-transition-fade-in`

When troubleshooting with DevTools, you might observe the -ua-view-transition-fade-in keyframe animation applied to the ::view-transition-new pseudo-element.

The ::view-transition-new CSS pseudo-element represents the “new” view state of a view transition — a real-time representation of the new view after the transition. Hence, you’ll notice the fade-in effect during page navigation, transitioning from opacity: 0 to opacity: 1, as defined in the default styling included in the UA stylesheet:

@keyframes -ua-view-transition-fade-in {
  from {
    opacity: 0;
  }
}

html::view-transition-new(*) {
  position: absolute;
  inset-block-start: 0;
  inline-size: 100%;
  block-size: auto;

  animation-name: -ua-view-transition-fade-in;
  animation-duration: inherit;
  animation-fill-mode: inherit;
}

For more information, refer to ::view-transition-new.

Customizing Transitions

While default fade-in/out animations are provided by the View Transitions API, developers can tailor transitions to suit their needs. For instance, creating a slide-in effect can be achieved by defining custom keyframes and applying them to the ::view-transition-new pseudo-element.

@keyframes slide-in {
  from {
    transform: translateX(100px);
  }
  to {
    transform: translateX(0);
  }
}

html::view-transition-new(root) {
  animation-name: slide-in;
}

This customization injects personality into transitions, enhancing the user experience.

See Demo: MPA with View Transitions: Custom animation

Transitioning Multiple Elements

While previous demonstrations focused on whole-page transitions, View Transitions also support transitioning specific elements. This is achieved by assigning a unique view-transition-name to the element.

<!-- In page-1.html -->
<div class="circle small" style="view-transition-name: circle; background-color: red"></div>

<!-- In page-2.html -->
<div class="circle large" style="view-transition-name: circle; background-color: blue;"></div>

Even when the elements are not identical across pages, the View Transitions API intelligently manages transitions based on shared view-transition-name attributes.

See Demo: MPA with View Transitions: Transitioning multiple elements

Unique Limitations for Lists

It’s crucial to remember that each view-transition-name must be unique. If you try to transition elements with the same name simultaneously, the transitions may fail. To ensure smooth transitions across all elements, it’s essential to manage transition names carefully.

Consider these examples of two cats without view transitions applied:

When I applied the @view-transition rule, you can notice the fade-in effect as seen before:

However, when I applied view-transition-name: cat to both cats, the transition didn’t work, and the fade-in animation was lost. So, I assigned each cat a different view-transition-name:

Now you can see the cat image smoothly transitioning between the listing page and the detail page:

See Demo: MPA with View Transitions: Cats

This means if you’re animating from a list-view to a details-view and back, ensure each element has a unique view-transition-name in your template. For example, in a list of cats:

<div className="cats">
  {cats.map(cat => (
    <a key={cat.id} style={{ viewTransitionName: `cat-${cat.id}` }} href={cat.url}>
      {cat.title}
    </a>
  ))}
</div>

Assigning a unique name like cat-kimi in your rendered HTML. Then, use the same “slug” in your cat template to transition the link into the article header:

<article>
  <header style={{ viewTransitionName: `cat-${cat.id}` }}>
    <h1>{cat.title}</h1>
  </header>
  {/* Additional content goes here */}
</article>

Understanding the Mechanism

Dave’s explanation provides valuable insight into how the View Transitions API operates. Essentially, the browser captures snapshots of DOM elements before and after the transition, then smoothly interpolates between these states to create seamless animations.

This seemingly simple mechanism is the foundation of the sophisticated transitions enabled by the View Transitions API.

Conclusion

With View Transitions, developers can effortlessly enhance user experiences by seamlessly transitioning between pages and elements within multi-page apps. By following simple directives and carefully managing transition names, the API empowers developers to create engaging, dynamic web experiences without the need for complex JavaScript solutions.

References

Upgrading from Angular 15 to 17 in Nx Workspace: A Comprehensive Guide

Fri, 29 Mar 2024 07:30:00 GMT

To explore the exciting new features of Angular 17, I am migrating Angular Spotify to the latest version. One of the notable additions in Angular 17 is the View Transition API, which is now supported by Angular Router.

The View Transition API in Angular Router allows for seamless component activation and deactivation using the document.startViewTransition callback. This feature ensures smooth transitions when navigating between pages. Importantly, it gracefully handles browsers that do not support view transitions, providing a consistent navigation experience.

My current dependencies angular@15.2.8 and nx@15.9.2

That’s how the current Angular Spotify dependencies looks like with angular@15.2.8 and nx@15.9.2

{
  "name": "angular-spotify",
  "dependencies": {
    "@angular/animations": "15.2.8",
    "@angular/common": "15.2.8",
    "@angular/compiler": "15.2.8",
    "@angular/core": "15.2.8",
    "@angular/forms": "15.2.8",
    "@angular/platform-browser": "15.2.8",
    "@angular/platform-browser-dynamic": "15.2.8",
    "@angular/router": "15.2.8",
    "@angular/service-worker": "15.2.8"
  },
  "devDependencies": {
    "@nrwl/cli": "15.9.2",
    "@nrwl/cypress": "15.9.2",
    "@nrwl/eslint-plugin-nx": "15.9.2",
    "@nrwl/jest": "15.9.2",
    "@nrwl/js": "15.9.2",
    "@nrwl/linter": "15.9.2",
    "@nrwl/nx-cloud": "16.0.1",
    "@nrwl/workspace": "15.9.2"
  }
}

To ensure compatibility between Nx and Angular versions, it is recommended to use the latest version of Nx. Therefore, I will proceed with the command nx migrate latest to initiate the migration process.

As a reminder, the migration involves two steps:

Step 1. nx migrate latest

> yarn nx migrate latest                                                                                                     127 ✘  22:34:22 
yarn run v1.22.19
$ nx migrate latest
Fetching meta data about packages.
It may take a few minutes.
Fetching nx@18.1.2
Fetching @nrwl/js@18.1.2
Fetching @nrwl/eslint-plugin-nx@18.1.2
Fetching @nrwl/js@18.1.2
Fetching @nrwl/cypress@18.1.2
Fetching @nrwl/eslint-plugin-nx@18.1.2
Fetching @nrwl/linter@18.1.2
Fetching @nrwl/jest@18.1.2
Fetching @nrwl/workspace@18.1.2
Fetching @nrwl/angular@18.1.2
Fetching @nrwl/cypress@18.1.2
Fetching @nrwl/workspace@18.1.2
Fetching @nrwl/jest@18.1.2
Fetching @nrwl/linter@18.1.2
Fetching @nrwl/angular@18.1.2
Fetching @angular/core@17.2.4
Fetching @ngrx/store@17.0.1
Fetching @ngrx/effects@17.0.1
Fetching @ngrx/component-store@17.0.1
Fetching @ngrx/store-devtools@17.0.1
Fetching @ngrx/component@17.0.1

 NX   The migrate command has run successfully.

- package.json has been updated.
- migrations.json has been generated.

 NX   Next steps:

- Make sure package.json changes make sense and then run 'yarn',
- Run 'yarn nx migrate --run-migrations'
- To learn more go to https://nx.dev/features/automate-updating-dependencies

✨  Done in 73.63s.

As you can see, we need to upgrade to angular@17.2.4 and nx@18.1.2.

Although the changes in package.json look promising, they don’t actually perform the migration yet. The next step is where the real work begins.

Step 2. nx migrate —run-migrations

As the title suggest, I immediate run the next command so that it will actually do the migration

yarn nx migrate --run-migrations

After successfully running the migration command, I encountered an error when trying to serve the application again. As expected, jumping three major versions from nx@15.9.2 to nx@18.1.2 doesn’t work smoothly.

Proper migration strategy

To ensure a smooth upgrade process, it is recommended to follow a gradual rolling out approach when upgrading from Nx 15 to 18. Similar to the process described in Upgrading from Angular 12 to 15 in an Nx Workspace: A Comprehensive Guide, we should upgrade from Nx 15 to 16, then from 16 to 17, and finally from 17 to 18.

nx migrate 16.7.0 (support Angular 16.2.0)

Considering that I am currently using angular@15.2.8, I believe it is safe to upgrade directly to angular@16.2.0.

See the full log of yarn nx migrate 16.7.0

> yarn nx migrate 16.7.0  ✔ 22:55:12
yarn run v1.22.19
$ nx migrate 16.7.0
Fetching meta data about packages.
It may take a few minutes.
Fetching nx@16.7.0
Fetching @nrwl/eslint-plugin-nx@16.7.0
Fetching @nrwl/linter@16.7.0
Fetching @nrwl/cypress@16.7.0
Fetching @nrwl/js@16.7.0
Fetching @nrwl/angular@16.7.0
Fetching @nrwl/jest@16.7.0
Fetching @nrwl/workspace@16.7.0
Fetching @nrwl/jest@16.7.0
Fetching @nrwl/cypress@16.7.0
Fetching @nrwl/eslint-plugin-nx@16.7.0
Fetching @nrwl/angular@16.7.0
Fetching @nrwl/workspace@16.7.0
Fetching @nrwl/linter@16.7.0
Fetching @nrwl/js@16.7.0
Fetching @angular/core@16.2.12
Fetching @ngrx/store@16.0.1
Fetching @ngrx/component-store@16.0.1
Fetching @ngrx/store-devtools@16.0.1
Fetching @ngrx/component@16.0.1
Fetching @ngrx/effects@16.0.1

 NX   The migrate command has run successfully.

- package.json has been updated.
- migrations.json has been generated.

 NX   Next steps:

- Make sure package.json changes make sense and then run 'yarn',
- Run 'yarn nx migrate --run-migrations'
- To learn more go to https://nx.dev/features/automate-updating-dependencies

✨  Done in 60.02s.

> yarn nx migrate --run-migrations  ✔ 22:57:26
yarn run v1.22.19
$ nx migrate --run-migrations

 NX   Running 'yarn' to make sure necessary packages are installed

[1/4] 🔍  Resolving packages...
warning @angular-devkit/build-angular > guess-parser > @wessberg/ts-evaluator@0.0.27: this package has been renamed to ts-evaluator. Please install ts-evaluator instead
warning @angular-devkit/build-angular > guess-parser > @wessberg/ts-evaluator > jsdom > domexception@2.0.1: Use your platform's native DOMException instead
warning @angular-devkit/build-angular > guess-parser > @wessberg/ts-evaluator > jsdom > w3c-hr-time@1.0.2: Use your platform's native performance.now() and performance.timeOrigin.
warning @angular-devkit/build-angular > guess-parser > @wessberg/ts-evaluator > jsdom > data-urls > abab@2.0.6: Use your platform's native atob() and btoa() methods instead
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning "@nrwl/angular > @nx/angular@16.7.0" has unmet peer dependency "esbuild@^0.17.5".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/common@>= 10.x <= 15.x".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/core@>= 10.x <= 15.x".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/router@>= 10.x <= 15.x".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/animations@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/common@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/forms@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/core@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/platform-browser@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/router@^15.0.1".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/common@^15.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/core@^15.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/platform-browser@^15.0.0".
[4/4] 🔨  Building fresh packages...
success Saved lockfile.
$ node ./decorate-angular-cli.js && ngcc --properties es2020 browser module main && husky install

 >  NX   Decoration of the Angular CLI is deprecated and will be removed in a future version

   Please replace usage of "ng <command>" in any scripts, particularly for CI, with "nx <command>"

 >  NX   Angular CLI has been decorated to enable computation caching.

==========================================

ALERT: As of Angular 16, "ngcc" is no longer required and not invoked during CLI builds. You are seeing this message because the current operation invoked the "ngcc" command directly. This "ngcc" invocation can be safely removed.

A common reason for this is invoking "ngcc" from a "postinstall" hook in package.json.

In Angular 17, this command will be removed. Remove this and any other invocations to prevent errors in later versions.

==========================================

husky - Git hooks installed
$ nx migrate --run-migrations
$ nx _migrate --run-migrations

 >  NX   Running migrations from 'migrations.json'

Ran 16.0.0-remove-nrwl-cli from nx
  Remove @nrwl/cli.

  UPDATE package.json
---------------------------------------------------------
Ran 16.0.0-update-nx-cloud-runner from nx
  Replace @nrwl/nx-cloud with nx-cloud

  UPDATE package.json
  UPDATE nx.json
---------------------------------------------------------
Ran 16.6.0-prefix-outputs from nx
  Prefix outputs with {workspaceRoot}/{projectRoot} if needed

  UPDATE apps/angular-spotify/project.json
  UPDATE libs/web/playlist/feature/list/project.json
  UPDATE libs/web/playlist/data-access/project.json
  UPDATE libs/web/playlist/feature/detail/project.json
  UPDATE libs/web/visualizer/feature/project.json
  UPDATE libs/web/visualizer/data-access/project.json
  UPDATE libs/web/shared/data-access/models/project.json
  UPDATE libs/web/shared/data-access/spotify-api/project.json
  UPDATE libs/web/shared/data-access/store/project.json
  UPDATE libs/web/search/feature/project.json
  UPDATE libs/web/search/data-access/project.json
  UPDATE libs/web/artist/ui/artist-top-tracks/project.json
  UPDATE libs/web/artist/ui/artist-top-track/project.json
  UPDATE libs/web/browse/data-access/project.json
  UPDATE libs/web/shared/ui/track-current-info/project.json
  UPDATE libs/web/shared/ui/icon/project.json
  UPDATE libs/web/shared/directives/click-stop-propagation/project.json
  UPDATE libs/web/shared/ui/media/project.json
  UPDATE libs/web/shared/ui/playlist-list/project.json
  UPDATE libs/web/shared/ui/spinner/project.json
  UPDATE libs/web/shared/ui/play-button/project.json
  UPDATE libs/web/shared/ui/tracks-loading/project.json
  UPDATE libs/web/shared/ui/media-order/project.json
  UPDATE libs/web/shared/ui/track-main-info/project.json
  UPDATE libs/web/shared/ui/input/project.json
  UPDATE libs/web/shared/ui/media-summary/project.json
  UPDATE libs/web/shared/ui/media-cover/project.json
  UPDATE libs/web/shared/ui/work-in-progress/project.json
  UPDATE libs/web/shared/ui/media-table/project.json
  UPDATE libs/web/shared/utils/project.json
  UPDATE libs/web/shared/app-config/project.json
  UPDATE libs/web/shared/assets/project.json
  UPDATE libs/web/artist/feature/project.json
  UPDATE libs/web/artist/data-access/project.json
  UPDATE libs/web/shared/pipes/duration-pipe/project.json
  UPDATE libs/web/visualizer/ui/project.json
  UPDATE libs/web/album/ui/album-track/project.json
  UPDATE libs/web/album/feature/detail/project.json
  UPDATE libs/web/album/feature/shell/project.json
  UPDATE libs/web/album/feature/list/project.json
  UPDATE libs/web/browse/feature/categories/project.json
  UPDATE libs/web/browse/feature/shell/project.json
  UPDATE libs/web/browse/feature/category/project.json
  UPDATE libs/web/browse/ui/category-cover/project.json
  UPDATE libs/web/album/data-access/project.json
  UPDATE libs/web/playlist/ui/playlist-track/project.json
  UPDATE libs/web/shell/ui/album-art-overlay/project.json
  UPDATE libs/web/shell/ui/player-controls/project.json
  UPDATE libs/web/shell/ui/main-view/project.json
  UPDATE libs/web/shell/ui/player-playback/project.json
  UPDATE libs/web/shell/ui/player-volume/project.json
  UPDATE libs/web/settings/data-access/project.json
  UPDATE libs/web/shell/ui/now-playing-bar/project.json
  UPDATE libs/web/shell/ui/nav-bar/project.json
  UPDATE libs/web/shell/ui/nav-links/project.json
  UPDATE libs/web/shell/ui/top-bar/project.json
  UPDATE libs/web/shell/ui/visualization-toggle/project.json
  UPDATE libs/web/home/ui/featured-playlists/project.json
  UPDATE libs/web/home/ui/greeting/project.json
  UPDATE libs/web/home/ui/recent-played/project.json
  UPDATE libs/web/home/data-access/project.json
  UPDATE libs/web/shell/ui/layout/project.json
  UPDATE libs/web/tracks/data-access/project.json
  UPDATE libs/web/shell/ui/social-share/project.json
  UPDATE libs/web/shell/ui/user-dropdown/project.json
  UPDATE libs/web/shell/feature/project.json
  UPDATE libs/web/tracks/feature/project.json
  UPDATE libs/web/auth/util/project.json
  UPDATE libs/web/home/feature/project.json
  UPDATE libs/web/auth/ui/unauthorized-modal/project.json
  UPDATE libs/web/settings/feature/project.json
  UPDATE libs/web/auth/data-access/project.json
---------------------------------------------------------
Ran update-16-0-0-add-nx-packages from @nrwl/workspace
  Replace @nrwl/workspace with @nx/workspace

  UPDATE package.json
  UPDATE .nx/cache/file-map.json
  UPDATE .nx/cache/parsed-lock-file.json
  UPDATE .nx/cache/project-graph.json
  UPDATE decorate-angular-cli.js
  UPDATE migrations.json
---------------------------------------------------------
Ran 16-0-0-move-workspace-generators-into-local-plugin from @nrwl/workspace
  Generates a plugin called 'workspace-plugin' containing your workspace generators.

  DELETE tools/generators
---------------------------------------------------------
Ran 16-0-0-fix-invalid-babelrc from @nrwl/workspace
  Fix .babelrc presets if it contains an invalid entry for @nx/web/babel.

  UPDATE libs/web/browse/data-access/.babelrc
  UPDATE libs/web/album/data-access/.babelrc
  UPDATE libs/web/tracks/data-access/.babelrc
  UPDATE libs/web/search/data-access/.babelrc
  UPDATE libs/web/settings/data-access/.babelrc
  UPDATE libs/web/home/data-access/.babelrc
---------------------------------------------------------
Ran update-16-0-0-add-nx-packages from @nrwl/eslint-plugin-nx
  Replace @nrwl/eslint-plugin-nx with @nx/eslint-plugin

  UPDATE package.json
  UPDATE .nx/cache/file-map.json
  UPDATE .nx/cache/parsed-lock-file.json
  UPDATE .nx/cache/project-graph.json
  UPDATE migrations.json
  UPDATE .eslintrc.json
  UPDATE apps/angular-spotify/.eslintrc.json
  UPDATE libs/web/album/feature/detail/.eslintrc.json
  UPDATE libs/web/album/feature/list/.eslintrc.json
  UPDATE libs/web/album/feature/shell/.eslintrc.json
  UPDATE libs/web/album/ui/album-track/.eslintrc.json
  UPDATE libs/web/artist/data-access/.eslintrc.json
  UPDATE libs/web/artist/feature/.eslintrc.json
  UPDATE libs/web/artist/ui/artist-top-track/.eslintrc.json
  UPDATE libs/web/artist/ui/artist-top-tracks/.eslintrc.json
  UPDATE libs/web/auth/ui/unauthorized-modal/.eslintrc.json
  UPDATE libs/web/browse/feature/categories/.eslintrc.json
  UPDATE libs/web/browse/feature/category/.eslintrc.json
  UPDATE libs/web/browse/feature/shell/.eslintrc.json
  UPDATE libs/web/browse/ui/category-cover/.eslintrc.json
  UPDATE libs/web/container-queries/.eslintrc.json
  UPDATE libs/web/future-responsive/.eslintrc.json
  UPDATE libs/web/home/feature/.eslintrc.json
  UPDATE libs/web/home/ui/featured-playlists/.eslintrc.json
  UPDATE libs/web/home/ui/greeting/.eslintrc.json
  UPDATE libs/web/home/ui/recent-played/.eslintrc.json
  UPDATE libs/web/playlist/feature/detail/.eslintrc.json
  UPDATE libs/web/playlist/feature/list/.eslintrc.json
  UPDATE libs/web/playlist/ui/playlist-track/.eslintrc.json
  UPDATE libs/web/search/feature/.eslintrc.json
  UPDATE libs/web/settings/feature/.eslintrc.json
  UPDATE libs/web/shared/app-init/.eslintrc.json
  UPDATE libs/web/shared/directives/click-stop-propagation/.eslintrc.json
  UPDATE libs/web/shared/directives/data-size-observer/.eslintrc.json
  UPDATE libs/web/shared/pipes/duration-pipe/.eslintrc.json
  UPDATE libs/web/shared/ui/icon/.eslintrc.json
  UPDATE libs/web/shared/ui/input/.eslintrc.json
  UPDATE libs/web/shared/ui/media/.eslintrc.json
  UPDATE libs/web/shared/ui/media-cover/.eslintrc.json
  UPDATE libs/web/shared/ui/media-order/.eslintrc.json
  UPDATE libs/web/shared/ui/media-summary/.eslintrc.json
  UPDATE libs/web/shared/ui/media-table/.eslintrc.json
  UPDATE libs/web/shared/ui/play-button/.eslintrc.json
  UPDATE libs/web/shared/ui/playlist-list/.eslintrc.json
  UPDATE libs/web/shared/ui/spinner/.eslintrc.json
  UPDATE libs/web/shared/ui/track-current-info/.eslintrc.json
  UPDATE libs/web/shared/ui/track-main-info/.eslintrc.json
  UPDATE libs/web/shared/ui/tracks-loading/.eslintrc.json
  UPDATE libs/web/shared/ui/work-in-progress/.eslintrc.json
  UPDATE libs/web/shell/feature/.eslintrc.json
  UPDATE libs/web/shell/ui/album-art-overlay/.eslintrc.json
  UPDATE libs/web/shell/ui/layout/.eslintrc.json
  UPDATE libs/web/shell/ui/main-view/.eslintrc.json
  UPDATE libs/web/shell/ui/nav-bar/.eslintrc.json
  UPDATE libs/web/shell/ui/nav-links/.eslintrc.json
  UPDATE libs/web/shell/ui/now-playing-bar/.eslintrc.json
  UPDATE libs/web/shell/ui/player-controls/.eslintrc.json
  UPDATE libs/web/shell/ui/player-playback/.eslintrc.json
  UPDATE libs/web/shell/ui/player-volume/.eslintrc.json
  UPDATE libs/web/shell/ui/social-share/.eslintrc.json
  UPDATE libs/web/shell/ui/top-bar/.eslintrc.json
  UPDATE libs/web/shell/ui/user-dropdown/.eslintrc.json
  UPDATE libs/web/shell/ui/visualization-toggle/.eslintrc.json
  UPDATE libs/web/tracks/feature/.eslintrc.json
  UPDATE libs/web/visualizer/feature/.eslintrc.json
  UPDATE libs/web/visualizer/ui/.eslintrc.json
---------------------------------------------------------
Ran update-16-0-0-add-nx-packages from @nrwl/cypress
  Replace @nrwl/cypress with @nx/cypress

  UPDATE package.json
  UPDATE .nx/cache/file-map.json
  UPDATE .nx/cache/parsed-lock-file.json
  UPDATE .nx/cache/project-graph.json
  UPDATE migrations.json
---------------------------------------------------------
Ran update-16-0-0-add-nx-packages from @nrwl/linter
  Replace @nrwl/linter with @nx/linter

  UPDATE package.json
  UPDATE apps/angular-spotify/project.json
  UPDATE libs/web/shared/data-access/spotify-api/project.json
  UPDATE libs/web/shared/data-access/store/project.json
  UPDATE libs/web/shared/data-access/models/project.json
  UPDATE libs/web/search/data-access/project.json
  UPDATE libs/web/browse/data-access/project.json
  UPDATE libs/web/album/data-access/project.json
  UPDATE libs/web/artist/data-access/project.json
  UPDATE libs/web/visualizer/data-access/project.json
  UPDATE libs/web/shared/pipes/duration-pipe/project.json
  UPDATE libs/web/shared/utils/project.json
  UPDATE libs/web/shared/app-init/project.json
  UPDATE libs/web/shared/app-config/project.json
  UPDATE libs/web/container-queries/project.json
  UPDATE libs/web/shared/ui/track-current-info/project.json
  UPDATE libs/web/shared/directives/click-stop-propagation/project.json
  UPDATE libs/web/shared/ui/icon/project.json
  UPDATE libs/web/shared/ui/media/project.json
  UPDATE libs/web/browse/feature/category/project.json
  UPDATE libs/web/browse/feature/shell/project.json
  UPDATE libs/web/browse/feature/categories/project.json
  UPDATE libs/web/shared/directives/data-size-observer/project.json
  UPDATE libs/web/search/feature/project.json
  UPDATE libs/web/shared/ui/playlist-list/project.json
  UPDATE libs/web/shared/ui/play-button/project.json
  UPDATE libs/web/shared/ui/track-main-info/project.json
  UPDATE libs/web/shared/ui/spinner/project.json
  UPDATE libs/web/shared/ui/media-order/project.json
  UPDATE libs/web/shared/ui/tracks-loading/project.json
  UPDATE libs/web/browse/ui/category-cover/project.json
  UPDATE libs/web/shared/ui/media-cover/project.json
  UPDATE libs/web/shared/ui/media-table/project.json
  UPDATE libs/web/shared/ui/input/project.json
  UPDATE libs/web/shared/ui/media-summary/project.json
  UPDATE libs/web/shared/ui/work-in-progress/project.json
  UPDATE libs/web/future-responsive/project.json
  UPDATE libs/web/artist/ui/artist-top-track/project.json
  UPDATE libs/web/visualizer/feature/project.json
  UPDATE libs/web/visualizer/ui/project.json
  UPDATE libs/web/album/feature/shell/project.json
  UPDATE libs/web/album/ui/album-track/project.json
  UPDATE libs/web/album/feature/list/project.json
  UPDATE libs/web/album/feature/detail/project.json
  UPDATE libs/web/artist/feature/project.json
  UPDATE libs/web/playlist/data-access/project.json
  UPDATE libs/web/playlist/feature/list/project.json
  UPDATE libs/web/settings/data-access/project.json
  UPDATE libs/web/playlist/feature/detail/project.json
  UPDATE libs/web/shell/ui/top-bar/project.json
  UPDATE libs/web/shell/ui/album-art-overlay/project.json
  UPDATE libs/web/shell/ui/player-controls/project.json
  UPDATE libs/web/shell/ui/player-playback/project.json
  UPDATE libs/web/auth/ui/unauthorized-modal/project.json
  UPDATE libs/web/shell/ui/layout/project.json
  UPDATE libs/web/shell/ui/now-playing-bar/project.json
  UPDATE libs/web/shell/ui/main-view/project.json
  UPDATE libs/web/shell/ui/nav-bar/project.json
  UPDATE libs/web/shell/ui/visualization-toggle/project.json
  UPDATE libs/web/shell/ui/nav-links/project.json
  UPDATE libs/web/shell/ui/social-share/project.json
  UPDATE libs/web/shell/ui/player-volume/project.json
  UPDATE libs/web/shell/ui/user-dropdown/project.json
  UPDATE libs/web/auth/data-access/project.json
  UPDATE libs/web/shell/feature/project.json
  UPDATE libs/web/auth/util/project.json
  UPDATE libs/web/settings/feature/project.json
  UPDATE libs/web/artist/ui/artist-top-tracks/project.json
  UPDATE libs/web/home/ui/greeting/project.json
  UPDATE libs/web/home/ui/recent-played/project.json
  UPDATE libs/web/playlist/ui/playlist-track/project.json
  UPDATE libs/web/tracks/data-access/project.json
  UPDATE libs/web/tracks/feature/project.json
  UPDATE libs/web/home/ui/featured-playlists/project.json
  UPDATE libs/web/home/feature/project.json
  UPDATE libs/web/home/data-access/project.json
  UPDATE .nx/cache/file-map.json
  UPDATE .nx/cache/parsed-lock-file.json
  UPDATE .nx/cache/project-graph.json
  UPDATE migrations.json
---------------------------------------------------------
Ran update-16-0-0-add-nx-packages from @nrwl/js
  Replace @nrwl/js with @nx/js

  UPDATE package.json
  UPDATE .nx/cache/file-map.json
  UPDATE .nx/cache/parsed-lock-file.json
  UPDATE .nx/cache/project-graph.json
  UPDATE migrations.json
---------------------------------------------------------
Ran update-16-0-0-add-nx-packages from @nrwl/jest
  Replace @nrwl/jest with @nx/jest

  UPDATE package.json
  UPDATE apps/angular-spotify/project.json
  UPDATE libs/web/visualizer/data-access/project.json
  UPDATE libs/web/future-responsive/project.json
  UPDATE libs/web/album/data-access/project.json
  UPDATE libs/web/artist/data-access/project.json
  UPDATE libs/web/artist/feature/project.json
  UPDATE libs/web/browse/data-access/project.json
  UPDATE libs/web/album/feature/detail/project.json
  UPDATE libs/web/album/feature/shell/project.json
  UPDATE libs/web/album/feature/list/project.json
  UPDATE libs/web/browse/ui/category-cover/project.json
  UPDATE libs/web/browse/feature/shell/project.json
  UPDATE libs/web/browse/feature/category/project.json
  UPDATE libs/web/browse/feature/categories/project.json
  UPDATE libs/web/visualizer/ui/project.json
  UPDATE libs/web/visualizer/feature/project.json
  UPDATE libs/web/tracks/feature/project.json
  UPDATE libs/web/tracks/data-access/project.json
  UPDATE libs/web/search/data-access/project.json
  UPDATE libs/web/container-queries/project.json
  UPDATE libs/web/artist/ui/artist-top-tracks/project.json
  UPDATE libs/web/shared/pipes/duration-pipe/project.json
  UPDATE libs/web/shared/data-access/spotify-api/project.json
  UPDATE libs/web/shared/data-access/store/project.json
  UPDATE libs/web/shared/app-init/project.json
  UPDATE libs/web/shared/app-config/project.json
  UPDATE libs/web/artist/ui/artist-top-track/project.json
  UPDATE libs/web/shared/ui/tracks-loading/project.json
  UPDATE libs/web/shared/ui/media-order/project.json
  UPDATE libs/web/shared/ui/icon/project.json
  UPDATE libs/web/shared/ui/media-table/project.json
  UPDATE libs/web/shared/ui/spinner/project.json
  UPDATE libs/web/shared/ui/playlist-list/project.json
  UPDATE libs/web/search/feature/project.json
  UPDATE libs/web/shared/directives/data-size-observer/project.json
  UPDATE libs/web/shared/ui/work-in-progress/project.json
  UPDATE libs/web/shared/ui/input/project.json
  UPDATE libs/web/album/ui/album-track/project.json
  UPDATE libs/web/shared/utils/project.json
  UPDATE libs/web/settings/feature/project.json
  UPDATE libs/web/settings/data-access/project.json
  UPDATE libs/web/home/data-access/project.json
  UPDATE libs/web/auth/util/project.json
  UPDATE libs/web/auth/data-access/project.json
  UPDATE libs/web/auth/ui/unauthorized-modal/project.json
  UPDATE libs/web/home/ui/recent-played/project.json
  UPDATE libs/web/playlist/ui/playlist-track/project.json
  UPDATE libs/web/shell/ui/visualization-toggle/project.json
  UPDATE libs/web/shell/ui/top-bar/project.json
  UPDATE libs/web/shell/ui/nav-bar/project.json
  UPDATE libs/web/shell/ui/nav-links/project.json
  UPDATE libs/web/shell/ui/album-art-overlay/project.json
  UPDATE libs/web/shell/ui/social-share/project.json
  UPDATE libs/web/shell/ui/user-dropdown/project.json
  UPDATE libs/web/shell/ui/layout/project.json
  UPDATE libs/web/shell/ui/main-view/project.json
  UPDATE libs/web/shell/feature/project.json
  UPDATE libs/web/home/feature/project.json
  UPDATE libs/web/playlist/data-access/project.json
  UPDATE libs/web/home/ui/featured-playlists/project.json
  UPDATE libs/web/home/ui/greeting/project.json
  UPDATE .nx/cache/file-map.json
  UPDATE .nx/cache/parsed-lock-file.json
  UPDATE .nx/cache/project-graph.json
  UPDATE jest.config.ts
  UPDATE jest.preset.js
  UPDATE migrations.json
---------------------------------------------------------
Ran add-test-setup-to-inputs-ignore from @nrwl/jest
  Add test-setup.ts to ignored files in production input

  UPDATE nx.json
---------------------------------------------------------
Ran update-16-0-0-add-nx-packages from @nrwl/angular
  Replace @nrwl/angular with @nx/angular

  UPDATE package.json
  UPDATE nx.json
  UPDATE .nx/cache/file-map.json
  UPDATE .nx/cache/parsed-lock-file.json
  UPDATE .nx/cache/project-graph.json
  UPDATE migrations.json
---------------------------------------------------------
Ran remove-ngcc-invocation from @nrwl/angular
  Remove 'ngcc' invocation if exists from the 'postinstall' script in package.json.

  UPDATE package.json
---------------------------------------------------------
Ran update-angular-cli-version-16-0-0 from @nrwl/angular
  Update the @angular/cli package version to ~16.0.0.

  UPDATE package.json
---------------------------------------------------------
Ran update-angular-cli-version-16-1-0 from @nrwl/angular
  Update the @angular/cli package version to ~16.1.0.

  UPDATE package.json
---------------------------------------------------------
Ran update-angular-cli-version-16-2-0 from @nrwl/angular
  Update the @angular/cli package version to ~16.2.0.

  UPDATE package.json
---------------------------------------------------------
Ran ngrx-component-migration-16 from @ngrx/component
  As of NgRx v16, `LetModule` and `PushModule` are deprecated in favor of standalone `LetDirective` and `PushPipe`.

  UPDATE libs/web/album/ui/album-track/src/lib/album-track.module.ts
  UPDATE libs/web/artist/ui/artist-top-track/src/lib/artist-top-track.module.ts
  UPDATE libs/web/browse/feature/category/src/lib/category.module.ts
  UPDATE libs/web/playlist/feature/detail/src/lib/playlist.module.ts
  UPDATE libs/web/playlist/ui/playlist-track/src/lib/playlist-track.module.ts
  UPDATE libs/web/shared/ui/media/src/lib/card.component.ts
  UPDATE libs/web/shared/ui/media-order/src/lib/media-order.module.ts
  UPDATE libs/web/shared/ui/play-button/src/lib/play-button.module.ts
  UPDATE libs/web/shell/ui/nav-links/src/lib/nav-links.module.ts
  UPDATE libs/web/shell/ui/visualization-toggle/src/lib/visualization-toggle.module.ts
  UPDATE libs/web/visualizer/ui/src/lib/web-visualizer-ui.module.ts
---------------------------------------------------------

 >  NX   Running 'yarn' to make sure necessary packages are installed

[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/common@>= 10.x <= 15.x".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/core@>= 10.x <= 15.x".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/router@>= 10.x <= 15.x".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/animations@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/common@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/forms@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/core@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/platform-browser@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/router@^15.0.1".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/common@^15.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/core@^15.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/platform-browser@^15.0.0".
warning " > @nx/angular@16.7.0" has unmet peer dependency "esbuild@^0.17.5".
[4/4] 🔨  Building fresh packages...
success Saved lockfile.
$ node ./decorate-angular-cli.js && husky install

 >  NX   Decoration of the Angular CLI did not complete successfully

husky - Git hooks installed

 >  NX   Successfully finished running migrations from 'migrations.json'. This workspace is up to date!

✨  Done in 117.18s.

It is crucial to run the serve or build command after every nx migrate --run-migrations to ensure that the application is functioning correctly. While having CI/CD configured can help catch issues when pushing code, it is always recommended to manually verify the code’s functionality before pushing.

I encountered an issue when running yarn serve.

Error: libs/web/shell/ui/visualization-toggle/src/lib/visualization-toggle.module.ts:16:5 - error NG6002: 'SvgIconsModule' does not appear to be an NgModule class.

16     SvgIconsModule
       ~~~~~~~~~~~~~~

  node_modules/@ngneat/svg-icon/lib/svg-icons.module.d.ts:4:22
    4 export declare class SvgIconsModule {
                           ~~~~~~~~~~~~~~
    This likely means that the library (@ngneat/svg-icon) which declares SvgIconsModule is not compatible with Angular Ivy. Check if a newer version of the library is available, and update if so. Also consider checking with the library's authors to see if the library is expected to be compatible with Ivy.

It turns out that the version of @ngneat/svg-icon I was using, 3.2.0, is too old. I found the latest version on GitHub, which is v7.0.3. To avoid any potential issues, I will commit the current Nx upgrade changes before upgrading @ngneat/svg-icon. This way, I can easily rollback if anything goes wrong.

yarn add @ngneat/svg-icon
yarn add @ngneat/svg-generator --save-dev

However, after performing the migration, I encountered another error when running yarn serve.

Error: libs/web/visualizer/ui/src/lib/web-visualizer-ui.component.html:11:15 - error NG8002: Can't bind to 'key' since it isn't a known property of 'svg-icon'.
1. If 'svg-icon' is an Angular component and it has 'key' input, then verify that it is part of this module.
2. If 'svg-icon' is a Web Component then add 'CUSTOM_ELEMENTS_SCHEMA' to the '@NgModule.schemas' of this component to suppress this message.
3. To allow any property add 'NO_ERRORS_SCHEMA' to the '@NgModule.schemas' of this component.

11     <svg-icon [key]="'times'"></svg-icon>
                 ~~~~~~~~~~~~~~~

  libs/web/visualizer/ui/src/lib/web-visualizer-ui.component.ts:28:16
    28   templateUrl: './web-visualizer-ui.component.html',
                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Error occurs in the template of component WebVisualizerUiComponent.

Error: libs/web/visualizer/ui/src/lib/web-visualizer-ui.module.ts:3:10 - error TS2305: Module '"@ngneat/svg-icon"' has no exported member 'SvgIconsModule'.

3 import { SvgIconsModule } from '@ngneat/svg-icon';
           ~~~~~~~~~~~~~~

Error: libs/web/visualizer/ui/src/lib/web-visualizer-ui.module.ts:8:12 - error NG1010: Value

I noticed that in Angular, components are now exported as standalone components. According to the documentation, SvgIconsModule has been replaced with SvgIconComponent, and SvgIconsModule.forRoot is now replaced with provideSvgIcons.

To update my code, I performed a global search and replace, replacing SvgIconsModule with SvgIconComponent. However, this resulted in a few TypeScript errors related to generics. I will fix these errors, but before that, I want to commit the current changes.

Type ‘string’ is not assignable to type ‘GenericStoreStatus’

Now TypeScript is reporting a new error. The problem is that the GenericStoreStatus type only allows four specific string values.

export type GenericStoreStatus = 'pending' | 'loading' | 'success' | 'error'

In the reducer function, when I only return a new object with status: 'loading', TypeScript implicitly assumes that the type of status is string. To explicitly specify that status should have the type GenericStoreStatus, I need to provide a type annotation or use a type assertion.

export const albumsReducer = createReducer(
  initialState,
  on(loadAlbums, (state) => ({
    ...state,
    status: 'loading',
    error: null
  })),

To resolve this issue, you can cast the status value to GenericStoreStatus using 'loading' as GenericStoreStatus. Alternatively, you can use the as const assertion to ensure the status value is treated as a specific string literal type.

export const albumsReducer = createReducer(
  initialState,
  on(loadAlbums, (state) => ({
    ...state,
-    status: 'loading',
+    status: 'loading' as GenericStoreStatus,
     // OR
+    status: 'loading' as const,
    error: null
  })),

To fix the issue, you can use multi-cursor editing. Here’s a gif demonstrating the process:

Running nx serve again and it is working now.

nx migrate 17.3.0 (support Angular 17.1.0)

I ran two commands

yarn nx migrate 17.3.0
yarn nx migrate --run-migrations

See the full log of nx migrate 17.3.0

> yarn nx migrate 17.3.0                                    ✔ 16:20:23
yarn run v1.22.19
$ nx migrate 17.3.0
Fetching meta data about packages.
It may take a few minutes.
Fetching nx@17.3.0
Fetching @nx/js@17.3.0
Fetching @nx/jest@17.3.0
Fetching @nx/linter@17.3.0
Fetching @nx/workspace@17.3.0
Fetching @nx/angular@17.3.0
Fetching @nx/cypress@17.3.0
Fetching @nx/eslint-plugin@17.3.0
Fetching @nx/linter@17.3.0
Fetching @angular/core@17.1.3
Fetching @ngrx/store@17.0.1
Fetching @ngrx/component-store@17.0.1
Fetching @ngrx/component@17.0.1
Fetching @ngrx/store-devtools@17.0.1
Fetching @ngrx/effects@17.0.1

 NX   The migrate command has run successfully.

- package.json has been updated.
- migrations.json has been generated.


 NX   Next steps:

- Make sure package.json changes make sense and then run 'yarn',
- Run 'yarn nx migrate --run-migrations'
- To learn more go to https://nx.dev/features/automate-updating-dependencies

✨  Done in 45.81s.

yarn nx migrate --run-migrations                ✔  40s   16:27:51 
yarn run v1.22.19
$ nx migrate --run-migrations

 NX   Running 'yarn' to make sure necessary packages are installed

[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/common@>= 10.x <= 15.x".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/core@>= 10.x <= 15.x".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/router@>= 10.x <= 15.x".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/animations@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/common@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/forms@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/core@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/platform-browser@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/router@^15.0.1".
warning "ng-zorro-antd > @angular/cdk@15.2.8" has incorrect peer dependency "@angular/core@^15.0.0 || ^16.0.0".
warning "ng-zorro-antd > @angular/cdk@15.2.8" has incorrect peer dependency "@angular/common@^15.0.0 || ^16.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/common@^15.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/core@^15.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/platform-browser@^15.0.0".
warning " > @ngneat/svg-generator@7.0.3" has unmet peer dependency "svgo@>=3.0.0".
[4/4] 🔨  Building fresh packages...
success Saved lockfile.
$ node ./decorate-angular-cli.js && husky install

 >  NX   Decoration of the Angular CLI did not complete successfully

husky - Git hooks installed
$ nx migrate --run-migrations
$ nx _migrate --run-migrations

 >  NX   Running migrations from 'migrations.json'

Ran 17.0.0-move-cache-directory from nx
  Updates the default cache directory to .nx/cache

  UPDATE .prettierignore
---------------------------------------------------------
Ran 17.0.0-use-minimal-config-for-tasks-runner-options from nx
  Use minimal config for tasksRunnerOptions

  UPDATE package.json
  UPDATE nx.json
---------------------------------------------------------
[object Object]
Ran rm-default-collection-npm-scope from nx
  Migration for v17.0.0-rc.1

  UPDATE nx.json
---------------------------------------------------------
Ran update-angular-cli-version-17-0-0 from @nx/angular
  Update the @angular/cli package version to ~17.0.0.

  UPDATE package.json
---------------------------------------------------------
Ran rename-browser-target-to-build-target from @nx/angular
  Rename 'browserTarget' to 'buildTarget'.

  UPDATE apps/angular-spotify/project.json
---------------------------------------------------------
Ran update-angular-cli-version-17-1-0 from @nx/angular
  Update the @angular/cli package version to ~17.1.0.

  UPDATE package.json
---------------------------------------------------------
Ran move-options-to-target-defaults from @nx/jest
  Move jest executor options to nx.json targetDefaults

  UPDATE nx.json
  UPDATE apps/angular-spotify/project.json
  UPDATE libs/web/album/data-access/project.json
  UPDATE libs/web/album/feature/detail/project.json
  UPDATE libs/web/album/feature/list/project.json
  UPDATE libs/web/album/feature/shell/project.json
  UPDATE libs/web/album/ui/album-track/project.json
  UPDATE libs/web/artist/data-access/project.json
  UPDATE libs/web/artist/feature/project.json
  UPDATE libs/web/artist/ui/artist-top-track/project.json
  UPDATE libs/web/artist/ui/artist-top-tracks/project.json
  UPDATE libs/web/auth/data-access/project.json
  UPDATE libs/web/auth/ui/unauthorized-modal/project.json
  UPDATE libs/web/auth/util/project.json
  UPDATE libs/web/browse/data-access/project.json
  UPDATE libs/web/browse/feature/categories/project.json
  UPDATE libs/web/browse/feature/category/project.json
  UPDATE libs/web/browse/feature/shell/project.json
  UPDATE libs/web/browse/ui/category-cover/project.json
  UPDATE libs/web/container-queries/project.json
  UPDATE libs/web/future-responsive/project.json
  UPDATE libs/web/home/data-access/project.json
  UPDATE libs/web/home/feature/project.json
  UPDATE libs/web/home/ui/featured-playlists/project.json
  UPDATE libs/web/home/ui/greeting/project.json
  UPDATE libs/web/home/ui/recent-played/project.json
  UPDATE libs/web/playlist/data-access/project.json
  UPDATE libs/web/playlist/ui/playlist-track/project.json
  UPDATE libs/web/search/data-access/project.json
  UPDATE libs/web/search/feature/project.json
  UPDATE libs/web/settings/data-access/project.json
  UPDATE libs/web/settings/feature/project.json
  UPDATE libs/web/shared/app-config/project.json
  UPDATE libs/web/shared/app-init/project.json
  UPDATE libs/web/shared/data-access/spotify-api/project.json
  UPDATE libs/web/shared/data-access/store/project.json
  UPDATE libs/web/shared/directives/data-size-observer/project.json
  UPDATE libs/web/shared/pipes/duration-pipe/project.json
  UPDATE libs/web/shared/ui/icon/project.json
  UPDATE libs/web/shared/ui/input/project.json
  UPDATE libs/web/shared/ui/media-order/project.json
  UPDATE libs/web/shared/ui/media-table/project.json
  UPDATE libs/web/shared/ui/playlist-list/project.json
  UPDATE libs/web/shared/ui/spinner/project.json
  UPDATE libs/web/shared/ui/tracks-loading/project.json
  UPDATE libs/web/shared/ui/work-in-progress/project.json
  UPDATE libs/web/shared/utils/project.json
  UPDATE libs/web/shell/feature/project.json
  UPDATE libs/web/shell/ui/album-art-overlay/project.json
  UPDATE libs/web/shell/ui/layout/project.json
  UPDATE libs/web/shell/ui/main-view/project.json
  UPDATE libs/web/shell/ui/nav-bar/project.json
  UPDATE libs/web/shell/ui/nav-links/project.json
  UPDATE libs/web/shell/ui/social-share/project.json
  UPDATE libs/web/shell/ui/top-bar/project.json
  UPDATE libs/web/shell/ui/user-dropdown/project.json
  UPDATE libs/web/shell/ui/visualization-toggle/project.json
  UPDATE libs/web/tracks/data-access/project.json
  UPDATE libs/web/tracks/feature/project.json
  UPDATE libs/web/visualizer/data-access/project.json
  UPDATE libs/web/visualizer/feature/project.json
  UPDATE libs/web/visualizer/ui/project.json
---------------------------------------------------------
Ran update-17-0-0-rename-to-eslint from @nx/linter
  update-17-0-0-rename-to-eslint

  UPDATE package.json
  UPDATE apps/angular-spotify/project.json
  UPDATE libs/web/album/data-access/project.json
  UPDATE libs/web/album/feature/detail/project.json
  UPDATE libs/web/album/feature/list/project.json
  UPDATE libs/web/album/feature/shell/project.json
  UPDATE libs/web/album/ui/album-track/project.json
  UPDATE libs/web/artist/data-access/project.json
  UPDATE libs/web/artist/feature/project.json
  UPDATE libs/web/artist/ui/artist-top-track/project.json
  UPDATE libs/web/artist/ui/artist-top-tracks/project.json
  UPDATE libs/web/auth/data-access/project.json
  UPDATE libs/web/auth/ui/unauthorized-modal/project.json
  UPDATE libs/web/auth/util/project.json
  UPDATE libs/web/browse/data-access/project.json
  UPDATE libs/web/browse/feature/categories/project.json
  UPDATE libs/web/browse/feature/category/project.json
  UPDATE libs/web/browse/feature/shell/project.json
  UPDATE libs/web/browse/ui/category-cover/project.json
  UPDATE libs/web/container-queries/project.json
  UPDATE libs/web/future-responsive/project.json
  UPDATE libs/web/home/data-access/project.json
  UPDATE libs/web/home/feature/project.json
  UPDATE libs/web/home/ui/featured-playlists/project.json
  UPDATE libs/web/home/ui/greeting/project.json
  UPDATE libs/web/home/ui/recent-played/project.json
  UPDATE libs/web/playlist/data-access/project.json
  UPDATE libs/web/playlist/feature/detail/project.json
  UPDATE libs/web/playlist/feature/list/project.json
  UPDATE libs/web/playlist/ui/playlist-track/project.json
  UPDATE libs/web/search/data-access/project.json
  UPDATE libs/web/search/feature/project.json
  UPDATE libs/web/settings/data-access/project.json
  UPDATE libs/web/settings/feature/project.json
  UPDATE libs/web/shared/app-config/project.json
  UPDATE libs/web/shared/app-init/project.json
  UPDATE libs/web/shared/data-access/models/project.json
  UPDATE libs/web/shared/data-access/spotify-api/project.json
  UPDATE libs/web/shared/data-access/store/project.json
  UPDATE libs/web/shared/directives/click-stop-propagation/project.json
  UPDATE libs/web/shared/directives/data-size-observer/project.json
  UPDATE libs/web/shared/pipes/duration-pipe/project.json
  UPDATE libs/web/shared/ui/icon/project.json
  UPDATE libs/web/shared/ui/input/project.json
  UPDATE libs/web/shared/ui/media/project.json
  UPDATE libs/web/shared/ui/media-cover/project.json
  UPDATE libs/web/shared/ui/media-order/project.json
  UPDATE libs/web/shared/ui/media-summary/project.json
  UPDATE libs/web/shared/ui/media-table/project.json
  UPDATE libs/web/shared/ui/play-button/project.json
  UPDATE libs/web/shared/ui/playlist-list/project.json
  UPDATE libs/web/shared/ui/spinner/project.json
  UPDATE libs/web/shared/ui/track-current-info/project.json
  UPDATE libs/web/shared/ui/track-main-info/project.json
  UPDATE libs/web/shared/ui/tracks-loading/project.json
  UPDATE libs/web/shared/ui/work-in-progress/project.json
  UPDATE libs/web/shared/utils/project.json
  UPDATE libs/web/shell/feature/project.json
  UPDATE libs/web/shell/ui/album-art-overlay/project.json
  UPDATE libs/web/shell/ui/layout/project.json
  UPDATE libs/web/shell/ui/main-view/project.json
  UPDATE libs/web/shell/ui/nav-bar/project.json
  UPDATE libs/web/shell/ui/nav-links/project.json
  UPDATE libs/web/shell/ui/now-playing-bar/project.json
  UPDATE libs/web/shell/ui/player-controls/project.json
  UPDATE libs/web/shell/ui/player-playback/project.json
  UPDATE libs/web/shell/ui/player-volume/project.json
  UPDATE libs/web/shell/ui/social-share/project.json
  UPDATE libs/web/shell/ui/top-bar/project.json
  UPDATE libs/web/shell/ui/user-dropdown/project.json
  UPDATE libs/web/shell/ui/visualization-toggle/project.json
  UPDATE libs/web/tracks/data-access/project.json
  UPDATE libs/web/tracks/feature/project.json
  UPDATE libs/web/visualizer/data-access/project.json
  UPDATE libs/web/visualizer/feature/project.json
  UPDATE libs/web/visualizer/ui/project.json
  UPDATE migrations.json
---------------------------------------------------------
Ran simplify-eslint-patterns from @nx/linter
  Simplify eslintFilePatterns

  UPDATE apps/angular-spotify/project.json
  UPDATE libs/web/album/data-access/project.json
  UPDATE libs/web/album/feature/detail/project.json
  UPDATE libs/web/album/feature/list/project.json
  UPDATE libs/web/album/feature/shell/project.json
  UPDATE libs/web/album/ui/album-track/project.json
  UPDATE libs/web/artist/data-access/project.json
  UPDATE libs/web/artist/feature/project.json
  UPDATE libs/web/artist/ui/artist-top-track/project.json
  UPDATE libs/web/artist/ui/artist-top-tracks/project.json
  UPDATE libs/web/auth/data-access/project.json
  UPDATE libs/web/auth/ui/unauthorized-modal/project.json
  UPDATE libs/web/auth/util/project.json
  UPDATE libs/web/browse/data-access/project.json
  UPDATE libs/web/browse/feature/categories/project.json
  UPDATE libs/web/browse/feature/category/project.json
  UPDATE libs/web/browse/feature/shell/project.json
  UPDATE libs/web/browse/ui/category-cover/project.json
  UPDATE libs/web/container-queries/project.json
  UPDATE libs/web/future-responsive/project.json
  UPDATE libs/web/home/data-access/project.json
  UPDATE libs/web/home/feature/project.json
  UPDATE libs/web/home/ui/featured-playlists/project.json
  UPDATE libs/web/home/ui/greeting/project.json
  UPDATE libs/web/home/ui/recent-played/project.json
  UPDATE libs/web/playlist/data-access/project.json
  UPDATE libs/web/playlist/feature/detail/project.json
  UPDATE libs/web/playlist/feature/list/project.json
  UPDATE libs/web/playlist/ui/playlist-track/project.json
  UPDATE libs/web/search/data-access/project.json
  UPDATE libs/web/search/feature/project.json
  UPDATE libs/web/settings/data-access/project.json
  UPDATE libs/web/settings/feature/project.json
  UPDATE libs/web/shared/app-config/project.json
  UPDATE libs/web/shared/app-init/project.json
  UPDATE libs/web/shared/data-access/models/project.json
  UPDATE libs/web/shared/data-access/spotify-api/project.json
  UPDATE libs/web/shared/data-access/store/project.json
  UPDATE libs/web/shared/directives/click-stop-propagation/project.json
  UPDATE libs/web/shared/directives/data-size-observer/project.json
  UPDATE libs/web/shared/pipes/duration-pipe/project.json
  UPDATE libs/web/shared/ui/icon/project.json
  UPDATE libs/web/shared/ui/input/project.json
  UPDATE libs/web/shared/ui/media/project.json
  UPDATE libs/web/shared/ui/media-cover/project.json
  UPDATE libs/web/shared/ui/media-order/project.json
  UPDATE libs/web/shared/ui/media-summary/project.json
  UPDATE libs/web/shared/ui/media-table/project.json
  UPDATE libs/web/shared/ui/play-button/project.json
  UPDATE libs/web/shared/ui/playlist-list/project.json
  UPDATE libs/web/shared/ui/spinner/project.json
  UPDATE libs/web/shared/ui/track-current-info/project.json
  UPDATE libs/web/shared/ui/track-main-info/project.json
  UPDATE libs/web/shared/ui/tracks-loading/project.json
  UPDATE libs/web/shared/ui/work-in-progress/project.json
  UPDATE libs/web/shared/utils/project.json
  UPDATE libs/web/shell/feature/project.json
  UPDATE libs/web/shell/ui/album-art-overlay/project.json
  UPDATE libs/web/shell/ui/layout/project.json
  UPDATE libs/web/shell/ui/main-view/project.json
  UPDATE libs/web/shell/ui/nav-bar/project.json
  UPDATE libs/web/shell/ui/nav-links/project.json
  UPDATE libs/web/shell/ui/now-playing-bar/project.json
  UPDATE libs/web/shell/ui/player-controls/project.json
  UPDATE libs/web/shell/ui/player-playback/project.json
  UPDATE libs/web/shell/ui/player-volume/project.json
  UPDATE libs/web/shell/ui/social-share/project.json
  UPDATE libs/web/shell/ui/top-bar/project.json
  UPDATE libs/web/shell/ui/user-dropdown/project.json
  UPDATE libs/web/shell/ui/visualization-toggle/project.json
  UPDATE libs/web/tracks/data-access/project.json
  UPDATE libs/web/tracks/feature/project.json
  UPDATE libs/web/visualizer/data-access/project.json
  UPDATE libs/web/visualizer/feature/project.json
  UPDATE libs/web/visualizer/ui/project.json
---------------------------------------------------------
Ran move-options-to-target-defaults from @nx/linter
  Move executor options to target defaults

  UPDATE nx.json
---------------------------------------------------------
Ran block-template-entities from @angular/core
  Angular v17 introduces a new control flow syntax that uses the @ and } characters. This migration replaces the existing usages with their corresponding HTML entities.

  UPDATE libs/web/shared/ui/work-in-progress/src/lib/work-in-progress.component.html
---------------------------------------------------------
Ran ngrx-store-devtools-migration-17-0-0-beta from @ngrx/store-devtools
  The road to v17-beta.1

  UPDATE libs/web/shell/feature/src/lib/build-specifics/index.ts
---------------------------------------------------------

 >  NX   Running 'yarn' to make sure necessary packages are installed

[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/common@>= 10.x <= 15.x".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/core@>= 10.x <= 15.x".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/router@>= 10.x <= 15.x".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/animations@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/common@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/forms@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/core@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/platform-browser@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/router@^15.0.1".
warning "ng-zorro-antd > @angular/cdk@15.2.8" has incorrect peer dependency "@angular/core@^15.0.0 || ^16.0.0".
warning "ng-zorro-antd > @angular/cdk@15.2.8" has incorrect peer dependency "@angular/common@^15.0.0 || ^16.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/common@^15.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/core@^15.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/platform-browser@^15.0.0".
warning " > @ngneat/svg-generator@7.0.3" has unmet peer dependency "svgo@>=3.0.0".
[4/4] 🔨  Building fresh packages...
success Saved lockfile.
$ node ./decorate-angular-cli.js && husky install

 >  NX   Decoration of the Angular CLI did not complete successfully

husky - Git hooks installed

 >  NX   Successfully finished running migrations from 'migrations.json'. This workspace is up to date!

I encountered an issue while running nx serve this time. The problem is in the promp-update.service.ts file where the UpdateAvailableEvent has been removed. To resolve this, I followed the instructions provided in the Updating to the latest version guide to force update the service worker.

Error: libs/web/shared/app-init/src/lib/promp-update.service.ts:3:20 - error TS2305: Module '"@angular/service-worker"' has no exported member 'UpdateAvailableEvent'.

3 import { SwUpdate, UpdateAvailableEvent } from '@angular/service-worker';
                     ~~~~~~~~~~~~~~~~~~~~

Error: libs/web/shared/app-init/src/lib/promp-update.service.ts:17:25 - error TS2339: Property 'available' does not exist on type 'SwUpdate'.

17     return this.updates.available.pipe(
                           ~~~~~~~~~

Error: libs/web/shared/app-init/src/lib/promp-update.service.ts:21:55 - error TS18046: 'version' is of type 'unknown'.

21             `[Angular Spotify] PWA is updating from ${version.current.hash} to ${version.available.hash}...`
                                                         ~~~~~~~

Error: libs/web/shared/app-init/src/lib/promp-update.service.ts:21:82 - error TS18046: 'version' is of type 'unknown'.

21             `[Angular Spotify] PWA is updating from ${version.current.hash} to ${version.available.hash}...`

Here is the updated code:

forceUpdate(): Observable<VersionEvent | null> {
  if (!this.updates.isEnabled) {
    return of(null);
  }
  return this.updates.versionUpdates.pipe(
    filter((evt) => evt.type === 'VERSION_READY'),
    tap(() => {
      this.updates.activateUpdate().then(() => {
        if (
          confirm(
            `There is a new version of Angular Spotify available! Would you like to upgrade now?`
          )
        ) {
          this.document.location.reload();
        }
      });
    })
  );
}

Running nx serve again and it is working now.

nx migrate 18.2.0 (support Angular 17.3.0)

This should be the easiest one as it is just a minor update.

yarn nx migrate 18.2.0
yarn nx migrate --run-migrations

See the full log of nx migrate 18.2.0

> yarn nx migrate 18.2.0                          ✔  16:48:04
yarn run v1.22.19
$ nx migrate 18.2.0
Fetching meta data about packages.
It may take a few minutes.
Fetching nx@18.2.0
Fetching @nx/js@18.2.0
Fetching @nx/eslint@18.2.0
Fetching @nx/eslint-plugin@18.2.0
Fetching @nx/jest@18.2.0
Fetching @nx/workspace@18.2.0
Fetching @nx/angular@18.2.0
Fetching @nx/cypress@18.2.0
Fetching @angular/core@17.3.2

 NX   The migrate command has run successfully.

- package.json has been updated.
- migrations.json has been generated.


 NX   Next steps:

- Make sure package.json changes make sense and then run 'yarn',
- Run 'yarn nx migrate --run-migrations'
- To learn more go to https://nx.dev/features/automate-updating-dependencies

✨  Done in 15.74s.

> yarn nx migrate --run-migrations               ✔ 16:49:19
yarn run v1.22.19
$ nx migrate --run-migrations

 NX   Running 'yarn' to make sure necessary packages are installed

[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/common@>= 10.x <= 15.x".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/core@>= 10.x <= 15.x".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/router@>= 10.x <= 15.x".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/animations@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/common@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/forms@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/core@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/platform-browser@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/router@^15.0.1".
warning "ng-zorro-antd > @angular/cdk@15.2.8" has incorrect peer dependency "@angular/core@^15.0.0 || ^16.0.0".
warning "ng-zorro-antd > @angular/cdk@15.2.8" has incorrect peer dependency "@angular/common@^15.0.0 || ^16.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/common@^15.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/core@^15.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/platform-browser@^15.0.0".
warning " > @ngneat/svg-generator@7.0.3" has unmet peer dependency "svgo@>=3.0.0".
[4/4] 🔨  Building fresh packages...
success Saved lockfile.
$ node ./decorate-angular-cli.js && husky install

 NX   Decoration of the Angular CLI did not complete successfully

husky - Git hooks installed
$ nx migrate --run-migrations
$ nx _migrate --run-migrations

 NX   Running migrations from 'migrations.json'

Ran 18.0.0-disable-adding-plugins-for-existing-workspaces from nx
  Updates nx.json to disabled adding plugins when generating projects in an existing Nx workspace

  UPDATE nx.json
---------------------------------------------------------
Ran update-angular-cli-version-17-2-0 from @nx/angular
  Update the @angular/cli package version to ~17.2.0.

  UPDATE package.json
---------------------------------------------------------
Ran move-default-base-to-nx-json-root from nx
  Moves affected.defaultBase to defaultBase in `nx.json`

  UPDATE nx.json
---------------------------------------------------------
Ran update-angular-cli-version-17-3-0 from @nx/angular
  Update the @angular/cli package version to ~17.3.0.

  UPDATE package.json
---------------------------------------------------------

 NX   Running 'yarn' to make sure necessary packages are installed

[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/common@>= 10.x <= 15.x".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/core@>= 10.x <= 15.x".
warning " > @sentry/angular@7.49.0" has incorrect peer dependency "@angular/router@>= 10.x <= 15.x".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/animations@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/common@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/forms@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/core@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/platform-browser@^15.0.1".
warning " > ng-zorro-antd@15.1.0" has incorrect peer dependency "@angular/router@^15.0.1".
warning "ng-zorro-antd > @angular/cdk@15.2.8" has incorrect peer dependency "@angular/core@^15.0.0 || ^16.0.0".
warning "ng-zorro-antd > @angular/cdk@15.2.8" has incorrect peer dependency "@angular/common@^15.0.0 || ^16.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/common@^15.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/core@^15.0.0".
warning "ng-zorro-antd > @ant-design/icons-angular@15.0.0" has incorrect peer dependency "@angular/platform-browser@^15.0.0".
warning " > @ngneat/svg-generator@7.0.3" has unmet peer dependency "svgo@>=3.0.0".
[4/4] 🔨  Building fresh packages...
success Saved lockfile.
$ node ./decorate-angular-cli.js && husky install

 NX   Decoration of the Angular CLI did not complete successfully

husky - Git hooks installed

 NX   Successfully finished running migrations from 'migrations.json'. This workspace is up to date!

✨  Done in 73.12s.

Voila! The migration is done. I have successfully migrated from Angular 15 to Angular 17 in Nx.

Improve Largest Contentful Paint (LCP)

Thu, 01 Feb 2024 08:30:00 GMT

Times really flies. Since the last article on improving FCP, it has been almost half a year. In this article, we’ll explore how to improve Largest Contentful Paint (LCP).

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) is one of the three Core Web Vitals metrics, and it represents how quickly the main content of a web page is loaded. Specifically, LCP measures the time from when the user initiates loading the page until the largest image or text block is rendered within the viewport.

What elements are considered?

As currently specified in the Largest Contentful Paint API, the types of elements considered for Largest Contentful Paint are:

<img> elements (the first frame presentation time is used for animated content such as GIFs or animated PNGs)
<image> elements inside an <svg> element
<video> elements (the poster image load time or first frame presentation time for videos is used—whichever is earlier)
An element with a background image loaded using the url() function, (as opposed to a CSS gradient)
Block-level elements containing text nodes or other inline-level text element children.

Understanding your LCP metric

Before optimizing LCP, developers should seek to understand if they even have an LCP issue, and the extent of any such issue.

LCP can be measured in a number of tools and not all of these measure LCP in the same way. To understand LCP of real users, we should look at what real users are experiencing, rather than what a lab-based tool like Lighthouse or local testing shows. These lab-based tools can give a wealth of information to explain and help you improve LCP, but be aware that lab tests alone may not be entirely representative of what your actual users experience.

LCP data based on real users can be surfaced from Real User Monitoring (RUM) tools installed on a site, or by using the Chrome User Experience Report (CrUX) which collect anonymous data from real Chrome users for millions of websites

The Performance panel of Chrome DevTools shows your local LCP experience next to the page or origin’s CrUX LCP in the live metrics view.

What is a good LCP score?

To provide a good user experience, sites should strive to have an LCP of 2.5 seconds or less for at least 75% of page visits.

Improve LCP

Now that we know how to get the first bytes out the door, we can make some infrastructure changes to ensure that we’re delivering our bytes as quickly as possible.

But how do we ensure that the bytes we’re sending to load the page are the right ones to reach this point of completion as soon as possible? As a reminder, the Largest Contentful Paint (LCP) is the time between the start of the page load and when the user sees that most of the page is ready, or almost ready.

Let’s look at the sequence of events in a simplified version of what we would see in the performance panel of Google DevTools. At the beginning of a request, the first thing we need to do is fetch the HTML document. We need to pull down the initial document and have the browser parse it to determine what other resources are needed.

As the document is being parsed, the browser finds other resources that need to be downloaded, such as a CSS file in the head of the page. This CSS file might then require additional resources like a background image, a font, or another CSS file import, causing a chain of events that can increase load time.
You’ll also likely have images in the file, which the browser will try to download in parallel as much as possible. However, depending on the number of resources and the browser’s parallel download capabilities, some images might be deferred until later when there is available bandwidth.
Most applications will have some JavaScript, which often pulls down additional assets, such as other JavaScript files or modules. This can create a pattern where JavaScript loads more JavaScript, further delaying the LCP.

If we attach our metrics here, the First Contentful Paint (FCP) occurs right after the HTML is downloaded and the first elements are rendered on the screen. However, the LCP happens only after all other resources, such as images, JavaScript, and CSS, have been fully loaded and rendered.

So how do we achieve a faster LCP? We do this by reducing the number of tasks the browser needs to perform and focusing on delivering the user’s most important content as quickly as possible.

For a well-optimized page, you want your LCP resource request to start loading as early as it can, and you want the LCP element to render as quickly as possible after the LCP resource finishes loading. To help visualize whether or not a particular page is following this principle, you can break down the total LCP time into the following sub-parts:

Time to First Byte (TTFB): The time from when the user initiates loading the page until the browser receives the first byte of the HTML document response.
Resource load delay: The time between TTFB and when the browser starts loading the LCP resource. If the LCP element doesn’t require a resource load to render (for example, if the element is a text node rendered with a system font), this time is 0.
Resource load duration: The duration of time it takes to load the LCP resource itself. If the LCP element doesn’t require a resource load to render, this time is 0.
Element render delay: The time between when the LCP resource finishes loading and the LCP element rendering fully.

1. Eliminate resource load delay

The goal in this step is to ensure the LCP resource starts loading as early as possible. While in theory the earliest a resource could start loading is immediately after TTFB, in practice there is always some delay before browsers actually start loading resources.

A good rule of thumb is that your LCP resource should start loading at the same time as the first resource loaded by that page. Or, to put that another way, if the LCP resource starts loading later than the first resource, then there’s opportunity for improvement.

Generally speaking, there are two factors that affect how quickly an LCP resource can be loading:

When the resource is discovered.
What priority the resource is given.

Optimize when the resource is discovered

To ensure your LCP resource starts loading as early as possible, it’s critical that the resource is discoverable in the initial HTML document response by the browser’s preload scanner. For example, in the following cases, the browser can discover the LCP resource by scanning the HTML document response:

The LCP element is an <img> element, and its src or srcset attributes are present in the initial HTML markup.
The LCP element requires a CSS background image, but that image is preloaded using <link rel="preload"> in the HTML markup (or using a Link header).
The LCP element is a text node that requires a web font to render, and the font is loaded using <link rel="preload"> in the HTML markup (or using a Link header).

Here are some examples where the LCP resource cannot be discovered from scanning the HTML document response:

The LCP element is an <img> that is dynamically added to the page using JavaScript.
The LCP element is lazily loaded with a JavaScript library that hides its src or srcset attributes (often as data-src or data-srcset).
The LCP element requires a CSS background image.

In each of these cases, the browser needs to run the script or apply the stylesheet—which usually involves waiting for network requests to finish—before it can discover the LCP resource and could start loading it. This is never optimal.

To eliminate unnecessary resource load delay, your LCP resource should be discoverable from the HTML source. In cases where the resource is only referenced from an external CSS or JavaScript file, the LCP resource should be preloaded with a high fetch priority, for example:

<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css" />

<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link
  rel="preload"
  fetchpriority="high"
  as="image"
  href="/path/to/hero-image.webp"
  type="image/webp"
/>

Optimize the priority the resource is given

Even if the LCP resource is discoverable from the HTML markup, it still may not start loading as early as the first resource. This can happen if the browser preload scanner’s priority heuristics don’t recognize that the resource is important, or if it determines that other resources are more important.

For example, you can delay your LCP image using HTML if you set loading="lazy" on your <img> element. Using lazy loading means that the resource won’t be loaded until after layout confirms the image is in the viewport and so may begin loading later than it otherwise would.

Even without lazy loading, images are not initially loaded with the highest priority by browsers as they are not render-blocking resources. You can hint to the browser as to which resources are most important using the fetchpriority attribute for resources that could benefit from a higher priority:

<img fetchpriority="high" src="/path/to/hero-image.webp" />

After you have optimized your LCP resource priority and discovery time, your network waterfall should look like this (with the LCP resource starting at the same time as the first resource):

2. Eliminate element render delay

The goal in this step is to ensure the LCP element can render immediately after its resource has finished loading, no matter when that happens.

The primary reason the LCP element wouldn’t be able to render immediately after its resource finishes loading is if rendering is blocked for some other reason:

Rendering of the entire page is blocked due to stylesheets or synchronous scripts in the <head> that are still loading.
The LCP resource has finished loading, but the LCP element has not yet been added to the DOM (it’s waiting for some JavaScript code to load).

Defer or inline render-blocking JavaScript

It is almost never necessary to add synchronous scripts (scripts without the async or defer attributes) to the <head> of your pages, and doing so will almost always have a negative impact on performance.

In cases where JavaScript code needs to run as early as possible in the page load, it’s best to inline it so rendering isn’t delayed waiting on another network request. As with stylesheets, though, you should only inline scripts if they’re very small.

❌ DON’T

<head>
  <script src="/path/to/main.js"></script>
</head>

✅ DO

<head>
  <script>
    // Inline script contents directly in the HTML.
    // IMPORTANT: only do this for very small scripts.
  </script>
</head>

3. Reduce resource load duration

The goal of this step is to reduce the time spent transferring the bytes of the resource over the network to the user’s device. In general, there are four ways to do that:

Reduce the size of the resource
- Use modern image formats
- Serve the optimal image size
Reduce the distance the resource has to travel.
- Image CDNs
Reduce contention for network bandwidth.
- Lazy load images
Eliminate the network time entirely.
- cache-control headers
- font-display: swap
- Reduce web font size

Use modern image formats.

The LCP resource of a page (if it has one) will either be an image or a web font. The following guides go into great detail about how to reduce the size of both:

AVIF and WebP are image formats that have superior compression and quality characteristics compared to their older JPEG and PNG counterparts. Encoding your images in these formats rather than JPEG or PNG means that they will load faster and consume less cellular data.

AVIF is supported in Chrome, Firefox, and Opera and offers smaller file sizes compared to other formats with the same quality settings.

WebP is supported in the latest versions of Chrome, Firefox, Safari, Edge, and Opera and provides better lossy and lossless compression for images on the web

Image CDNs

Image CDNs are a type of CDN that specializes in serving images. They can help reduce the distance the resource has to travel by caching images closer to the user and provide additional features like image optimization and resizing.

Lazy load images

Lazy loading images means that images are only loaded when they are in the viewport. This can reduce contention for network bandwidth by ensuring that images are only loaded when they are needed.

Summary

LCP is complex, and its timing can be affected by a number of factors. But if you consider that optimizing LCP is primarily about optimizing the load of the LCP resource, it can significantly simplify things.

At a high level, optimizing LCP can be summarized in a few steps:

Ensure the LCP resource starts loading as early as possible.
Ensure the LCP element can render as soon as its resource finishes loading.
Reduce the load time of the LCP resource as much as you can without sacrificing quality.

References

How to change VSCode terminal font?

Mon, 30 Oct 2023 17:32:00 GMT

Problem

So, I had to reinstall my computer and set up the terminal all over again. Here’s what I typically need:

iTerm (That’s the one most of my gang use)
Oh My Zsh
powerlevel10k
zsh-syntax-highlighting
zsh-autosuggestions
fzf

I’ll give you a step-by-step on that soon. But for now, iTerm looks great.

However, the VSCode terminal doesn’t look right. The font doesn’t load properly, and where I expect to see icons, there are question marks instead.

This guide will help you fix the font issue in the VSCode terminal.

Solution

Step 1. Open settings.json in VSCode

Hit Command ⌘ + Shift ⇧ + P in VSCode, type settings and select Preferences: Open User Settings (JSON)

Step 2. Add this code into settings.json

 "terminal.integrated.fontFamily": "MesloLGS NF",
 "terminal.integrated.defaultProfile.osx": "zsh",
 "terminal.external.osxExec": "iTerm.app",

If you’re wondering where I got MesloLGS NF from - You can find it on iTerm’s setting.

Just go to iTerm -> Settings -> Profiles -> Text -> Font

Step 3. Save & Restart VSCode

And voila! Your VSCode terminal should now have a new font.

@next/bundle-analyzer throw error Module not found: Can't resolve child_process

Sat, 16 Sep 2023 08:32:00 GMT

Problem

Recently I helped my friend to analyze why his Next.js project is slow. I installed @next/bundle-analyzer which can help us to analyze the bundle size. I follow their guideline for configuration

yarn add @next/bundle-analyzer
Update next.config.js:

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  i18n: {
    locales: ['en', 'vi'],
    defaultLocale: 'vi',
    localeDetection: false,
  },
}

const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
})

module.exports = withBundleAnalyzer(nextConfig)

Finally, run ANALYZE=true yarn build, it throws an error:

yarn run v1.22.19
$ next build
- info Loaded env from /root/Frontend/.env.production
- info Loaded env from /root/Frontend/.env
- info Linting and checking validity of types
Failed to compile.

./node_modules/opener/lib/opener.js
Module not found: Can't resolve 'child_process'

https://nextjs.org/docs/messages/module-not-found

Import trace for requested module:
./node_modules/webpack-bundle-analyzer/lib/utils.js
./node_modules/webpack-bundle-analyzer/lib/viewer.js
./node_modules/webpack-bundle-analyzer/lib/index.js
./node_modules/@next/bundle-analyzer/index.js
./next.config.js
./hooks/useAnalyzeUrl.js
./PageComponents/AnalyzePage/AnalyzePage.js
./pages/analyze/index.js


> Build failed because of webpack errors
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Solution

I found a solution from here. Basically we need to disable child_process and fs in webpack config. Here is the final next.config.js:

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  swcMinify: true,
  compress: false,
  i18n: {
    locales: ['en', 'vi'],
    defaultLocale: 'vi',
    localeDetection: false,
  },
+  webpack: (config, { isServer }) => {
+    if (!isServer) {
+      config.resolve.fallback.fs = false
+      config.resolve.fallback.child_process = false
+    }
+    return config
+  },
}

const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
})

module.exports = withBundleAnalyzer(nextConfig)

Angular Material 15 Migration

Sun, 03 Sep 2023 08:32:00 GMT

Angular Material 15 migration is part of our plan to migrate to Angular 15. It was successfully completed a few months ago, and we are now using Angular 15 in production. This document provides a step-by-step guide on how we migrated Angular Material to version 15, which involved migrating to MDC-based Angular Material components.

Many of the components in Angular Material v15 have been refactored to be based on Angular Material Design Components (MDC) for the Web. The refactored components offer improved accessibility and adherence to the Material Design spec.

What has changed?

The new components have different internal DOM and CSS styles. Since the MDC-based components are not API-compatible with the previous versions, you will need to update your code to use the new components. We follow two steps as mentioned on the Migrating to MDC-based Angular Material Components.

Step 1. Update to Angular Material v15

Angular Material includes a schematic to help migrate applications to use the new MDC-based components. To get started, upgrade your application to Angular Material 15.

ng update @angular/material@15

As part of this update, a schematic will run to automatically move your application to use the “legacy” imports containing the old component implementations. This provides a quick path to getting your application running on v15 with minimal manual changes. After the update, it should look like this:

We then commit the changes and push to the remote repository. Everything should work as before, nothing changes.

Step 2. Update to MDC-based components

Then we schedule to update to MDC-based components. This is a manual process that involves updating your application to use the new component implementations.

First, we run the migration command to switch from the legacy component implementations to the new MDC-based ones.

ng generate @angular/material:mdc-migration

Upon running the command, you will be prompted to select which components you would like to migrate. We divided into three steps:

Form Field, Input
Select
AutoComplete

Why is it necessary to break the migration of Angular Material into three parts?

This is because deep down inside the MatSelectModule, MatAutoCompleteModule, and MatInputModule, they all import the MatFormField component.

By breaking the migration into three parts, with the following modules are being migrated one by one:

1️⃣ MatFormFieldModule and MatInputModule
2️⃣ MatSelectModule
3️⃣ MatAutoCompleteModule

We avoid a declaration conflict by doing so.

TODO(mdc-migration)

ng generate @angular/material:mdc-migration command updates your styles and templates to the new implementations as much as it can automatically.

Changes that are deprecated and require modification will have the prefix /* TODO(mdc-migration):. Our job will be to fix them all, one by one.

/* TODO(mdc-migration):

Key changes

Below is what happened after I ran the migration script.

Dimensions are now different. Everything is now bigger, from height, width to paddings, margins, and animation durations.
- For textbox heights, we need to revert back to the magical 67px that exists in the previous version. The width of the elements remains unchanged.
- For paddings, horizontal paddings are now 16px instead of 8px like it used to be.
- Animation durations of the labels are now faster, 150ms by default. We need to change it back to 400ms.
Default required marker “ are now always enabled by default. We need to hide it by adding the following lines in our app.module.ts.

{
   provide: MAT_FORM_FIELD_DEFAULT_OPTIONS,
   useValue: {
      hideRequiredMarker: true,
   },
},

Manually fixing the style changes

The main changes we’ll need to fix will mostly be style changes. After running the migrations, most places where we use the mat-form-field component will be broken, as we heavily customize using CSS selector to meet our needs, e.g .mat-select now become .mat-mdc-select.

For instance, I had to make several changes such as:

ℹ️ Update .mat-form-field-flex to .mat-mdc-text-field-wrapper selector:

ℹ️ mat-select now become .mat-mdc-select selector:

ℹ️ .mat-input-element to .mat-mdc-input-element selector:

Not to mention a lot of places we need to compare the new implementation with the existing one and make changes accordingly.

Conclusion

I hope this article has given you a better understanding of how we moved to Angular Material 15 and the changes we made along the way. We successfully completed the migration to Angular Material 15 and are now using it in our production environment. Although the migration was challenging, it was definitely worth it. If you have any questions or comments, please feel free to leave them below!

Improve First Contentful Paint (FCP)

Mon, 14 Aug 2023 08:30:00 GMT

Even though First Contentful Paint (FCP) is not a Core Web Vital, it is still an important metric to measure and improve. The Lighthouse report includes FCP as one of the metrics to measure web performance.

First Contentful Paint (FCP) measures the time from when the user first navigates to the page to when any part of the page’s content is rendered on the screen. Following FCP are other metrics like Largest Contentful Paint (LCP), which is part of the Core Web Vitals. Therefore, improving FCP will also improve LCP.

What is a good FCP score?

To provide a good user experience, sites should strive to have a First Contentful Paint of 1.8 seconds or less. To ensure you’re hitting this target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.

How to Improve FCP

As a quick reminder, the first contentful paint is the time from when the page starts loading until the user sees an indication that the page is going to load. Another way of saying that is we need to respond quickly.

So how do we do that? How do we make sure that we’re responding quickly? Well, let’s conceptually think about our website again.

All websites inherently have:

A set of servers, hosts, or virtual machines.
A set of documents that need to be delivered across the network to your users.

There are a few different parts of this process that can contribute to slowing down the first contentful paint.

Your servers need to be quick. You need to deliver small documents that can be sent efficiently, and the number of hops through the network needs to be as short as possible.

Quick Servers

So, how do we make sure your server is quick? We need to ensure that your server is sized correctly for what you’re doing. This is the first step in improving it by focusing on your servers.

The specific changes to your servers will depend on what you’re doing and what technology stack you’re using. But essentially, you need to focus on three things:

Sized correctly: First, size the hardware, virtual machine, network, or whatever your constraining factors are correctly. Ensure that you have enough overhead in the machines you’ve selected to deliver the content you need.
Minimal processing: Second, minimize the processing needed to fulfill the request. For example, if you just need to serve an index.html page to your users, you probably shouldn’t be making calls to your database unless there’s something especially interesting that you need to do.
Network bandwidth: Third, the bandwidth to your servers needs to be large enough to fulfill all the requests coming in at once.

Small Documents

There are two major things to consider here: the size of our content and how we compress it.

Content size: How do you deliver as small a payload as possible while still getting the effectiveness you need? This will depend on your application, but if you’re delivering an HTML page, a JavaScript file, or an image, there are certain upper limits on how much you should send. For an HTML document, if you’re sending anything more than 80 or 100k in total size, that’s too much. An image might be 1mb at its upper limit. If you’re sending larger files, you’re sending too much content to be consumed efficiently.

Compression: Even if you’re sending a 100k HTML document, how you compress that document over the wire can greatly improve speed. Most platforms support Gzip compression, and newer web platforms support more advanced compression such as Brotli. The specific compression method will depend on your technology stack, but compressing your documents can greatly reduce the number of bytes sent over the wire.

See the following example of how much you can save by compressing your content. I used curl with the —compressed flag to download the HTML of a website. The original size is 700kb, and the compressed size is 200kb.

curl  -o /dev/null -s -w "File size: %{size_download} bytes\n" https://jira.trungk18.com/main.js
File size: 756498 bytes

curl -H "Accept-Encoding: gzip" -o /dev/null -s -w "File size: %{size_download} bytes\n" https://jira.trungk18.com/main.js
File size: 212983 bytes

curl -H "Accept-Encoding: br" -o /dev/null -s -w "File size: %{size_download} bytes\n" https://jira.trungk18.com/main.js
File size: 215579 bytes

Short Transmissions

If we take a look at the network, there’s more than one thing happening. There’s where our servers are in your data center, Amazon, Microsoft, Digital Ocean, or wherever you host your content. And there’s a series of network hops in their infrastructure, which you largely don’t control.

On the other side, you have your users, connected to their own ISP or wireless network, with a series of hops to manage that network.

Between them is the infrastructure of the Internet, and this time is something we can control based on where we place our servers and how far they are from our users.

For example, if your servers are on the East Coast of the United States and your user is on the West Coast, the minimum time is 200 milliseconds due to the speed of light and network hardware. Reducing this distance can greatly improve performance.

So how do you reduce this distance? The most effective way is to use CDNs.

CDNs take the content and place a copy at the edge of each user network, so they can grab it without crossing the Internet. Most CDNs, like CloudFlare and Akamai, do this.

When a user makes a request, the CDN will pick it up, call your server if they don’t already have a copy, cache the response, and serve it to every user who asks for it.

Essentially, we’re doing fewer things by not processing each request across the entire network. This is largely about putting infrastructure in place.

Demo

Putting infrastructure in place is very hard to demo and depends on your infrastructure. For example, compression is mostly supported out of the box on most platforms. Some of my web applications are deployed to Netlify and have Content-Encoding: zstd in the response headers by default without me doing anything.

Summary

To improve First Contentful Paint (FCP), you need to focus on the following:

Quick servers: Ensure your servers are sized correctly, minimize processing, and have enough network bandwidth.
Small documents: Deliver small payloads and compress them effectively.
Short transmissions: Use CDNs to reduce the distance between your servers and your users.

References

Web Performance Fundamentals

Measuring Web Performance

Sat, 15 Jul 2023 08:30:00 GMT

Understanding how to measure web performance is crucial for ensuring a fast and efficient user experience. In this guide, we’ll explore various tools like Lighthouse, WebPageTest, and Chrome DevTools to help you measure web performance effectively.

Before diving into these tools, it’s important to understand the types of performance data you can collect. There are two main types: lab data and field data.

Lab Data and Field Data

Lab Data

Lab data describes how hypothetical users may experience your website. This data is collected through controlled tests, such as those performed by Lighthouse. It represents a single webpage load from a specific location on the network.

Lab data is often referred to as “Synthetic Testing” because it measures performance from a known device and network. It provides an estimate of performance rather than actual user experience.

Field Data

Field data describes how real users actually experienced your website. Field data is also known as Real User Monitoring (RUM), and is typically collected by monitoring real user experiences using JavaScript on the pages they load, and reporting various metrics to an analytics solution

Field data can be extensive and sometimes noisy, meaning it includes irrelevant information. To make sense of field data, you need to use statistical methods.

Interpreting Performance Data with Statistics

Averages are a simple way to understand data sets, but they can be misleading due to uneven performance distribution. For example, an average Lighthouse score of 80 could result from very different performance scenarios.

To get a clearer picture, use median and percentiles.

Median and Percentiles

The median score is the middle value in a sorted list of performance scores, representing the typical user experience. Percentiles like p50, p75, and p95 show the performance for different segments of users:

p50 (50th percentile): This is the median score, indicating that 50% of users have a performance score below this value and 50% have a score above it. It represents the “typical user” experience.
p75 (75th percentile): This score indicates that 75% of users have a performance score below this value and 25% have a score above it. It represents the experience of “most users.”
p95 (95th percentile): This score indicates that 95% of users have a performance score below this value and only 5% have a score above it. It represents the experience of the “worst users.”

Here’s a simple code example to calculate percentiles:

// Performance scores, sorted.
var lighthouseScores = [100, 100, 90, 90, 90, 80, 70, 70, 60, 50]

// Desired percentile to calculate.
var percentile = 0.75

// Find the index 75% into the array.
var idx = Math.round((lighthouseScores.length - 1) * percentile)

var p75Score = lighthouseScores[idx]

Tools to Measure Web Performance

Now that you understand the metrics and methods for measuring web performance, let’s look at the tools available to help you

Refer to Core Web Vitals workflows with Google tools

1. Lighthouse & PageSpeed Insights

Type: Synthetic Lab Data

Lighthouse is an open-source tool from Google that can be run from Chrome DevTools or from the command line.

Lighthouse runs from you local computer, so it’s measuring the performance you experience with your hardware on your network.

Lighthouse-CI is a related tool that runs Lighthouse during project builds and deploys to assist with performance regression testing. It presents a Lighthouse report along with pull requests, and tracks performance metrics over time.

It generates an overall performance “score” to make you feel good (or bad) about your site’s speed. This score can be useful, but has some limitations.

There are several places where you can run Lighthouse-as-a-Service from elsewhere on the internet, including Google’s PageSpeed Insights.

2. Chrome User Experience Report (CrUX)

Type: Field Data

The Chrome browser itself collects performance metrics from opt-in users for the top million domains on the internet. Google publishes these metrics in the Chrome User Experience Report or CrUX. It’s real-user data!

CrUX only represents Chrome users, and even then, only a subset of Chrome users

3. Google Search Console

Google Search Console shows the analytics, issues, and performance recorded by the Googlebot crawler when Google indexes your website. This includes User Experience metrics like the Core Web Vitals.

Although the Search Console metrics are synthetic, they are what Google will use to rank your site in search results. They represent a very important user: Google.

The metrics you’ll see in Search Console will be quite slow to update, depending on the traffic to your website. It could be a week or more for Google to see changes in your performance scores, and the reports are very generic.

You need to use Search Console to see how Google ranks your performance, but it’s not very useful for testing or discovering performance issues.

4. Chrome DevTools (Update September 2024)

Type: Synthetic Lab Data (with some context from CrUX)

Chrome has so many amazing updates since the last time I wrote this article. The Chrome DevTools now has a new Performance panel that shows you the Core Web Vitals for your website.

When you open the Performance panel, it immediately captures and shows you your local Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics tells you their score (good, needs improvement, or bad).

The new Performance panel is pretty cool, thus I decided to write a new article Performance panel: Analyze your website’s performance about it. Stay tuned!

The Performance panel is a developer tool that primarily provides lab data—though with some context from CrUX. It’s not a substitute for field data.

5. WebPageTest

Type: Synthetic Lab Data

WebPageTest is a free hosted service that performs performance tests on public websites. It can do a lot more things than Lighthouse, like setting up network locations, network speeds, and customizing requests.

It also produces a more detailed (and more complex) report with network location, breakdown of timings, and a detailed waterfall chart.

WebPageTest is great for auditing live websites to better understand how they are performing in production.

Summary

Measuring web performance is essential for ensuring a fast and efficient user experience. By using tools like Lighthouse, WebPageTest, and Chrome DevTools, you can collect lab and field data to evaluate your website’s performance effectively.

References

Angular augmenting native elements

Mon, 19 Jun 2023 14:00:00 GMT

We build new components every day in our Angular application. A few core principles, such as augmenting native elements or utilising the directive selector, could help develop fantastic components. In this post, we’ll go back to the basics to revisit the power of Angular directive selectors in ways that simplify the component’s implementation and improve accessibility.

Components are the most basic UI building block of an Angular app. An Angular app contains a tree of Angular components.

We will look into a rather simple use case and see how augmenting native elements could help.

Source code and slide

This blog post is based on my recent presentation at NGRome 2022.

View the original slide → trungvose.com/ngrome22
View the demo → https://stackblitz.com/edit/angular-directives-use-case

Creating a custom button component

We will create a custom button component with three variants

A button with simply a text
A button with text and an icon
A button with text and an icon, behave like a <a> tag and open a new URL when clicked.

stackblitz.com/edit/angular-directives-use-case ↗

Custom button #1

That’s the simple implementation for the first requirement that simple can render a button with specific styling and text content.

export type ButtonType = 'reset' | 'button' | 'submit'
export type ButtonTheme = 'primary' | 'secondary'

@Component({
  selector: 'shared-button',
  template: `
    <button
      class="button"
      [ngClass]="'btn-' + buttonTheme"
      [attr.type]="buttonType"
    >
      <span class="button-text">{{ buttonText }}</span>
    </button>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ButtonComponent {
  @Input() buttonText!: string
  @Input() buttonTheme: ButtonTheme = 'secondary'
  @Input() buttonType: ButtonType = 'button'
}

To create a new component in Angular, we usually need at least three parts:

A selector, in this case, is shared-button
The template to render when we use our component
A class that defines the behaviour of our component. In the use case of a button, there isn’t any behaviour needed.

That’s how we use it to render the first use-case, notice that you only need to give the [buttonText] input and we will have the text Login render inside the button for us.

Below is how it gets rendered into the DOM. As we can see there is a shared-button that wraps the real native button

Custom button #2

In the second example, we want to render the text along with an icon. The simplest way to do it is introducing new @Input() icon: string and our shared-button will use this icon to render with our favourite icon library, e.g. material icon. The code could potentially look like this:

export type ButtonType = 'reset' | 'button' | 'submit';
export type ButtonTheme = 'primary' | 'secondary';

@Component({
 selector: 'shared-button',
 template: `
   <button class="button" [ngClass]="'btn-' + buttonTheme" [attr.type]="buttonType">
     <span class="button-text">{{ buttonText }}</span>
+		 <mat-icon [svgIcon]="buttonIcon"></mat-icon>
   </button>
 `,
 changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ButtonComponent {
  @Input() buttonText!: string;
+ @Input() buttonIcon!: string;
}

However with this implementation, there are always certain constraints:

We always use mat-icon
The icon always displays after the text

With that, several questions arise:

What if I don’t want to use mat-icon but used just a font icon with a simple <i> tag? Or sometimes, an image with <img> tag
What if I want to place the icon, then the text?

To support the above requirements, it is so much easier if we can provide both text and icons together as a “template” to the button component. So that the component’s user can decide how he wants to arrange the content, or which icon library he wants to use.

We introduce a new @Input() buttonContent that accepts a TemplateRef instead of just a simple string. We can use something like content projection that does the same thing, however, let’s stick with TemplateRef for now.

@Component({
 selector: 'shared-button',
 template: `
   <button class="button" [ngClass]="'btn-' + buttonTheme" [attr.type]="buttonType">
     <span class="button-text">
       <ng-container> {{ buttonText }} </ng-container>
+      <ng-container *ngTemplateOutlet="buttonContent"> </ng-container>
     </span>
   </button>
 `,
})
export class ButtonComponent {
+ @Input() buttonContent!: TemplateRef<any>;
  @Input() buttonText!: string;
  @Input() buttonTheme: ButtonTheme = 'secondary';
  @Input() buttonType: ButtonType = 'button';
}

So with the new implementation, it is very flexible since we can essentially decide what template we want to render inside the button: maybe it is just a single icon, maybe the icon appears in front of the text, and in this example, we use a dedicated component twitter-icon. You know what I am talking about.

<shared-button [buttonContent]="twitterBtnTmpl">
  <ng-template #twitterBtnTmpl>
    Twitter <twitter-icon class="btn-icon"></twitter-icon>
  </ng-template>
</shared-button>

Below is how it gets rendered into the DOM. As we can see there is a shared-button that wraps the real native button as the previous #1 example.

Custom button #3

In the 3rd use case, things get a little more interesting. We want to have a link, that looks like a button. A link means when click, it opens an URL.

Looks simple enough, however, the real implementation was a bit more complicated than that.

A link could be either opened using routerLink for an internal Angular route or href for an external URL

We need to check whether the URL includes http or https to differentiate between internal and external URL
routerLink could require some query parameters
If the link is external and open with href, do we want to open it in a new tab using target="_blank"
We also know that if target="_blank" appears, we should set rel="noopener noreferrer" to a tag for safety reasons.

ℹ️ View the full shared-button implementation that supports link

type ButtonMode = 'internalURL' | 'externalURL' | 'button'
export type ButtonType = 'reset' | 'button' | 'submit'
export type ButtonTheme = 'primary' | 'secondary'

@Component({
selector: 'shared-button',
template: `
  <ng-container [ngSwitch]="buttonMode()">
    <button
      *ngSwitchCase="'button'"
      class="button"
      [ngClass]="'btn-' + buttonTheme"
      [attr.aria-label]="ariaLabel"
      [attr.disabled]="isDisabled ? true : null"
      [attr.type]="buttonType"
    >
      <img *ngIf="iconPath" alt="" class="btn-icon" [src]="iconPath" />
      <span class="button-text">
        <ng-container *ngIf="!!buttonText"> {{ buttonText }} </ng-container>
        <ng-container *ngTemplateOutlet="buttonContent"> </ng-container>
      </span>
    </button>

    <a
      *ngSwitchCase="'internalURL'"
      class="button"
      [ngClass]="'btn-' + buttonTheme"
      [routerLink]="redirectURL"
      [queryParams]="queryParams"
      [attr.aria-label]="ariaLabel"
      [attr.role]="roleType"
    >
      <img *ngIf="iconPath" class="btn-icon" [src]="iconPath" />
      <span class="button-text">
        <ng-container *ngIf="!!buttonText"> {{ buttonText }} </ng-container>
        <ng-container *ngTemplateOutlet="buttonContent"> </ng-container>
      </span>
    </a>

    <a
      *ngSwitchCase="'externalURL'"
      class="button"
      [ngClass]="'btn-' + buttonTheme"
      [href]="redirectURL"
      [attr.target]="isTargetBlank ? '_blank' : null"
      [attr.rel]="isTargetBlank ? 'noopener noreferrer' : null"
      [attr.aria-label]="ariaLabel"
      [attr.role]="roleType"
    >
      <img *ngIf="iconPath" class="btn-icon" [src]="iconPath" />
      <span class="button-text">
        <ng-container *ngIf="!!buttonText"> {{ buttonText }} </ng-container>
        <ng-container *ngTemplateOutlet="buttonContent"> </ng-container>
      </span>
    </a>
  </ng-container>
`,
})
export class ButtonComponent implements OnInit {
@HostBinding('class') fullButtonClass!: string
@HostBinding('class.shared-button') componentClass = true
@HostBinding('class.is-disabled') get isButtonDisabled(): boolean {
  return this.isDisabled
}

@Input() buttonClass!: string
@Input() buttonContent!: TemplateRef<any>
@Input() buttonText!: string
@Input() buttonTheme: ButtonTheme = 'secondary'
@Input() buttonType: ButtonType = 'button'
@Input() roleType: string | null = null
@Input() redirectURL!: string
@Input() queryParams: { [key: string]: string | number } | null = null
@Input() isDisabled!: boolean
@Input() isTargetBlank!: boolean
@Input() iconPath!: string
@Input() ariaLabel!: string

ngOnInit(): void {
  const classNames = [this.buttonClass, this.buttonTheme].filter(
    className => className
  )

  this.fullButtonClass = classNames.join(' ')
}

buttonMode(): ButtonMode {
  if (!this.redirectURLExists()) {
    return 'button'
  }

  if (this.isInternalURL()) {
    return 'internalURL'
  } else {
    return 'externalURL'
  }
}

private redirectURLExists(): boolean {
  return !!this.redirectURL
}

private isInternalURL(): boolean {
  return !(
    this.redirectURL.toString().startsWith('http://') ||
    this.redirectURL.toString().startsWith('https://')
  )
}
}

The following code could render our desired button

However, the button implementation might have @Input with different attributes that you used to work with e.g. isTargetBlank instead of just target or redirectURL instead normal href

Below is how it gets rendered into DOM, we have our shared-button as usual and inside it renders the <a> as we are expecting.

Also, if you don’t know about the implementation detail at all, it could easily end up in a situation where you render the whole button inside <a> tag to have the same anchor behaviour.

<a href="https://trungvose.com/"
    target="_blank">
   <shared-button
     [buttonContent]="readmoreTmpl"
     [buttonTheme]="'primary'"
   >
     <ng-template #readmoreTmpl>
       Readmore ↗
     </ng-template>
   </shared-button>
 </a>

In this case, the DOM structure will be a > shared-button > button and because both a and button are focusable, pressing Tab will focus into each one of them.

In the screenshot, we press Tab to have a default blue outline because we focus on a, press one more time you’ll see our custom outline because now it gets focused on button

This approach won’t scale very well

In all three examples, our implementation is increasingly its complexity when we need to introduce new functionality. However, what we want at the end is truly simple: apply certain classes to button and a so that it looks the way we want.

For the rest of the code, we are trying to duplicate the functionality of the button and a because they are hidden away within our shared-button component and we couldn’t access it otherwise.

Global attributes

Because we hide our button element from shared-button, if we want to support new button attributes, we will need to introduce one new @Input on our shared-button

However, each HTML element like button will also come with a list of global attributes ↗ it needs to support.

It included all ARIA attributes for making our web more accessible, which includes about 50+ more attributes.

So if our shared-button component suddenly needs to support more attributes, that’s how it might look.

@Input() ariaHidden: boolean;
@Input() ariaPlaceholder: string;
@Input() ariaPressed: string;
@Input() ariaReadonly: string;
@Input() ariaRequired: string;
@Input() ariaSelected: string;
@Input() ariaValueText: string;
@Input() ariaControls: string;
@Input() ariaDescribedBy: string;
@Input() ariaDescription: string;
@Input() ariaFlowTo: string;
@Input() ariaLabelledBy: string;
// and another 100 more Inputs 😏

Augmenting native elements

In angular.io accessibility guide, there is one small section that mentions Augmenting native elements approach.

Native HTML elements capture several standard interaction patterns that are important to accessibility. When authoring Angular components, you should re-use these native elements directly when possible, rather than re-implementing well-supported behaviors.

For example, instead of creating a custom element for a new variety of button, create a component that uses an attribute selector with a native <button> element. This most commonly applies to <button> and <a>, but can be used with many other types of element.

From https://angular.io/guide/accessibility#augmenting-native-elements

In Angular, augmenting native elements is creating a component that uses an attribute selector to extend the native <button> element.

That’s how the code with augmenting native elements

Selector: we are not using a custom component tag, instead, we combine button[shared-button] and a[shared-button] because we don’t want to apply this component to a div for example.
Template: using purely content projection means we want anything which is between a button or a
Then we can apply directly the class we want to the native element using HostBinding

@Component({
+	 selector: 'button[shared-button], a[shared-button]',
+	 template: ` <ng-content></ng-content> `,
	 changeDetection: ChangeDetectionStrategy.OnPush,
	 styleUrls: ['./button-v2.component.scss'],
	 encapsulation: ViewEncapsulation.None,
})
export class ButtonV2Component {
+ @HostBinding('class') get rdButtonClass(): string {
   const classes = ['button', `btn-${this.buttonTheme}`];
   return classes.filter(Boolean).join(' ');
 }

 @Input() buttonTheme: ButtonTheme = 'secondary';
}

Re-implement three use cases using augmenting native elements approach

I show the code side by side so we can have a better comparison. The top is the old approach using a custom shared-button, and the bottom uses our new approach of attribute selector.

Custom button #1

Custom button #2

Custom button #3

Noticed that in all three examples

What we render into DOM will be the button and a without a redundant wrapper.
When we are using the selector, we can access to button and a directly thus it eliminates the need to forward additional attributes. The only @Input we accepts so far is buttonTheme

Why does it work?

Angular directive ↗ selector accepts:

element-name: Select by element name.
.class: Select by class name.
[attribute]: Select by attribute name.
[attribute=value]: Select by attribute name and value.
:not(sub_selector): Select only if the element does not match the sub_selector.
selector1, selector2: Select if either selector1 or selector2 matches.

In our code, we use button[shared-button], a[shared-button] which is the combination of element-name and [attribute] selectors.

Benefits

Familiar APIs!
Accessibility win!
Simpler implementation!

Many popular UI libraries use augmenting native elements approach

Angular Material

material/button/button.ts#L40 ↗️

@Component({
 selector: `
   button[mat-button], button[mat-raised-button], button[mat-flat-button],
   button[mat-stroked-button]
 `,
 templateUrl: 'button.html',
 inputs: MAT_BUTTON_INPUTS,
 exportAs: 'matButton',
 encapsulation: ViewEncapsulation.None,
 changeDetection: ChangeDetectionStrategy.OnPush,
})
export class MatButton extends MatButtonBase {

NG-ZORRO

components/button/button.component.ts#L40

Notice here ng-zorro enhance the template to supply a loading icon as well, not just a simple ng-content anymore.

@Component({
 selector: 'button[nz-button], a[nz-button]',
 exportAs: 'nzButton',
 changeDetection: ChangeDetectionStrategy.OnPush,
 encapsulation: ViewEncapsulation.None,
 template: `
+  <i nz-icon nzType="loading" *ngIf="nzLoading"></i>
   <ng-content></ng-content>
 `,
})
export class NzButtonComponent implements OnDestroy, OnChanges,

What else can you do with augmenting native elements?

Angular Material

material/table/table.ts#L41

@Component({
 selector: 'mat-table, table[mat-table]',
 exportAs: 'matTable',
 template: CDK_TABLE_TEMPLATE,
 providers: [
   {provide: CdkTable, useExisting: MatTable},
   {provide: CDK_TABLE, useExisting: MatTable},
 changeDetection: ChangeDetectionStrategy.Default,
})
export class MatTable<T> extends CdkTable<T> implements OnInit {

material/tabs/tab-nav-bar/tab-nav-bar.ts#L307

@Component({
 selector: '[mat-tab-nav-bar]',
 exportAs: 'matTabNavBar, matTabNav',
 templateUrl: 'tab-nav-bar.html',
 encapsulation: ViewEncapsulation.None,
 changeDetection: ChangeDetectionStrategy.Default,
})
export class MatTabNav extends _MatTabNavBase

❓ Should we never replace native components with custom components?

No. We need custom components!

However, when you’re creating a new component, you should ask yourself

Can I augment an existing one instead? ✅

Core Web Vitals

Mon, 01 May 2023 08:30:00 GMT

As I mentioned on the previous two articles, Why Web Performance Matters: An Introduction and Perceived Performance, web performance is crucial for user experience and business success. In this article, we’ll explore how to measure web performance using Core Web Vitals.

Shout-out to Web Performance Fundamentals for providing a comprehensive guide on web performance.

Page Load Time

In the beginning, there was PageLoad. Website performance was measured with a single measurement of the time until the PageLoad event is fired.

But PageLoad doesn’t fully describe performance. Some sites initially load really fast, but dynamic content needs to load. PageLoad doesn’t fully capture whether a website feels fast.

Worse, PageLoad was easy to manipulate. Developers could improve their PageLoad time by deferring work with JavaScript. Lazy-loading, async script loaders, client-side rendering, and dynamic content were all patterns that often improved PageLoad time, but created a slower experience from the end user perspective.

What do we do instead?

There are lots of ways a website can feel slow: slow to start, slow to finish, jumping around, slow to respond, and more. We can’t use one metric to understand performance anymore.

Core Web Vitals

In 2019, Google introduced a set of metrics intent on measuring the actual performance of a website as the users would see it. These metrics are collectively called the Core Web Vitals.

They are measured in all Chrome-based browsers, including the Googlebot spider, which uses these scores to influence page rank.

Note that Chrome-based browsers, Firefox, and Safari support these metrics and compatibility is increasing. You can check the current compatibility of the Core Web Vitals here.

The web-vitals code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).

Browser support for each function is as follows:

onCLS(): Chromium

onFCP(): Chromium, Firefox, Safari

onFID(): Chromium, Firefox (Deprecated)

onINP(): Chromium

onLCP(): Chromium, Firefox

onTTFB(): Chromium, Firefox, Safari

The metrics that make up Core Web Vitals will evolve over time. The current set focuses on three aspects of the user experience—loading, interactivity, and visual stability—and includes the following metrics (and their respective thresholds):

Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.
Interaction to Next Paint (INP): measures interactivity. To provide a good user experience, pages should have a INP of 200 milliseconds or less.
Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, pages should maintain a CLS of 0.1. or less.

You might have heard of First Input Delay (FID), however it is deprecated September 9 2024 in favor of Interaction to Next Paint (INP).

While First Contentful Paint (FCP) is not one of the Core Web Vitals that impact Google rankings, it is still one of Google’s broader set of Web Vitals metrics. The Largest Contentful Paint (LCP) is one of the Core Web Vitals metrics, and it can never be lower than the First Contentful Paint (FCP).

Largest Contentful Paint (LCP)

“Largest Contentful Paint” measures how long it takes until the browser renders the largest amount of content to the screen. At this point, ideally, the user can see the content they are looking for and believes the page is nearly done.

Like the First Paint and First Contentful Paint metrics, LCP is a paint timing metric that marks a rendering milestone in the page load process.

Contentful means that content like text or an image were rendered, rather than just showing empty boxes or background images.

In the website filmstrip above the LCP element is a piece of text, but it’s also common for the LCP to be caused by an image like in the example below.

Another example, navigating to the homepage of NPR News has a few different renders, but this is the largest one by pixel area:

The advertisement is probably not what the user is looking for, but the article images might be.

LCP encourages websites to finish quickly by emphasizing their primary content and making sure it loads fast.

For optimal user experience and search engine performance, websites should aim for an LCP of 2.5 seconds or less. Google considers an LCP of 4 seconds or more to be poor, which can worsen your search rankings and user experience.

Cumulative Layout Shift (CLS)

“Cumulative Layout Shift” is a little harder to understand because it does not measure time. CLS measures how much the content on a page moves around as other content is loaded and rendered. Like this:

Layout Shifts measure how late-rendered content affects the user experience of a page. Layout shifts that push important content around are really frustrating to use.

CLS discourages websites from moving content around once the user sees it and minimizing the amount of late-rendered content.

Layout shift score

To provide a good user experience, sites should strive to have a CLS score of 0.1 or less

layout shift score = impact fraction * distance fraction

impact fraction: the area of the viewport affected by the layout shift (impact size / viewport size)
distance fraction: the distance the unstable element moved in the viewport (distance / viewport size)

See the example below:

Another example is the layout shift score for a mobile view:

Interaction to Next Paint (INP)

Interaction to Next Paint (INP) is a web performance metric that measures user interface responsiveness – how quickly a website responds to user interactions like clicks or key presses.

Specifically, it measures how much time elapses between a user interaction like a click or key press and the next time the user sees a visual update on the page.

How is Interaction to Next Paint measured?

INP measures the responsiveness of your website by tracking the time between user input and UI updates. This metric consists of three key components:

Input Delay: waiting for background tasks on the page that prevent the event handler from running
Processing Time: running event handlers in JavaScript
Presentation Delay: handling other queued up interactions, recalculating the page layout, and painting page content

This diagram shows an example timeline of different CPU tasks, and how they add up to INP activity. Interaction to Next Paint spans the entire time frame from the mouse, touch, or keyboard input up to the point when the next frame is rendered by the browser.

Summary

Metric	Description	Good Score Threshold
Largest Contentful Paint (LCP)	How fast the main content loads.	≤ 2.5 seconds
Cumulative Layout Shift (CLS)	How stable the page layout is.	≤ 0.1
Interaction to Next Paint (INP)	How quickly the page responds to user actions.	≤ 200 milliseconds

These metrics help ensure a good user experience by focusing on loading speed, visual stability, and responsiveness.

References

Upgrading from Angular 12 to 15 in Nx Workspace: A Comprehensive Guide

Sun, 23 Apr 2023 09:32:00 GMT

I am currently preparing for a talk at Web Directions Code 2023 about CSS container queries.

However, I have encountered an issue with CSS containers in Angular 12, and it seems that upgrading to Angular 15 is necessary to resolve the issue.

The problem is related to the @container style not being properly emulated into the component. This issue has been causing some difficulties in my preparation for the talk.

https://github.com/angular/angular/issues/48264

The disaster with `nx migrate latest`

angular-spotify is using nrwl@12.5.2 and the latest version is 15.2.8

I straight away try running nx migrate latest to update to the latest version

> nx migrate latest
> node --version
v12.22.12

> nvm use 16
Now using node v16.15.1 (npm v8.11.0)

> nx migrate latest

> nx migrate --run-migrations

NX   Running 'npm install' to make sure necessary packages are installed

npm WARN old lockfile
npm WARN old lockfile The package-lock.json file was created with an old version of npm,
npm WARN old lockfile so supplemental metadata must be fetched from the registry.
npm WARN old lockfile
npm WARN old lockfile This is a one-time fix-up, please be patient...
npm WARN old lockfile

Despite my initial optimism, I encountered numerous issues when attempting to execute nx migrate --run-migrations. These issues proved to be quite challenging to resolve, and included errors such as:

Failed to parse npm lockfile
Failed to run update-tsconfig-target from @nrwl/angular. This workspace is NOT up to date!
Failed to run update-platform-server-exports from @nrwl/angular. This workspace is NOT up to date!
‘rule’ is not a function

Despite my best efforts, these issues proved to be impossible to fix. This experience highlights the importance of thoroughly testing and preparing for major upgrades, as even seemingly minor issues can quickly snowball into major problems.

To avoid further complications, I decided to break down the upgrade process into multiple steps. This approach not only helps me to avoid errors but also allows me to experiment with the codebase more effectively.

While I had initially planned to take this approach, the issues I encountered reinforced the importance of taking a cautious and methodical approach to upgrading.

Proper migration strategy

Thus I decided to do the migration in multiple steps. How? I refer to this Nx and Angular Version Compatibility Matrix.

Therefore, I’ve made the decision to migrate from Angular 12 to 13 first, then to 14, and finally to 15.

In line with that, I’ll also be upgrading Nx from 12.5.2 to 14.1.9 (which supports Angular 13), and then to 15.2.0, and finally to the latest version.

It’s worth mentioning that I skipped Nx 13 since it doesn’t yet support Angular 13, and everything is still functioning smoothly.

1. nx migrate 14.1.9 (support Angular 13)

See a full log of nx migrate 14.1.9

> nx migrate 14.1.9

Fetching meta data about packages.
It may take a few minutes.
Fetching nx@14.1.9
Fetching @nrwl/workspace@14.1.9
Fetching @nrwl/cypress@14.1.9
Fetching @nrwl/angular@14.1.9
Fetching @nrwl/jest@14.1.9
Fetching @nrwl/linter@14.1.9
Fetching @angular/cli@13.3.11
Fetching @ngrx/store-devtools@13.0.2
Fetching @ngrx/store@13.0.2
Fetching @angular/core@13.3.12
Fetching @angular/cli@~13.3.0
Fetching @ngrx/component-store@13.0.2
Fetching @ngrx/effects@13.0.2
Fetching @ngrx/component@13.0.2

>  NX   The migrate command has run successfully.

- package.json has been updated.
- migrations.json has been generated.

>  NX   Next steps:

- Make sure package.json changes make sense and then run 'yarn',
- Run 'yarn nx migrate --run-migrations'
- To learn more go to https://nx.dev/core-features/automate-updating-dependencies

> yarn nx migrate --run-migrations --create-commits

>  NX  Running migrations from 'migrations.json', with each applied in a dedicated commit

Running migration 14-0-6-remove-root
Successfully finished 14-0-6-remove-root
- Commit created for changes: fdbbae302748b868e78e81f04c973fd8c8317867
---------------------------------------------------------
Running migration update-invalid-import-paths
Successfully finished update-invalid-import-paths
- Commit created for changes: 972b8d10118b898753592ffe3fc2c98b023ff56d
---------------------------------------------------------
Running migration add-postcss-packages
Successfully finished add-postcss-packages
- There were no changes to commit
---------------------------------------------------------
Running migration update-angular-config
Successfully finished update-angular-config
- There were no changes to commit
---------------------------------------------------------
Running migration update-libraries
Successfully finished update-libraries
- There were no changes to commit
---------------------------------------------------------
Running migration update-angular-jest-config
Successfully finished update-angular-jest-config
- Commit created for changes: 325354d83ff4260a87b28e2175558d8706bf1eac
---------------------------------------------------------
Running migration update-testing-imports
Successfully finished update-testing-imports
- There were no changes to commit
---------------------------------------------------------
Running migration opt-out-testbed-teardown
Successfully finished opt-out-testbed-teardown
- Commit created for changes: 29ae169b5246d60fc6446e511d79b23741f750bd
---------------------------------------------------------
Running migration update-mfe-config-to-module-syntax
Successfully finished update-mfe-config-to-module-syntax
- There were no changes to commit
---------------------------------------------------------
Running migration remove-library-generator-style-default
Successfully finished remove-library-generator-style-default
- Commit created for changes: 25c8f450bfd6e0ddc9e6199feef4bf0a04c00d52
---------------------------------------------------------
Running migration fix-incorrect-mfe-setups
Successfully finished fix-incorrect-mfe-setups
- There were no changes to commit
---------------------------------------------------------
Running migration add-cypress-mfe-workaround
Successfully finished add-cypress-mfe-workaround
- There were no changes to commit
---------------------------------------------------------
Running migration migrate-karma-config
Successfully finished migrate-karma-config
- There were no changes to commit
---------------------------------------------------------
Running migration set-build-libs-from-source
Successfully finished set-build-libs-from-source
- There were no changes to commit
---------------------------------------------------------
Running migration rename-module-federation-config
Successfully finished rename-module-federation-config
- There were no changes to commit
---------------------------------------------------------
Running migration set-default-base-if-not-set
Successfully finished set-default-base-if-not-set
- There were no changes to commit
---------------------------------------------------------
Running migration 13-0-0-config-locations
Successfully finished 13-0-0-config-locations
- Commit created for changes: 066d71ef0bb40fe809b202e9c29ba39344e8ae6e
---------------------------------------------------------
Running migration set-parallel-default
Successfully finished set-parallel-default
- Commit created for changes: f897090e59eee9c4ec5770b8fc26ac354a5c52ff
---------------------------------------------------------
Running migration 13-3-0-tsc-location
Successfully finished 13-3-0-tsc-location
- There were no changes to commit
---------------------------------------------------------
Running migration 13-6-0-remove-old-task-runner-options
Successfully finished 13-6-0-remove-old-task-runner-options
- Commit created for changes: c5826fc8c18e1589427a51995a19a629da87989e
---------------------------------------------------------
Running migration 13-9-0-replace-tao-with-nx
Please run yarn to ensure the correct version of Nx is installed.
Successfully finished 13-9-0-replace-tao-with-nx
- Commit created for changes: 4a240af6dbdd5aba2bb1c8048c2f6b01614ac496
---------------------------------------------------------
Running migration 13-10-0-update-decorate-cli
Successfully finished 13-10-0-update-decorate-cli
- There were no changes to commit
---------------------------------------------------------
Running migration 13-10-0-update-tasks-runner
Successfully finished 13-10-0-update-tasks-runner
- There were no changes to commit
---------------------------------------------------------
Running migration 14-0-0-change-nx-json-presets
Successfully finished 14-0-0-change-nx-json-presets
- There were no changes to commit
---------------------------------------------------------
Running migration 14-0-0-change-npm-script-executor
Successfully finished 14-0-0-change-npm-script-executor
- There were no changes to commit
---------------------------------------------------------
Running migration remove-typescript-plugin
Successfully finished remove-typescript-plugin
- There were no changes to commit
---------------------------------------------------------
Running migration add-outputs
Successfully finished add-outputs
- Commit created for changes: 2686c67a14f1440aa37a0f43f76d2ed790d1fbf0
---------------------------------------------------------
Running migration remove-eslint-project-config-if-no-type-checking-rules-again
Successfully finished remove-eslint-project-config-if-no-type-checking-rules-again
- There were no changes to commit
---------------------------------------------------------
Running migration eslint-8-updates
Successfully finished eslint-8-updates
- There were no changes to commit
---------------------------------------------------------
Running migration update-jest-config-to-use-util
Successfully finished update-jest-config-to-use-util
- Commit created for changes: 3de59c7be81310dba231ac74023fb9e5b934d03e
---------------------------------------------------------
Running migration update-ts-config-for-test-filenames
Unable to update libs/web/shared/data-access/spotify-api/tsconfig.lib.json.
Successfully finished update-ts-config-for-test-filenames
- Commit created for changes: 432f9e8d855c3e5779e6aa5956e70beabe9a6f49
---------------------------------------------------------
Running migration add-missing-root-babel-config
Successfully finished add-missing-root-babel-config
- There were no changes to commit
---------------------------------------------------------
Running migration update-jest-config-extensions
Nx Unable to update libs/web/shared/data-access/spotify-api/tsconfig.lib.json. Please manually ignore the jest.config.ts file.
Successfully finished update-jest-config-extensions
- Commit created for changes: 9db789c3a98a5e48479800bc39c7b755e2f507f9
---------------------------------------------------------
Running migration update-to-export-default
Successfully finished update-to-export-default
- Commit created for changes: 601886d11498f56daa90dbc56f0d3e4eed604e00
---------------------------------------------------------
Running migration ngrx-store-migration-13-beta
Successfully finished ngrx-store-migration-13-beta
- There were no changes to commit
---------------------------------------------------------
Running migration ngrx-store-migration-13-rc
Successfully finished ngrx-store-migration-13-rc
- There were no changes to commit
---------------------------------------------------------
Running migration migration-v13-router-link-empty-expression
Successfully finished migration-v13-router-link-empty-expression
- There were no changes to commit
---------------------------------------------------------
Running migration migration-v13-testbed-teardown
Successfully finished migration-v13-testbed-teardown
- There were no changes to commit
---------------------------------------------------------
Running migration migration-v13.1-entry-components
Successfully finished migration-v13.1-entry-components
- There were no changes to commit
---------------------------------------------------------
Running migration ngrx-effects-migration-03
Successfully finished ngrx-effects-migration-03
- There were no changes to commit
---------------------------------------------------------
Running migration schematic-options-13
Successfully finished schematic-options-13
- There were no changes to commit
---------------------------------------------------------
Running migration update-angular-config-v13
Successfully finished update-angular-config-v13
- There were no changes to commit
---------------------------------------------------------
Running migration update-libraries-v13
Successfully finished update-libraries-v13
- There were no changes to commit
---------------------------------------------------------
Running migration drop-ie-polyfills
Successfully finished drop-ie-polyfills
- Commit created for changes: fd4ec7906196569dc3bcbfa1fb8f94ff80ec6d2b
---------------------------------------------------------
Running migration update-gitignore
Successfully finished update-gitignore
- Commit created for changes: 221fa6348b88cb29ee4bf793cfb7e1b1bffeb795
---------------------------------------------------------

>  NX  Successfully finished running migrations from 'migrations.json'

2. nx migrate 15.2.0 (support Angular 14 and above)

See a full log of nx migrate 15.2.0

> nx migrate 15.2.0

> NX ✅ This workspace is already connected to Nx Cloud.

This means your workspace can use computation caching, distributed task execution, and show you run analytics.
Go to https://nx.app to learn more.
trung.vo@trung  ~/Source/angular-spotify   trung/angular-15 ±  yarn nx migrate --run-migrations --create-commits
yarn run v1.22.19
$ nx migrate --run-migrations --create-commits

> NX Running 'yarn' to make sure necessary packages are installed

[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
[3/4] 🔗 Linking dependencies...
warning " > @ngrx/component@14.0.2" has incorrect peer dependency "@angular/common@^14.0.0".
warning " > @ngrx/component@14.0.2" has incorrect peer dependency "@angular/core@^14.0.0".
warning " > @ngrx/component-store@14.0.2" has incorrect peer dependency "@angular/core@^14.0.0".
warning " > @ngrx/effects@14.0.2" has incorrect peer dependency "@angular/core@^14.0.0".
warning " > @ngrx/store@14.0.2" has incorrect peer dependency "@angular/core@^14.0.0".
warning "@nrwl/angular > @nrwl/webpack > babel-loader@8.3.0" has unmet peer dependency "@babel/core@^7.0.0".
warning " > @sentry/angular@6.8.0" has incorrect peer dependency "@angular/common@10.x || 11.x || 12.x".
warning " > @sentry/angular@6.8.0" has incorrect peer dependency "@angular/core@10.x || 11.x || 12.x".
warning " > @sentry/angular@6.8.0" has incorrect peer dependency "@angular/router@10.x || 11.x || 12.x".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/animations@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/common@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/forms@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/core@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/platform-browser@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/router@^11.0.4".
warning "ng-zorro-antd > @angular/cdk@11.2.13" has incorrect peer dependency "@angular/core@^11.0.0 || ^12.0.0-0".
warning "ng-zorro-antd > @angular/cdk@11.2.13" has incorrect peer dependency "@angular/common@^11.0.0 || ^12.0.0-0".
warning "ng-zorro-antd > @ant-design/icons-angular@11.0.1" has incorrect peer dependency "@angular/common@^11.0.5".
warning "ng-zorro-antd > @ant-design/icons-angular@11.0.1" has incorrect peer dependency "@angular/core@^11.0.5".
warning "ng-zorro-antd > @ant-design/icons-angular@11.0.1" has incorrect peer dependency "@angular/platform-browser@^11.0.0".
[4/4] 🔨 Building fresh packages...
success Saved lockfile.
$ node ./decorate-angular-cli.js && ngcc --properties es2015 browser module main && husky install

> NX Angular CLI has been decorated to enable computation caching.
> husky - Git hooks installed

> nx migrate --run-migrations --create-commits

> NX Running migrations from 'migrations.json', with each applied in a dedicated commit

Ran 14-2-0-add-json-schema from nx
Add JSON Schema to Nx configuration files

UPDATE nx.json
UPDATE angular.json

- Commit created for changes: 8eda85987526ebbb0253a9021f51015fd00fd36a

---

Ran 14-2-0-remove-default-collection from nx
Remove default collection from configuration to switch to prompts for collection

UPDATE nx.json

- Commit created for changes: 8a5d68b4b19bf1a0f4a3856194bec6c491d13058

---

Ran 14.3.4-create-target-defaults from nx
Replace targetDependencies with targetDefaults

UPDATE nx.json

- Commit created for changes: 348d85e4845308d3bc5539532c7d7ce4711a71bc

---

Ran 15.0.0-migrate-to-inputs from nx
Replace implicitDependencies with namedInputs + target inputs

UPDATE nx.json

- Commit created for changes: 026753402d445ba9f45bd6e3b6dee6afdc72b368

---

Ran 15.0.0-prefix-outputs from nx
Prefix outputs with {workspaceRoot}/{projectRoot} if needed

UPDATE angular.json

- Commit created for changes: 5914df2633fb6194c7014030162f61974cca0361

---

Ran 15.1.0-set-project-names from nx
Set project names in project.json files

UPDATE apps/angular-spotify/project.json
UPDATE libs/web/album/data-access/project.json
UPDATE libs/web/artist/data-access/project.json
UPDATE libs/web/artist/feature/project.json
UPDATE libs/web/auth/data-access/project.json
UPDATE libs/web/auth/util/project.json
UPDATE libs/web/browse/data-access/project.json
UPDATE libs/web/home/data-access/project.json
UPDATE libs/web/home/feature/project.json
UPDATE libs/web/playlist/data-access/project.json
UPDATE libs/web/search/data-access/project.json
UPDATE libs/web/search/feature/project.json
UPDATE libs/web/settings/data-access/project.json
UPDATE libs/web/settings/feature/project.json
UPDATE libs/web/shared/app-config/project.json
UPDATE libs/web/shared/assets/project.json
UPDATE libs/web/shared/utils/project.json
UPDATE libs/web/shell/feature/project.json
UPDATE libs/web/tracks/data-access/project.json
UPDATE libs/web/tracks/feature/project.json
UPDATE libs/web/visualizer/data-access/project.json
UPDATE libs/web/visualizer/feature/project.json
UPDATE libs/web/visualizer/ui/project.json
UPDATE libs/web/album/feature/detail/project.json
UPDATE libs/web/album/feature/list/project.json
UPDATE libs/web/album/feature/shell/project.json
UPDATE libs/web/album/ui/album-track/project.json
UPDATE libs/web/artist/ui/artist-top-track/project.json
UPDATE libs/web/artist/ui/artist-top-tracks/project.json
UPDATE libs/web/auth/ui/unauthorized-modal/project.json
UPDATE libs/web/browse/feature/categories/project.json
UPDATE libs/web/browse/feature/category/project.json
UPDATE libs/web/browse/feature/shell/project.json
UPDATE libs/web/browse/ui/category-cover/project.json
UPDATE libs/web/home/ui/featured-playlists/project.json
UPDATE libs/web/home/ui/greeting/project.json
UPDATE libs/web/home/ui/recent-played/project.json
UPDATE libs/web/playlist/feature/detail/project.json
UPDATE libs/web/playlist/feature/list/project.json
UPDATE libs/web/playlist/ui/playlist-track/project.json
UPDATE libs/web/shared/data-access/models/project.json
UPDATE libs/web/shared/data-access/spotify-api/project.json
UPDATE libs/web/shared/data-access/store/project.json
UPDATE libs/web/shared/directives/click-stop-propagation/project.json
UPDATE libs/web/shared/pipes/duration-pipe/project.json
UPDATE libs/web/shared/ui/icon/project.json
UPDATE libs/web/shared/ui/input/project.json
UPDATE libs/web/shared/ui/media/project.json
UPDATE libs/web/shared/ui/media-cover/project.json
UPDATE libs/web/shared/ui/media-order/project.json
UPDATE libs/web/shared/ui/media-summary/project.json
UPDATE libs/web/shared/ui/media-table/project.json
UPDATE libs/web/shared/ui/play-button/project.json
UPDATE libs/web/shared/ui/playlist-list/project.json
UPDATE libs/web/shared/ui/spinner/project.json
UPDATE libs/web/shared/ui/track-current-info/project.json
UPDATE libs/web/shared/ui/track-main-info/project.json
UPDATE libs/web/shared/ui/tracks-loading/project.json
UPDATE libs/web/shared/ui/work-in-progress/project.json
UPDATE libs/web/shell/ui/album-art-overlay/project.json
UPDATE libs/web/shell/ui/layout/project.json
UPDATE libs/web/shell/ui/main-view/project.json
UPDATE libs/web/shell/ui/nav-bar/project.json
UPDATE libs/web/shell/ui/nav-bar-playlist/project.json
UPDATE libs/web/shell/ui/now-playing-bar/project.json
UPDATE libs/web/shell/ui/player-controls/project.json
UPDATE libs/web/shell/ui/player-playback/project.json
UPDATE libs/web/shell/ui/player-volume/project.json
UPDATE libs/web/shell/ui/social-share/project.json
UPDATE libs/web/shell/ui/top-bar/project.json
UPDATE libs/web/shell/ui/user-dropdown/project.json
UPDATE libs/web/shell/ui/visualization-toggle/project.json

- Commit created for changes: 4d4c04edcbe6da9a56b35df97df53e2fc313bbe9

---

Ran exclude-jest-config-from-ts-config from @nrwl/jest
Exclude jest.config.ts from tsconfig where missing.

UPDATE libs/web/shared/data-access/spotify-api/tsconfig.lib.json

- Commit created for changes: 504ac808bbcd7a447a5b24481ee91f1dfe61b299

---

Ran update-configs-jest-28 from @nrwl/jest
Update jest configs to support jest 28 changes (https://jestjs.io/docs/upgrading-to-jest28#configuration-options)

UPDATE package.json

- Commit created for changes: b5de988aaad4016d7aa72e8f3d58643869868df6

---

Ran add-jest-inputs from @nrwl/jest
Stop hashing jest spec files and config files for build targets and dependent tasks

UPDATE nx.json

- Commit created for changes: 78aa51c9e9728697ac1e797d4351632efa1a7748

---

Ran update-angular-cli-version from @nrwl/angular
Update the @angular/cli package version.

UPDATE package.json

- Commit created for changes: f5fc0ec57aec1dde36398cbcf7515ae958602fe6

---

Ran update-postinstall-script-ngcc-target from @nrwl/angular
Update postinstall script running ngcc to use ES2020 target.

UPDATE package.json

- Commit created for changes: 8af412b8dd9e3c9c82baaa23560b748ee11b22c3

---

Ran update-tsconfig-target from @nrwl/angular
Update TypeScript compilation target to 'ES2020'.

UPDATE libs/web/shared/directives/click-stop-propagation/tsconfig.json
UPDATE libs/web/shared/data-access/spotify-api/tsconfig.json
UPDATE libs/web/shell/ui/visualization-toggle/tsconfig.json
UPDATE libs/web/shared/ui/track-current-info/tsconfig.json
UPDATE libs/web/artist/ui/artist-top-tracks/tsconfig.json
UPDATE libs/web/artist/ui/artist-top-track/tsconfig.json
UPDATE libs/web/auth/ui/unauthorized-modal/tsconfig.json
UPDATE libs/web/home/ui/featured-playlists/tsconfig.json
UPDATE libs/web/playlist/ui/playlist-track/tsconfig.json
UPDATE libs/web/shared/pipes/duration-pipe/tsconfig.json
UPDATE libs/web/shared/ui/work-in-progress/tsconfig.json
UPDATE libs/web/shell/ui/album-art-overlay/tsconfig.json
UPDATE libs/web/browse/feature/categories/tsconfig.json
UPDATE libs/web/shared/ui/track-main-info/tsconfig.json
UPDATE libs/web/shell/ui/nav-bar-playlist/tsconfig.json
UPDATE libs/web/browse/ui/category-cover/tsconfig.json
UPDATE libs/web/shared/data-access/store/tsconfig.json
UPDATE libs/web/shared/ui/tracks-loading/tsconfig.json
UPDATE libs/web/shell/ui/now-playing-bar/tsconfig.json
UPDATE libs/web/shell/ui/player-controls/tsconfig.json
UPDATE libs/web/shell/ui/player-playback/tsconfig.json
UPDATE libs/web/browse/feature/category/tsconfig.json
UPDATE libs/web/playlist/feature/detail/tsconfig.json
UPDATE libs/web/shared/ui/media-summary/tsconfig.json
UPDATE libs/web/shared/ui/playlist-list/tsconfig.json
UPDATE libs/web/shell/ui/player-volume/tsconfig.json
UPDATE libs/web/shell/ui/user-dropdown/tsconfig.json
UPDATE libs/web/visualizer/data-access/tsconfig.json
UPDATE libs/web/home/ui/recent-played/tsconfig.json
UPDATE libs/web/playlist/feature/list/tsconfig.json
UPDATE libs/web/shared/ui/media-cover/tsconfig.json
UPDATE libs/web/shared/ui/media-order/tsconfig.json
UPDATE libs/web/shared/ui/media-table/tsconfig.json
UPDATE libs/web/shared/ui/play-button/tsconfig.json
UPDATE libs/web/shell/ui/social-share/tsconfig.json
UPDATE libs/web/album/feature/detail/tsconfig.json
UPDATE libs/web/album/ui/album-track/tsconfig.json
UPDATE libs/web/browse/feature/shell/tsconfig.json
UPDATE libs/web/playlist/data-access/tsconfig.json
UPDATE libs/web/settings/data-access/tsconfig.json
UPDATE libs/web/album/feature/shell/tsconfig.json
UPDATE libs/web/album/feature/list/tsconfig.json
UPDATE libs/web/artist/data-access/tsconfig.json
UPDATE libs/web/browse/data-access/tsconfig.json
UPDATE libs/web/search/data-access/tsconfig.json
UPDATE libs/web/shell/ui/main-view/tsconfig.json
UPDATE libs/web/tracks/data-access/tsconfig.json
UPDATE libs/web/visualizer/feature/tsconfig.json
UPDATE libs/web/album/data-access/tsconfig.json
UPDATE libs/web/shared/app-config/tsconfig.json
UPDATE libs/web/shared/ui/spinner/tsconfig.json
UPDATE libs/web/auth/data-access/tsconfig.json
UPDATE libs/web/home/data-access/tsconfig.json
UPDATE libs/web/home/ui/greeting/tsconfig.json
UPDATE libs/web/settings/feature/tsconfig.json
UPDATE libs/web/shell/ui/nav-bar/tsconfig.json
UPDATE libs/web/shell/ui/top-bar/tsconfig.json
UPDATE libs/web/shared/app-init/tsconfig.json
UPDATE libs/web/shared/ui/input/tsconfig.json
UPDATE libs/web/shared/ui/media/tsconfig.json
UPDATE libs/web/shell/ui/layout/tsconfig.json
UPDATE libs/web/artist/feature/tsconfig.json
UPDATE libs/web/search/feature/tsconfig.json
UPDATE libs/web/shared/ui/icon/tsconfig.json
UPDATE libs/web/tracks/feature/tsconfig.json
UPDATE libs/web/shell/feature/tsconfig.json
UPDATE libs/web/visualizer/ui/tsconfig.json
UPDATE libs/web/home/feature/tsconfig.json
UPDATE apps/angular-spotify/tsconfig.json
UPDATE libs/web/auth/util/tsconfig.json

- Commit created for changes: 81f0a5670a0fdd9f7131e5dbca1830154e54b64a

---

Ran update-angular-cli-version-14-1-0 from @nrwl/angular
Update the @angular/cli package version to ~14.1.0.

UPDATE package.json

- Commit created for changes: 9d39a2e9eb26fae063e8e34bba4ecbc4ff49904c

---

Ran update-angular-cli-version-14-2-0 from @nrwl/angular
Update the @angular/cli package version to ~14.2.0.

UPDATE package.json

- Commit created for changes: 345ec3a60645f7837c0d1c215f02335a1a064804

---

Ran update-angular-cli-version-15-0-0 from @nrwl/angular
Update the @angular/cli package version to ~15.0.0.

UPDATE package.json

- Commit created for changes: 2ae14b1641e043c0d0540a1262bc79a3dd500880

---

Ran remove-browserlist-config from @nrwl/angular
Remove browserlist config as it's handled by build-angular

DELETE apps/angular-spotify/.browserslistrc

- Commit created for changes: 6e48af0215db5859886e48c2d2a7fa7a76fc4a1c

---

Ran update-typescript-target from @nrwl/angular
Update typescript target to ES2022

UPDATE apps/angular-spotify/tsconfig.app.json

- Commit created for changes: 2091c12a721c9e5c1a46fb5c67153e62a222d5e3

---

[NX] Angular devkit readJsonWorkspace fell back to Nx workspaces logic
Project 'web-shared-directives-click-stop-propagation' contains extension with invalid name (files).
Project 'web-shared-data-access-spotify-api' contains extension with invalid name (files).
Project 'web-shell-ui-visualization-toggle' contains extension with invalid name (files).
Project 'web-shared-ui-track-current-info' contains extension with invalid name (files).
Project 'web-artist-ui-artist-top-tracks' contains extension with invalid name (files).
Project 'web-artist-ui-artist-top-track' contains extension with invalid name (files).
Project 'web-auth-ui-unauthorized-modal' contains extension with invalid name (files).
Project 'web-home-ui-featured-playlists' contains extension with invalid name (files).
Project 'web-playlist-ui-playlist-track' contains extension with invalid name (files).
Project 'web-shared-pipes-duration-pipe' contains extension with invalid name (files).
Project 'web-shared-ui-work-in-progress' contains extension with invalid name (files).
Project 'web-shell-ui-album-art-overlay' contains extension with invalid name (files).
Project 'web-browse-feature-categories' contains extension with invalid name (files).
Project 'web-shared-data-access-models' contains extension with invalid name (files).
Project 'web-shared-ui-track-main-info' contains extension with invalid name (files).
Project 'web-shell-ui-nav-bar-playlist' contains extension with invalid name (files).
Project 'web-browse-ui-category-cover' contains extension with invalid name (files).
Project 'web-shared-data-access-store' contains extension with invalid name (files).
Project 'web-shared-ui-tracks-loading' contains extension with invalid name (files).
Project 'web-shell-ui-now-playing-bar' contains extension with invalid name (files).
Project 'web-shell-ui-player-controls' contains extension with invalid name (files).
Project 'web-shell-ui-player-playback' contains extension with invalid name (files).
Project 'web-browse-feature-category' contains extension with invalid name (files).
Project 'web-playlist-feature-detail' contains extension with invalid name (files).
Project 'web-shared-ui-media-summary' contains extension with invalid name (files).
Project 'web-shared-ui-playlist-list' contains extension with invalid name (files).
Project 'web-shell-ui-player-volume' contains extension with invalid name (files).
Project 'web-shell-ui-user-dropdown' contains extension with invalid name (files).
Project 'web-visualizer-data-access' contains extension with invalid name (files).
Project 'web-home-ui-recent-played' contains extension with invalid name (files).
Project 'web-playlist-feature-list' contains extension with invalid name (files).
Project 'web-shared-ui-media-cover' contains extension with invalid name (files).
Project 'web-shared-ui-media-order' contains extension with invalid name (files).
Project 'web-shared-ui-media-table' contains extension with invalid name (files).
Project 'web-shared-ui-play-button' contains extension with invalid name (files).
Project 'web-shell-ui-social-share' contains extension with invalid name (files).
Project 'web-album-feature-detail' contains extension with invalid name (files).
Project 'web-album-ui-album-track' contains extension with invalid name (files).
Project 'web-browse-feature-shell' contains extension with invalid name (files).
Project 'web-playlist-data-access' contains extension with invalid name (files).
Project 'web-settings-data-access' contains extension with invalid name (files).
Project 'web-album-feature-shell' contains extension with invalid name (files).
Project 'web-album-feature-list' contains extension with invalid name (files).
Project 'web-artist-data-access' contains extension with invalid name (files).
Project 'web-browse-data-access' contains extension with invalid name (files).
Project 'web-search-data-access' contains extension with invalid name (files).
Project 'web-shell-ui-main-view' contains extension with invalid name (files).
Project 'web-tracks-data-access' contains extension with invalid name (files).
Project 'web-visualizer-feature' contains extension with invalid name (files).
Project 'web-album-data-access' contains extension with invalid name (files).
Project 'web-shared-app-config' contains extension with invalid name (files).
Project 'web-shared-ui-spinner' contains extension with invalid name (files).
Project 'web-auth-data-access' contains extension with invalid name (files).
Project 'web-home-data-access' contains extension with invalid name (files).
Project 'web-home-ui-greeting' contains extension with invalid name (files).
Project 'web-settings-feature' contains extension with invalid name (files).
Project 'web-shell-ui-nav-bar' contains extension with invalid name (files).
Project 'web-shell-ui-top-bar' contains extension with invalid name (files).
Project 'web-shared-app-init' contains extension with invalid name (files).
Project 'web-shared-ui-input' contains extension with invalid name (files).
Project 'web-shared-ui-media' contains extension with invalid name (files).
Project 'web-shell-ui-layout' contains extension with invalid name (files).
Project 'web-artist-feature' contains extension with invalid name (files).
Project 'web-search-feature' contains extension with invalid name (files).
Project 'web-shared-ui-icon' contains extension with invalid name (files).
Project 'web-tracks-feature' contains extension with invalid name (files).
Project 'web-shared-assets' contains extension with invalid name (files).
Project 'web-shell-feature' contains extension with invalid name (files).
Project 'web-visualizer-ui' contains extension with invalid name (files).
Project 'web-home-feature' contains extension with invalid name (files).
Project 'web-shared-utils' contains extension with invalid name (files).
Project 'angular-spotify' contains extension with invalid name (files).
Project 'web-auth-util' contains extension with invalid name (files).
Ran add-eslint-inputs from @nrwl/linter
Stop hashing eslint config files for build targets and dependent tasks

UPDATE nx.json

- Commit created for changes: 6852947b4baea8065775fa34a8976d11ce615bc8

---

> NX Running 'yarn' to make sure necessary packages are installed

[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
[3/4] 🔗 Linking dependencies...
warning " > @ngrx/component@14.0.2" has incorrect peer dependency "@angular/common@^14.0.0".
warning " > @ngrx/component@14.0.2" has incorrect peer dependency "@angular/core@^14.0.0".
warning " > @ngrx/component-store@14.0.2" has incorrect peer dependency "@angular/core@^14.0.0".
warning " > @ngrx/effects@14.0.2" has incorrect peer dependency "@angular/core@^14.0.0".
warning " > @ngrx/store@14.0.2" has incorrect peer dependency "@angular/core@^14.0.0".
warning " > @sentry/angular@6.8.0" has incorrect peer dependency "@angular/common@10.x || 11.x || 12.x".
warning " > @sentry/angular@6.8.0" has incorrect peer dependency "@angular/core@10.x || 11.x || 12.x".
warning " > @sentry/angular@6.8.0" has incorrect peer dependency "@angular/router@10.x || 11.x || 12.x".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/animations@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/common@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/forms@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/core@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/platform-browser@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/router@^11.0.4".
warning "ng-zorro-antd > @angular/cdk@11.2.13" has incorrect peer dependency "@angular/core@^11.0.0 || ^12.0.0-0".
warning "ng-zorro-antd > @angular/cdk@11.2.13" has incorrect peer dependency "@angular/common@^11.0.0 || ^12.0.0-0".
warning "ng-zorro-antd > @ant-design/icons-angular@11.0.1" has incorrect peer dependency "@angular/common@^11.0.5".
warning "ng-zorro-antd > @ant-design/icons-angular@11.0.1" has incorrect peer dependency "@angular/core@^11.0.5".
warning "ng-zorro-antd > @ant-design/icons-angular@11.0.1" has incorrect peer dependency "@angular/platform-browser@^11.0.0".
[4/4] 🔨 Building fresh packages...
success Saved lockfile.
$ node ./decorate-angular-cli.js && ngcc --properties es2020 browser module main && husky install

> NX Angular CLI has been decorated to enable computation caching.
  husky - Git hooks installed

> NX Successfully finished running migrations from 'migrations.json'. This workspace is up to date!

✨ Done in 174.19s.

3. nx migrate latest

See the full log of nx migrate latest

nx migrate latest
Fetching meta data about packages.
It may take a few minutes.
Fetching nx@15.9.2
Fetching @nrwl/jest@15.9.2
Fetching @nrwl/angular@15.9.2
Fetching @nrwl/cypress@15.9.2
Fetching @nrwl/workspace@15.9.2
Fetching @nrwl/linter@15.9.2
Fetching @angular/core@15.2.8
Fetching @ngrx/effects@15.3.0
Fetching @ngrx/store@15.3.0
Fetching @ngrx/component-store@15.3.0
Fetching @ngrx/store-devtools@15.3.0
Fetching @ngrx/component@15.3.0

> NX The migrate command has run successfully.

- package.json has been updated.
- migrations.json has been generated.

> NX Next steps:

- Make sure package.json changes make sense and then run 'yarn',
- Run 'yarn nx migrate --run-migrations'
- To learn more go to https://nx.dev/core-features/automate-updating-dependencies


yarn nx migrate --run-migrations --create-commits
yarn run v1.22.19
\$ nx migrate --run-migrations --create-commits

> NX Running 'yarn' to make sure necessary packages are installed

[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
[3/4] 🔗 Linking dependencies...
warning " > @nrwl/angular@15.9.2" has unmet peer dependency "@angular-devkit/core@>= 14.0.0 < 16.0.0".
warning " > @nrwl/angular@15.9.2" has unmet peer dependency "@angular-devkit/schematics@>= 14.0.0 < 16.0.0".
warning " > @nrwl/angular@15.9.2" has unmet peer dependency "@schematics/angular@>= 14.0.0 < 16.0.0".
warning " > @sentry/angular@6.8.0" has incorrect peer dependency "@angular/common@10.x || 11.x || 12.x".
warning " > @sentry/angular@6.8.0" has incorrect peer dependency "@angular/core@10.x || 11.x || 12.x".
warning " > @sentry/angular@6.8.0" has incorrect peer dependency "@angular/router@10.x || 11.x || 12.x".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/animations@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/common@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/forms@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/core@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/platform-browser@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/router@^11.0.4".
warning "ng-zorro-antd > @angular/cdk@11.2.13" has incorrect peer dependency "@angular/core@^11.0.0 || ^12.0.0-0".
warning "ng-zorro-antd > @angular/cdk@11.2.13" has incorrect peer dependency "@angular/common@^11.0.0 || ^12.0.0-0".
warning "ng-zorro-antd > @ant-design/icons-angular@11.0.1" has incorrect peer dependency "@angular/common@^11.0.5".
warning "ng-zorro-antd > @ant-design/icons-angular@11.0.1" has incorrect peer dependency "@angular/core@^11.0.5".
warning "ng-zorro-antd > @ant-design/icons-angular@11.0.1" has incorrect peer dependency "@angular/platform-browser@^11.0.0".
[4/4] 🔨 Building fresh packages...
success Saved lockfile.
\$ node ./decorate-angular-cli.js && ngcc --properties es2020 browser module main && husky install

> NX Decoration of the Angular CLI is deprecated and will be removed in a future version

Please replace usage of "ng <command>" in any scripts, particularly for CI, with "nx <command>"

> NX Angular CLI has been decorated to enable computation caching.
> husky - Git hooks installed
> Ran install-required-packages from @nrwl/angular
> Install the required angular-devkit packages as we do not directly depend on them anymore

UPDATE package.json

- Commit created for changes: 3c7ac4fed751545f2e56e2c4fee491e1864a4574

---

Ran update-angular-cli-version-15-1-0 from @nrwl/angular
Update the @angular/cli package version to ~15.1.0.

UPDATE package.json

- Commit created for changes: fe732dd4503ecf6f207fbb0f58dd304cd115d79e

---

Ran update-angular-cli-version-15-2-0 from @nrwl/angular
Update the @angular/cli package version to ~15.2.0.

UPDATE package.json

- Commit created for changes: b63ce242f43a39dbd5961495ff5f5d57a824a89c

---

Ran update-tsconfig-spec-jest from @nrwl/angular
Update the tsconfig.spec.json to use target es2016 for jest-preset-angular v13

UPDATE libs/web/shared/app-init/tsconfig.spec.json

- Commit created for changes: 6fe21b49efed5169578dc8494fc840a78d04d7f6

---

Ran add-eslint-ignore from @nrwl/linter
Add node_modules to root eslint ignore

CREATE .eslintignore

- Commit created for changes: a83d02d70a963e60aeed5de895c24cd1507b6d14

---

Ran ngrx-component-migration-15-beta from @ngrx/component
As of NgRx v14, `ReactiveComponentModule` is deprecated. It is replaced by `LetModule` and `PushModule`.

UPDATE libs/web/album/ui/album-track/src/lib/album-track.module.ts
UPDATE libs/web/artist/ui/artist-top-track/src/lib/artist-top-track.module.ts
UPDATE libs/web/browse/feature/category/src/lib/category.module.ts
UPDATE libs/web/playlist/feature/detail/src/lib/playlist.module.ts
UPDATE libs/web/playlist/ui/playlist-track/src/lib/playlist-track.module.ts
UPDATE libs/web/shared/ui/media/src/lib/media.module.ts
UPDATE libs/web/shared/ui/media-order/src/lib/media-order.module.ts
UPDATE libs/web/shared/ui/play-button/src/lib/play-button.module.ts
UPDATE libs/web/shell/ui/nav-bar-playlist/src/lib/nav-bar-playlist.module.ts
UPDATE libs/web/shell/ui/visualization-toggle/src/lib/visualization-toggle.module.ts
UPDATE libs/web/visualizer/ui/src/lib/web-visualizer-ui.module.ts

- Commit created for changes: dad2a2353699b1c76578cf9b220379b1df569b40

---

> NX Running 'yarn' to make sure necessary packages are installed

[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
[3/4] 🔗 Linking dependencies...
warning " > @sentry/angular@6.8.0" has incorrect peer dependency "@angular/common@10.x || 11.x || 12.x".
warning " > @sentry/angular@6.8.0" has incorrect peer dependency "@angular/core@10.x || 11.x || 12.x".
warning " > @sentry/angular@6.8.0" has incorrect peer dependency "@angular/router@10.x || 11.x || 12.x".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/animations@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/common@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/forms@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/core@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/platform-browser@^11.0.4".
warning " > ng-zorro-antd@11.4.2" has incorrect peer dependency "@angular/router@^11.0.4".
warning "ng-zorro-antd > @angular/cdk@11.2.13" has incorrect peer dependency "@angular/core@^11.0.0 || ^12.0.0-0".
warning "ng-zorro-antd > @angular/cdk@11.2.13" has incorrect peer dependency "@angular/common@^11.0.0 || ^12.0.0-0".
warning "ng-zorro-antd > @ant-design/icons-angular@11.0.1" has incorrect peer dependency "@angular/common@^11.0.5".
warning "ng-zorro-antd > @ant-design/icons-angular@11.0.1" has incorrect peer dependency "@angular/core@^11.0.5".
warning "ng-zorro-antd > @ant-design/icons-angular@11.0.1" has incorrect peer dependency "@angular/platform-browser@^11.0.0".
[4/4] 🔨 Building fresh packages...
success Saved lockfile.
\$ node ./decorate-angular-cli.js && ngcc --properties es2020 browser module main && husky install

> NX Decoration of the Angular CLI is deprecated and will be removed in a future version

Please replace usage of "ng <command>" in any scripts, particularly for CI, with "nx <command>"

> NX Angular CLI has been decorated to enable computation caching.

husky - Git hooks installed

> NX Successfully finished running migrations from 'migrations.json'. This workspace is up to date!

All three steps above are done without any errors 🎉🎉🎉. I also tried to run the app with nx serve and it works fine.

nx:run-commands output not colored

Thu, 02 Mar 2023 09:32:00 GMT

Problem

We are using Nx in our project and recently we want to utlize nx:run-commands to run two commands:

nx serve
open a custom our configured domain

However, we found that the output of the command is not colored.

"serve-open": {
  "executor": "nx:run-commands",
  "options": {
    "commands": [
      "nx run my-bank:serve",
      "open https://our-custom-domain.local"
    ],
    "parallel": true
  }
}

Solution

After visiting some related issues, we found that we need to set --output-style to whether stream or stream-without-prefixes

This 10918#issuecomment-1202731648 is the most helpful one.

"serve-open": {
  "executor": "nx:run-commands",
  "options": {
    "commands": [
-     "nx run my-bank:serve",
+     "nx run my-bank:serve --output-style=stream-without-prefixes",
      "open https://our-custom-domain.local"
    ],
    "parallel": true
  }
}

Now the output looks as expected:

Prettier - prevent HTML closing tag > being placed on a new line?

Wed, 01 Feb 2023 06:45:00 GMT

Problem

Our project uses Prettier to format our code. We have Angular components that have HTML code in them.

Prettier formats the HTML code in the Angular component and places the closing tag > on a new line. This is not what we want.

<label class="mb-10 flex">
  <span>
    I accept the
    <a class="underline" routerLink="/tnc"
      >Our terms and conditions</a
    >
  </span>
</label>

The reason is because Prettier is trying to preserve the whitespace between the a tag and the closing tag >. Thus, it places text like >Our terms and conditions< so that the whitespace is preserved.

See the explanation from the Prettier documentation:

Solution

Since we are not interested in preserving the whitespace between HTML tag, we can tell Prettier to ignore the whitespace sensitivity by updating Prettier configuration file with htmlWhitespaceSensitivity option to ignore.

module.exports = {
  bracketSameLine: true,
  trailingComma: 'all',
  tabWidth: 2,
  semi: true,
  singleQuote: true,
+  htmlWhitespaceSensitivity: 'ignore',
};

Now run prettier again for all html files, the closing tag > should be on the same line as the last attribute.

npx prettier "**/*.html" --write --ignore-unknown

<label class="mb-10 flex">
  <span>
    I accept the
    <a class="underline" routerLink="/tnc">
      Our terms and conditions
    </a>
  </span>
</label>

References

Perceived Performance: The psychology of waiting

Fri, 13 Jan 2023 08:30:00 GMT

I recently took the course Web Performance Fundamentals, which covered an intriguing topic about perceived performance. This concept revolves around the psychology of waiting and how we can make our websites feel faster to users.

Over the years, I’ve been deeply interested in web performance and how to make websites faster. I’ve used tools like Lighthouse, WebPageTest, and Chrome DevTools to measure and improve my site’s performance. However, I never really considered the perceived performance of my website. I always focused on actual performance metrics like First Contentful Paint (FCP), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS). But perceived performance is just as crucial as actual performance. In this article, I’ll share insights from Todd Gardner’s course about the Psychology of Waiting and how we can apply these principles to make our websites feel faster to users.

Update 2024

I recently presented a 30-minute talk titled “Creating Fast-Feeling Web Apps” at JSConfJP in Tokyo, one of the largest web developer events in Japan. The feedback from attendees was overwhelmingly positive. You can view the slides and the recorded talk here: Creating Fast-Feeling Web Apps at JSConfJP.

The Psychology of Waiting

Todd Gardner referenced The Psychology of Waiting Lines by David Maister, which outlines eight key points. Here are six of them:

1. Wait Time is Subjective

Imagine going to an empty bar. You expect to be served quickly, but if the bartender is on the phone for a minute, it feels like a long wait because you have nothing to do. Conversely, in a busy bar with a bustling scene, the wait feels shorter because you’re engaged.

2. Bored Waits Feel Slower

Think about road trips before the era of smartphones and in-car entertainment. Staring out the window made the trip feel endless, even if it was just two hours.

3. Anxious Waits Feel Slower

Waiting for high-stress results, like visa approvals or loan decisions, feels much longer than waiting for something trivial. The uncertainty and anxiety make the wait unbearable.

4. Uncertain Waits Feel Slower

Not knowing how long a wait will be can make it feel interminable. Is it going to be a minute, five minutes, or an hour?

5. Unexplained Waits Feel Slower

If you don’t understand why you’re waiting, the wait feels longer. For example, if a bartender takes a long time without explanation, it feels frustrating.

6. People Will Wait for Value

People are willing to wait longer for something valuable. For instance, they’ll wait for a high-quality video to buffer but won’t wait long for a trivial news article.

Applying the Psychology of Waiting to Web Performance

Understanding these psychological principles can help us design web experiences that feel faster to users, even if the actual load times remain unchanged. However, before we dive into the solutions, let’s see how long is too long for users to wait.

Many cite Jakob Nielsen, who specifies three limits:

0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
10 seconds is about the limit for keeping the user’s attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

Bucketing timeframes by attention span (based on Steve Souw’s definitions and research by Rina A. Doherty and Paul Sorenson) proves more useful when assessing performance depending on length of the operation and perceived complexity:

Attention	Category	Response time	Description
Attentive	Instantaneous	below 300ms	Perceived as closed-loop system, where people are in direct control.
	Immediate	300ms–1 sec	Perceived as easy to perform.
	Transient	1–5 sec	Perceived as requiring some simple processing, but people still feel like they are making continuous progress. People are unlikely to disengage from task flow.
	Attention span	5–10 sec	Perceived as requiring more wait time. People need informative feedback to stay engaged.
Non-attentive	Non-attentive	10 sec–5 min	Perceived as requiring more complex processing. People are likely to disengage and multi-task.
	Walk-away	above 5 min	Perceived as requiring intensive processing. People won’t stay engaged with the task.

My Story with Perceived Performance

When I started my career as a frontend developer about 7-8 years ago, I thought I was doing everything right. Every time I fetched data, I showed a loading spinner. However, my boss kept complaining about how slow everything felt.

I checked the network tab, and everything seemed fine. The response time was less than 300ms, which is considered instantaneous.

The code itself was fairly simple, just a few states and a data fetch. What could be wrong?

export const useFetchVehicle = (vehicleId: string | undefined) => {
  const [vehicle, setVehicle] = useState<Vehicle | null>(null)
  const [loading, setLoading] = useState(false)
  const [error, setError] = useState<string | null>(null)

  useEffect(() => {
    const init = async () => {
      try {
        const data = await fetchVehicle(vehicleId)
        setVehicle(data)
      } catch (err) {
        setError((err as Error).message)
      } finally {
        setLoading(false)
      }
    }

    init()
  }, [vehicleId])

  return { vehicle, loading, error }
}

I was confused. I thought I was doing everything right. However, my boss asked, “Why is the spinner on forever?”

After much discussion, I realized that the spinner was the problem. For a resource as simple as the vehicle list, the spinner should not be there. Showing the spinner is necessary if the user’s network is slow or our API server is slow. But most of our users have high-speed internet, and our API server is fast. So the spinner was not needed. We decided to only show the spinner if the response time was more than 300ms.

To implement this, I added a delay of 300ms before showing the spinner. If the response time was less than 300ms, the spinner would not be shown.

export const useFetchVehicle = (vehicleId: string | undefined) => {
  useEffect(() => {
    let timer: ReturnType<typeof setTimeout>;
    const init = async () => {
      try {
+        timer = setTimeout(() => {
+          setLoading(true);
+        }, 300);
        const data = await fetchVehicle(vehicleId);
        setVehicle(data);
      } catch (err) {
        setError((err as Error).message);
      } finally {
+        if (timer) clearTimeout(timer);
        setLoading(false);
      }
    };

    init();
  }, [vehicleId]);

  return { vehicle, loading, error };
};

The result was very satisfying.

The spinner doesn’t show up anymore when the response time is less than 300ms. Users feel like the website is faster even though the actual response time is the same.

The spinner is only shown when the response time is more than 300ms.

Conclusion

Perceived performance is just as important as actual performance. By understanding the psychology of waiting, we can design web experiences that feel faster to users.

Reference

zsh history not working after VSCode upgrade

Mon, 12 Dec 2022 07:45:00 GMT

Problem

I recently updated my VSCode to the latest version and found that the zsh history is not working anymore. That’s how it looks when running the history command with only a few commands showing up.

When running echo $HISTFILE, it shows some random path that I don’t recognize. It should be ~/.zsh_history instead.

Others have reported the same issue on the VSCode GitHub repo for VS Code 1.74.0.

https://github.com/microsoft/vscode/issues/168396

Solution

The solution is to add the following line to your ~/.zshrc file to set the HISTFILE variable explicitly.

HISTFILE="$HOME/.zsh_history"

After that, run source ~/.zshrc to reload the configuration file. Now the HISTFILE variable should be set correctly thus the zsh history is working again.

The different between :focus and :focus-visible

Sat, 19 Nov 2022 07:45:00 GMT

Problem

Browsing the web using different input methods like a mouse, keyboard, or assistive technology devices requires clear indicators of the current interactive element for a good user experience and accessibility. While default browser stylesheets do a great job, there are cases where we may want more control over focus styling.

One common argument against focus indicators is that they appear even when you click on a component with a mouse or tap on it. Designers and stakeholders often don’t prefer this behavior.

Currently, modern browsers only show default focus indicators when necessary, specifically when navigating with a keyboard. The focus outline doesn’t show up when an element is clicked or tapped; it only appears when tabbing to it using a keyboard.

Understanding the Issue

In the provided code and example:

&:hover {
  background: red;
  color: white;
}

&:focus {
  outline-color: #007dbc60;
  outline-offset: 0.5rem;
  transform: scale(1.5);
}

We applied a different outline color and a transform(1.5) to the element to make the focus state visually obvious.

The problem arises when:

Navigating with the keyboard, both the outline and the element grow bigger with transform.
Clicking with the mouse, the outline is invisible, but the element still grows bigger with transform. This behavior is not desired.

Somehow, when we click, it also captures the focus state.

You may wonder why only the scale is applied, but not the outline.

The reason is that the outline is a property that is only visible when the element is focused using focus-visible under the hood. So, when we click, the outline is not visible, but the scale is still applied.

To solve this issue and show focus indicators only for users who need them, we can use the :focus-visible selector.

What is `:focus-visible`?

:focus-visible works just like :focus, but it only applies focus indicator styles to an element when it receives keyboard focus.

Now, the focus indicator will only be visible to users navigating with a keyboard or keyboard-like assistive technology. Users who aren’t using a keyboard won’t even know it’s there!

To fix the issue above, simply change :focus to :focus-visible in our CSS:

- &:focus {
+ &:focus-visible {
  outline-color: #007dbc60;
  outline-offset: 0.5rem;
  transform: scale(1.5);
}

Browser Support

The :focus-visible pseudo-class is supported by all major browsers except for IE11.

Support notes — March 2023

The :focus-visible pseudo-class is now supported in all major browsers.

But we recommend that default :focus styles are still provided, as a fallback for older versions, since focus indication is so critical.

Key Takeaways

If you want to display focus indicators only for keyboard users, utilize the :focus-visible pseudo-class instead of :focus.

Source code

See the Pen focus vs focus-visible by Trung Vo (@trungk18) on CodePen.

Angular 13 upgrade - Error: Unknown keyword formatMinimum

Sun, 13 Nov 2022 07:45:00 GMT

Problem

I recently upgraded my Angular project from version 12 to version 13 for our massive project at Ascenda.

After the upgrade, I ran into an error when I tried to build the project.

Error: Module build failed(from ./node_modules/mini-css-extract-plugin/dist/loader.js):

Error: Unknown keyword formatMinimum
    at get (/build/node_modules/ajv-keywords/dist/index.js:25:15)
    at ajvKeywords (/build/node_modules/ajv-keywords/dist/index.js:10:13)
    at Object.<anonymous> (/build/node_modules/webpack/node_modules/schema-utils/dist/validatejs:65:1)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/build/node_modules/webpack/node_modules/schema-utils/dist/indexjs:6:5)

As we can see, the error is related to the formatMinimum keyword in the ajv-keywords package.

The interesting problem is that the error only occurs on CI/CD when you delete the node_modules folder and reinstall the dependencies.

Investigation

First, to understand what is going on, we need to know where ajv-keywords is used in the node_modules folder.

npm ls ajv-keywords

As we can see, there are two versions of ajv-keywords in the node_modules folder.

adj-keywords@3.5.2 is used by schema-utils.
adj-keywords@5.1.0 is used by webpack and other packages.

We can clearly see npm indicated that our adj-keywords version is invalid in two places.

Where by adj-keywords@5.1.0 is required, however adj-keywords@3.5.2 is installed.

npm deduped

On the above screenshot, we can see that npm has indicated that adj-keywords was deduped.

But what is npm deduped?

deduped is short for “deduplicated” (duplicates were removed).

According to the npm documentation, npm dedupe is used to remove duplicate packages.

Searches the local package tree and attempts to simplify the overall structure by moving dependencies further up the tree, where they can be more effectively shared by multiple dependent packages.

In other words, it looks if multiple packages have the same dependencies (meaning the same packages and version range) and “points” them to the same package.

Meaning on our example above, despite many packages requiring adj-keywords@5.1.0, npm will only install this package once. Instead of installing it multiple times.

Solution

To solve this problem, we need to execute npm update to update the npm packages.

It will result in the package-lock.json file being updated and you will need to commit the changes.

npm update

After the update, we can see that the ajv-keywords version is correct without the invalid warning anymore.

Conclusion

npm update is a helpful command to update the npm packages that you might need to use when you encounter the npm deduped problem.

After resolving this problem, Our team at Ascenda also decided two things:

Upgrade the Angular project to version 14 straight away. Our first attempt at Angular 14 upgrade also failed due to the same npm deduped issue.
Use Yarn instead of npm to manage the dependencies.

The Angular team recommends using Yarn to manage the dependencies as well.

Why Web Performance Matters: An Introduction

Sun, 04 Sep 2022 16:00:00 GMT

In the fast-paced world of the web, performance is everything. Whether you’re running an e-commerce store, a personal blog, or a large-scale web application, how quickly and smoothly your site loads can make or break your user’s experience. Websites that load quickly and respond to user input in a timely fashion engage and retain users better than websites that are slow to load and feel sluggish.

1. What is Web Performance?

According to MDN, web performance is the objective measurement and perceived user experience of a website or application. This includes the following major areas:

Reducing overall load time: How long does it take for the files required to render the website to download onto the user’s computer? This is affected by latency, file size, the number of files, and other factors. Strategies include minimizing file sizes, reducing the number of HTTP requests, and using techniques like preloading to make files available sooner.
Making the site usable as soon as possible: Load website assets in a sensible order so that the user can start using it quickly. Other assets can load in the background, and some can be loaded only when needed (lazy loading). The time it takes for the site to become usable after it starts loading is called time to interactive.
Smoothness and interactivity: Does the application feel reliable and pleasurable to use? Is scrolling smooth? Are buttons clickable? Do pop-ups open quickly and animate smoothly? Best practices include using CSS animations instead of JavaScript and minimizing UI repaints due to DOM changes.
Perceived performance: How fast a website seems to the user impacts user experience more than actual speed. Keeping users engaged while they wait, such as showing a loading spinner or useful hints, can improve perceived performance.

To summarize, many factors impact performance, including latency, application size, the number of DOM nodes, resource requests, JavaScript performance, and CPU load. Minimizing loading and response times and adding features to conceal latency can make the experience as available and interactive as possible, as soon as possible.

2. The Impact of Web Performance on User Experience

User experience (UX) is at the heart of any successful website, and performance is a key component. Here’s why:

First Impressions Matter: Users form an impression of your site within the first few seconds of loading. A slow site can cause users to leave before it finishes loading.
User Engagement: Fast, responsive websites encourage users to stay longer, explore more content, and engage with features like forms, videos, and links. Slow sites drive users away, reducing engagement and increasing bounce rates.
Mobile Users: With more people accessing the web on mobile devices, performance is even more critical. Mobile users often have slower connections, so a site that loads quickly on desktop might still be slow on mobile.

3. The Business Case for Web Performance

Beyond user experience, web performance significantly impacts business metrics:

Conversion Rates: There is a direct correlation between page load time and conversion rates. A delay of even one second can lead to a significant drop in conversions, translating to lost revenue.
SEO and Search Rankings: Google considers page speed a ranking factor, particularly on mobile. A faster website is more likely to rank higher in search results, leading to increased visibility and traffic.
Customer Retention: Fast-loading sites build trust and credibility, encouraging users to return. Poor performance can lead to negative perceptions and reduced customer loyalty.

3.1 What is a webpage’s conversion rate?

In web terms, a user converts when they take the desired action on a webpage, such as purchasing a product, filling out a form, or clicking through to another page. The conversion rate is the percentage of visitors who convert. For example, if 100 users visit a page and 2 users click the ‘buy’ button, the conversion rate is 2%. Conversion rate optimization aims to increase this figure.

Conversion rate vs. page traffic

Conversion rate is separate from total traffic. If conversion rate declines, the number of conversions goes down even if traffic remains the same. Conversely, if traffic stays the same but conversion rate increases, the number of conversions goes up.

3.2 How does site speed affect conversion rates?

Website performance has a measurable effect on conversion rates. Studies show that faster page speed results in better conversion rates. For example, 47% of customers expect a webpage to load in 2 seconds or less, according to skilled.co. Testing by mPulse Mobile found that:

Pages loading in 2.4 seconds had a 1.9% conversion rate
At 3.3 seconds, conversion rate was 1.5%
At 4.2 seconds, conversion rate was less than 1%
At 5.7+ seconds, conversion rate was 0.6%

Other companies have experienced similar results:

Walmart found that for every 1 second improvement in page load time, conversions increased by 2%
COOK increased conversions by 7% by reducing page load time by 0.85 seconds
Mobify found that each 100ms improvement in homepage load time resulted in a 1.11% increase in conversion

These small increases in conversion significantly impact revenue. For example, if an e-commerce site generates 10 million dollars in sales per year, a 2% increase in conversion rate from a 1-second improvement in load time (as in the Walmart case study) results in a $200,000 increase in revenue.

3.3 What other factors besides page performance affect conversion rate?

Conversion rate is also affected by page design, layout, text, images, and more. If it’s unclear what action a visitor should take or if too many options are presented, they may leave the page. Regardless, website speed optimization should improve conversion rates even if other areas need optimization.

3.4 Website speed, SEO, and conversion rate

Page speed affects both conversion rate and SEO. Improving it can increase both total traffic and conversion rate.

See the following screenshot from my blog (updated 2024) from Google Search Console highlighting the good performance of the website:

Conclusion

Web performance is crucial for user experience, search rankings, and business success. By understanding its importance and optimizing your site, you can create a faster, more engaging, and more successful web presence. In upcoming posts, we’ll dive deeper into specific techniques and best practices for enhancing web performance, starting with the all-important Core Web Vitals.

ngIf - Store the conditional result in a variable

Wed, 31 Aug 2022 13:45:00 GMT

Sometimes we need to do an *ngIf with a complex condition, and we render the same result into the UI. For instance:

<div *ngIf="somethingThatCanBeVeryLong">{{ somethingThatCanBeVeryLong }}</div>

<span
  *ngIf="settings.data.details.groupName | someHelperPipe:'accountNumber'"
  >{{ settings.data.details.groupName | someHelperPipe:'accountNumber' }}
</span>

In this case, we can use the as keyword to store the condition as a local variable and use it in the template. We are probably familiar with this syntax in async pipe *ngIf="users$ | async as users", but we can use it in any other case with ngIf.

<span
  *ngIf="settings.data.details.groupName | someHelperPipe:'accountNumber' as accountNumber"
  >{{ accountNumber }}
</span>

1️⃣ When is this useful?

Access deep properties in an object

<span
  *ngIf="settings.data?.details?.groupName as groupName"
  >{{ groupName }}
</span>

The condition includes pipe, and you don’t want to apply the pipe again

<span
  *ngIf="settings.data.details.groupName | someHelperPipe:'accountNumber' as accountNumber"
  >{{ accountNumber }}
</span>

The condition includes a function call, and you don’t want to call it again. Obviously you don’t want to use a function call in the template, but sometimes you are lazy and just use it anyway 😂

Read this article to find out Why you should never use function calls in Angular template expressions

<span
  *ngIf="generateAccountNumber(settings.data.details.groupName) as accountNumber"
  >{{ accountNumber }}
</span>

2️⃣ How does it work under the hood?

Yeah, it’s magic that happens during template compilation.

The template below

<div *ngIf="user$ | async as user"></div>

is just sugar for:

<ng-template [ngIf]="user$ | async" let-user="ngIf">
  <div></div>
</ng-template>

On Angular source code, it sets the context to the same condition input -> common/src/directives/ng_if.ts#L171

@Input()
set ngIf(condition: T) {
  this._context.$implicit = this._context.ngIf = condition;
  this._updateView();
}

3️⃣ How `as` works?

In short, the compiler sees as keyword and do some magic so that it is equivalent to the let syntax.

See this yurzui’s stackoverflow.com answer for more details.

Common use cases and solutions for accessibility in Angular

Sun, 31 Jul 2022 03:45:00 GMT

At Ascenda, we built a suite of products that bring effortless rewards technology for financial services. One critical requirement is making the application accessible to all users. This blog will document the everyday use cases and solutions for accessibility in Angular that I have encountered along the way.

What is accessibility?

Broadly speaking, when we say a site is accessible, we mean that the site’s content is available, and its functionality can be operated, by literally anyone.

From web.dev/accessibility

While working with accessibility or a11y in short, you will hear a lot about Web Content Accessibility Guidelines (WCAG), a set of guidelines that define how to make web content accessible. However, WCAG can also be a bit overwhelming. To help mitigate this, the WebAIM (Web Accessibility in Mind) group has distilled the WCAG guidelines into an easy-to-follow checklist, targeted specifically for web content.

The WebAIM checklist can give you a short, high-level summary of what you need to implement, while also linking to the underlying WCAG specification if you need an expanded definition.

Compliances Levels

At Ascenda’s core fintech platform, many stakeholders are involved in making the application accessible, including product people, developers, designers, and QA engineers. For some of you that don’t know, the WCAG guidelines are classified into three conformance levels. We followed WCAG 2.1 Level A and AA criteria.

Level A - Considered the least strict, Level A success criteria are essential for every website. If your website doesn’t conform with WCAG Level A, it may have serious accessibility issues that prevent users with disabilities from using it.
Level AA - Websites that conform with WCAG Level AA can be considered reasonably accessible for most users. Most websites should aim for Level AA conformance. To meet this goal, content must conform with all Level AA and Level A success criteria.
Level AAA - Digital content that conforms with WCAG Level AAA is considered optimally accessible. To earn Level AAA conformance, content must pass every guideline in WCAG (including Level AA and Level A success criteria). However, some Level AAA success criteria are extremely strict, and some types of content cannot conform with every guideline at this level.

Our WCAG Ascenda Guideline has been rewritten to help understand WHAT is each criterion and HOW we could meet its requirements easier for all of the stakeholders. Following is an example of how it has been simplify for our team, hope you get the idea. I omit the section where we map each criterion to our product.

Criterion	Level	Type	Description
1.1.1 Non-text Content	A	Tech & Design	Provide alt-text for non-text content (Except for 1. decorative image 2. visual formatting 3. invisible elements)
1.3.1 Info and Relationships	A	Tech	Header, title and subtitle have various heading levels according to the content structure; For all pages, there is one and only one heading level 1 item.
1.4.1 Use of Color	A	Design	Don’t use presentation that relies solely on colour. This requirement is color specific while the 1.3.3. covers all other visual elements.
1.3.5 Identify Input Purpose	AA	Tech	Form fields can be recognized and auto-filled by browser.

And lot of more.

Testing Tools

We start with the following tools for testing

Keyboard
Screen reader
Page Magnifier

Keyboard

Keyboard accessibility is one of the most important aspects of web accessibility. Potential problems:

Focus indicator: a sighted keyboard user must be provided with a visual indicator of the element that currently has keyboard focus.
Navigation order
Items that cannot receive keyboard focus
Inaccessible custom widgets: complex menu, sliders, dialog, tab panel, etc. must all be built to support keyboard a11y.
Length navigation: tabbing through length navigation maybe particularly demanding for users with motor disabilities.

A “screen reader” is a software application that convert the text displayed on a computer screen into synthesized speech. Potential problems:

Elements does not have correct alt
Language of the page cannot be determined
Incorrect text pronunciation of foreign language

VoiceOver

VoiceOver is a screen reader that is available for Mac and iOS. It is a free software application that can be used to read aloud text on a screen.

1️⃣ How to start VoiceOver?

Command + F5
Command + press touch ID three times
System Preferences > Accessibility > VoiceOver and selecting Enable VoiceOver.

The VoiceOver Activation keys (called VO keys) are control + option. These keys are used to access special VoiceOver commands and functions and will be referenced simply as VO.

2️⃣ Basic useful commands

VO + A: Start reading
control: Stop Reading
VO + →: Read next item
VO + ←: Read previous item
VO + U: Navigate by various items such as Heading.

View full commands

3️⃣ Example

Common Use Cases

1. Visually break line, but Voiceover need to speak as one line

❌ Problem

Usually, you’ll have to use <br> tag to break line on the HTML code to make a new line. Why? The design will look nicely with two lines, why not? But if you need to do it for a heading, the Voiceover won’t be able to read it as one line. See the screenshot below for an example.

If I have this HTML

@Component({
  selector: 'break-line',
  template: `
    <h2>This is a great introduction <br /> and I need to be displayed in two lines</h2>
  `,
})

That’s how screen reader will read it:

You see it right, suddenly there is additional 3 items in the heading because we have <br> tag that break the sentence into two parts + the br itself.

✅ How to to fix it?

Instead of using br, you can:

Use the new line character \n and innerHTML for rendering.
Apply white-space: pre-line

@Component({
  selector: 'break-line',
  template: `
    <h2 [innerHTML]="'This is a great introduction \n and I need to be displayed in two lines'"></h2>
  `,
  styles: [
    `
      h2 {
        white-space: pre-line;
      }
    `,
  ],
})

That’s result, no more the annoying 3 items in the heading!

Source code

Resources

The following articles/blogs/websites are resources for learning about accessibility in Angular that I went through. Hope you find them useful!

Error: Cannot install in Homebrew on ARM processor in Intel default prefix (/usr/local)

Sat, 11 Jun 2022 03:45:00 GMT

Problem

I am setting my MacOS fresh again and setting up my terminal. I wanted to use neofetch to get a nice-looking terminal prompt. But upon running brew install neofetch, I got the following error:

Error: Cannot install in Homebrew on ARM processor in Intel default prefix (/usr/local)!
Please create a new installation in /opt/homebrew using one of the
"Alternative Installs" from:
  https://docs.brew.sh/Installation
You can migrate your previously installed formula list with:
  brew bundle dump

Apparently, this happens because I am using a Mac M1 with an ARM processor. As explained on stackoverflow

Homebrew needs to be installed in two places on Apple silicon:

/usr/local for rosetta-emulated (Intel) code,
/opt/homebrew for ARM64 (M1).

These are somewhat hard-coded and the /opt/homebrew one MUST be used for ARM code and is non-negotiable

How I solved it

Following those steps below fixes the error for me.

Install Rosetta2

/usr/sbin/softwareupdate --install-rosetta --agree-to-license

Install Homebrew for ARM M1 chip

arch -x86_64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Once installed homebrew for M1 ARM, use this Homebrew command to install packages. Noted the prefix arch -x86_64

arch -x86_64 brew install <package>

I ran the following for my use case above for neofetch.

arch -x86_64 brew install neofetch

I can then install neofetch as expected.

Next Steps

In the comment, rahul suggested that you should add an alias to your .zshrc file for future convenience.

alias alias brew86="arch -x86_64 /usr/local/homebrew/bin/brew"

Therefore the above install command will become

- arch -x86_64 brew install neofetch
+ brew86 install neofetch

⚠️ Because zsh runs the binary in /usr/local/bin by default. Running brew86 will probably change the location newly installed application to /usr/local/homebrew/bin/brew.

You must also add the following to .zshrc so that zsh recognizes the binary in the new location.

export PATH="/usr/local/homebrew/bin:$PATH"

Otherwise, you’ll see some errors like this:

zsh: command not found: pyenv

/usr/local/bin/code: line 6: python: command not found

Tue, 19 Apr 2022 13:45:00 GMT

Recently, when trying to run code . from terminal, I got the following error:

/usr/local/bin/code: line 6: python: command not found
/usr/local/bin/code: line 10: ./MacOS/Electron: No such file or directory

After searching on google, I found that Github issue #141738. The problem was Apple removed support for Python 2 on macOS 12.3. Therefore when code is trying to run python command, it will fail.

To fix the issue, do the following steps.

I got mine working by:

cd /usr/local/bin
nano code
change python => python3 on the following line

- function realpath() { python -c ...
+ function realpath() { python3 -c ...

To save the file on nano, press Ctrl + Option + o. Restart the terminal, and now code . works!

Multiple ng-content

Sun, 10 Apr 2022 03:45:00 GMT

Problem

I have a component with multiple ng-content. Basically if you passed a routerLink Input into the component, it will render <a> tag, otherwise it will render <button> tag. Obviously it is not how you design a link component but it is a good example. I actually did it around 2016 when I was learning Angular 😂

@Component({
  selector: 'app-link',
  template: `
    <a *ngIf="routerLink" [routerLink]="routerLink">
      {{ routerLink }} - <ng-content></ng-content>
    </a>
    <button *ngIf="!routerLink">
      <ng-content></ng-content>
    </button>
  `,
  styles: [],
})
export class LinkComponent {
  @Input() routerLink: string
}

And you would probably notice that the <a> tag was render but nothing come has been projected into <ng-content>.

<app-link routerLink="active">My link</app-link>
<br />
<app-link>My button</app-link>

The result come, but only the My button text get projected.

There are several issues has been created on the angular repository regarding this issue, for example #9173 and #22972.

Solution

Why it is working this way, I don’t think I can explain in an easy way for you. Therefore feel free to check misko’s detailed comment

One notable workaround can be found on #22972 nelisbijl’ comment. Essentially, you don’t try to render multiple ng-content, but putting ng-content inside an ng-template and render that template inside your ngIf.

@Component({
  selector: 'app-link-fixed',
  template: `
    <a *ngIf="routerLink" [routerLink]="routerLink">
      {{ routerLink }} -
      <ng-container *ngTemplateOutlet="contentTmpl"></ng-container>
    </a>
    <button *ngIf="!routerLink">
      <ng-container *ngTemplateOutlet="contentTmpl"></ng-container>
    </button>
    <ng-template #contentTmpl>
      <ng-content></ng-content>
    </ng-template>
  `,
  styles: [
    `
      :host {
        display: block;
      }
    `,
  ],
})
export class LinkFixedComponent {
  @Input() routerLink: string
}

Source code

My React Reading List

Sun, 12 Dec 2021 14:45:00 GMT

I have been working mainly with Angular in the previous few years and now moved to React for about a year. The following is my React reading list that I have collected over the past year, hope you enjoy it as much as I enjoyed reading and watching them.

View the full list here on notion

Slick - prevent layout shift for your slider

Sat, 18 Sep 2021 04:45:00 GMT

Recently, I revamped our new website with a completely new catchy design. It has many sliders, which is a very popular feature of most websites, and I wanted to implement it in a way that would not cause layout shifts. I choose Slick as the library to implement the slider.

All I need to do is include the library with a script tag, the required CSS from Slick and initialize it with a simple JavaScript.

$(window).on("load", function () {
  $(".js-slider").slick({
    arrow: true,
    dots: true
  });
});

HTML code would look like

<div class="container">
  <section class="js-slider">
    <div class="slide">
      <img src="https://via.placeholder.com/350x300?text=1" />
    </div>
    <div class="slide">
      <img src="https://via.placeholder.com/350x300?text=2" />
    </div>
    <div class="slide">
      <img src="https://via.placeholder.com/350x300?text=3" />
    </div>
  </section>
</div>

Notice that all images will be rendered first before the JS kicks in to initialize the slider that could cause a layout shift, as shown in the screenshot below. Locally, we usually don’t need to worry about the layout shift, but it is a must for our end users.

I could do a pretty easy fix with just a few lines of CSS. We need to ensure our images have the same styles before and after the scripts are parsed and executed. In this case, all it takes is the following:


.js-slider {  
  & > .slide:not(:first-child) {
    display: none;
  }
}

This way, we hide everything but the first slide in our carousel and add the padding on the sides that Slick will add after it loads. Slick will add extra wrapping elements to our slides, so the immediate children selector (>) will make the styles only apply before it loads.

Notice that the $(window).on("load" is important because if you use $(document).ready() it will not work as expected. $(window).on("load" will make sure the images are rendered before the slider is initialized.

Source code

See the Pen Slick - prevent layout shift for your slider by Trung Vo (@trungk18) on CodePen.

Reference

https://www.codementor.io/@michelre/using-box-shadow-to-construct-a-border-ex0rpxvng

CSS div jumped when adding a border

Sat, 21 Aug 2021 03:45:00 GMT

TL;DR:

Using box-shadow to highlight the div could be a good idea instead of using border.

Adding a border to a div

So, adding a border to a box, is pretty simple when you use the border property. Let’s start a first basic example by drawing a small square and adding a red border to it.

<div class="box border">Border</div>

.box {
  width: 100px;
  height: 100px;
  padding: 5px;
  margin-bottom: 10px;
}

.border {
  border: 1px solid red;

  &:hover {
    border: 3px solid red;
  }
}

Do you see what’s happening when your mouse is hovering the box? Your content move forward and the rendering is not really great.

If the normal border is 3px and when hover, it is also 3px. You can fix it with a simple trick to set the initial border to 3px transparent and then set the final border to 3px red. But here, we have initial of 1px and on hover 3px. That’s came to the solution below where we use box-shadow instead of border

Using box-shadow

box-shadow: inset | offset-x | offset-y | blur-radius | spread-radius | color;

Obviously, box-shadow is a property that is used to add shadow to a box. But we can utilize it to add a border to a box as well.

box-shadow: 0 1px 0 0 red; /* Border bottom */
box-shadow: 0 -1px 0 0 red; /* Border top */
box-shadow: -1px 0 0 0 red; /* Border left */
box-shadow: 1px 0 0 0 red; /* Border right */
box-shadow: 0 0 0 1px red; /* All the borders by using the spread properties */

So with that in mind, we can now use the box-shadow to resolve our previous issue. So I added a new box and drawn the borders with the box-shadow property:

<div class="box shadow">Box shadow</div>

.shadow {
  box-shadow: 0 0 0 1px red;

  &:hover {
    box-shadow: 0 0 0 3px red;
  }
}

Source code

See the Pen Border or box-shadow by Trung Vo (@trungk18) on CodePen.

Reference

https://www.codementor.io/@michelre/using-box-shadow-to-construct-a-border-ex0rpxvng

Align React Material UI Dialog to the top instead of center

Sat, 10 Jul 2021 13:45:00 GMT

As you work with Material Dialog, you should know that its default position is always to the center of the page. But more often, we want to make the dialog stick to the top instead.

1. For `scroll='paper'`

By default, the dialog alignment styles were inside the .MuiDialog-scrollPaper class with display: flex. So to easily change the position to the top, we only need to adjust align-items to flex-start and voila, the dialog now is displaying on the top as we expected.

2. For `scroll='body'`

.MuiDialog-paperScrollBody class with display: inline-block define the dialog position center. We need to adjust the vertical-align to top to make the dialog stay at the top.

Source code

Don’t use position: absolute or fixed because it will mess up the scroll behavior of the dialog

To always make the Material Dialog stay at the top of the page, you need to customize both class scrollPaper and paperScrollBody, as I mentioned above. The code will look like

const useStyles = makeStyles({
  topScrollPaper: {
    alignItems: 'flex-start',
  },
  topPaperScrollBody: {
    verticalAlign: 'top',
  },
})

function SimpleDialog(props: SimpleDialogProps) {
  const classes = useStyles()
  return (
    <Dialog
      onClose={handleClose}
      aria-labelledby="simple-dialog-title"
      open={open}
      scroll="paper"
      classes={{
        scrollPaper: classes.topScrollPaper,
        paperScrollBody: classes.topPaperScrollBody,
      }}
    ></Dialog>
  )
}

Demo

View on codesanbox

TypeScript - Property 'onerror' does not exist on type 'EventTarget'

Sat, 03 Jul 2021 10:45:00 GMT

Problem

Recently, I converted one legacy React component to TS, and this error starts to appear.

Property 'onerror' does not exist on type 'EventTarget'

<img
  className="vip-badge-avatar"
  src={`https://www.gravatar.com/avatar/${md5(
    user.email.toLowerCase()
  )}?size=80&d=blank`}
  onError={(e) => {
    e.target.onerror = null;
    e.target.src = userDefaultPicture;
  }}
  alt="Profile Avatar"
/>

Reason

By default an event target element has an EventTarget type in TypeScript. It has just a few properties that we can use, and most of the time, we will need to assert the event type to the correct type.

Solution

If I assert the type of the event target to HTMLImageElement, the TS error went away. The HTMLImageElement interface represents an HTML <img> element, providing the properties and methods used to manipulate image elements.

<img
  className="vip-badge-avatar"
  src={`https://www.gravatar.com/avatar/${md5(
    user.email.toLowerCase()
  )}?size=80&d=blank`}
  onError={(e) => {
    (e.target as HTMLImageElement).onerror = null;
    (e.target as HTMLImageElement).src = userDefaultPicture;
  }}
  alt="Profile Avatar"
/>

TypeScript data structure: Stack

Sat, 19 Jun 2021 11:45:00 GMT

Stack

In computer science, a stack is an abstract data type that serves as a collection of elements, with two principal operations:

push, which adds an element to the collection, and
pop, which removes the most recently added element that was not yet removed.

The order in which elements come off a stack gives rise to its alternative name, LIFO (last in, first out). Additionally, a peek operation may give access to the top without modifying the stack. The name “stack” for this type of structure comes from the analogy to a set of physical items stacked on top of each other, which makes it easy to take an item off the top of the stack, while getting to an item deeper in the stack may require taking off multiple other items first.

Simple representation of a stack runtime with push and pop operations.

Implementation

Implement using built-in object as a map, with tail pointer. I came up with this approach to make sure the Big O notation for the pop operation.

Operation	Description	Big O
push(value)	adds an element to the collection	O(1)
pop()	removes the most recently added element	O(1)
peek()	returns the most recently added element without modifying the stack	O(1)
clear()	removes all the element in the stack	O(1)
isEmpty	checks if the stack is empty	O(1)
size	checks the size of the stack	O(1)

Completed Source code

You can find the source code in my TS data structure repo

trungk18/typescript-data-structures/tree/master/data-structures/stack

import { ObjectType } from '../model/objectType';

export class Stack<T> {
  private _stack: ObjectType<T>;
  private _count: number;

  constructor() {
    this._stack = {};
    this._count = 0;
  }

  get isEmpty(): boolean {
    return this.size === 0;
  }

  get size(): number {
    return this._count;
  }

  push(value: T) {
    this._stack[this._count] = value;
    this._count++;
  }

  pop(): T {
    if (this.isEmpty) {
      return undefined;
    }
    this._count--;
    const value = this._stack[this._count];
    delete this._stack[this._count];
    return value;
  }

  peek(): T {
    if (this.isEmpty) {
      return undefined;
    }
    return this._stack[this._count - 1];
  }

  clear(): void {
    this._stack = {};
    this._count = 0;
  }

  print(): string {
    if (this.isEmpty) {
      return '';
    }
    let values = [];
    for (let i = 0; i < this._count; i++) {
      values.unshift((this._stack[i] as any).toString());
    }
    return values.join(' -> ');
  }
}

Alternative Implementation

Trivial implementation using Array - Using arr.splice() for pop, could take O(n). That will not meet the requirement of O(1) for pop operation.
Stack

References

Wikipedia

TypeScript data structure: Queue

Sun, 13 Jun 2021 03:45:00 GMT

Queue

In computer science, a queue is a collection of entities that are maintained in a sequence and can be modified by the addition of entities at one end of the sequence and the removal of entities from the other end of the sequence. By convention, the end of the sequence at which elements are added is called the back, tail, or rear of the queue, and the end at which elements are removed is called the head or front of the queue, analogously to the words used when people line up to wait for goods or services.

The operation of adding an element to the rear of the queue is known as enqueue, and the operation of removing an element from the front is known as dequeue. Other operations may also be allowed, often including a peek or front operation that returns the value of the next element to be dequeued without dequeuing it.

The operations of a queue make it a first-in-first-out (FIFO) data structure. In a FIFO data structure, the first element added to the queue will be the first one to be removed. This is equivalent to the requirement that once a new element is added, all elements that were added before have to be removed before the new element can be removed. A queue is an example of a linear data structure, or more abstractly a sequential collection

Representation of a FIFO (first in, first out) queue

Implementation

Implement using built-in object as a map, with tail pointer. I came up with this approach to make sure the Big O notation for the dequeue operation. You can implement with the same approach using array instead of object. But to take one element out of an array could take O(n).

Operation	Description	Big O
enqueue(value)	adds value at tail	O(1)
dequeue()	returns value and removes least recently added element (head)	O(1)
peek()	returns the value of the next element to be dequeued without dequeuing it	O(1)
clear()	removes all the element in the queue	O(1)
isEmpty	checks if the queue is empty	O(1)
size	checks the size of the queue	O(1)

Completed Source code

You can find the source code in my TS data structure repo

trungk18/typescript-data-structures/tree/master/data-structures/queue

import { ObjectType } from '../model/objectType';

export class Queue<T> {
  private _queue: ObjectType<T>;
  private _head: number;
  private _tail: number;

  constructor() {
    this._queue = {};
    this._head = 0;
    this._tail = 0;
  }

  get isEmpty() {
    return this.size === 0;
  }

  get size() {
    return this._tail - this._head;
  }

  enqueue(value: T): void {
    this._queue[this._tail] = value;
    this._tail++;
  }

  dequeue(): T {
    if (this.isEmpty) {
      return undefined;
    }
    const value = this._queue[this._head];
    delete this._queue[this._head];
    this._head++;
    return value;
  }

  peek(): T {
    if (this.isEmpty) {
      return undefined;
    }
    return this._queue[this._head];
  }

  clear(): void {
    this._queue = {};
    this._head = 0;
    this._tail = 0;
  }

  print(): string {
    if (this.isEmpty) {
      return '';
    }
    let values = [];
    for (let i = this._head; i < this._tail; i++) {
      values.unshift(this._queue[i].toString());
    }
    return values.join(' -> ');
  }
}

Alternative Implementation

Trivial implementation using Array - Using arr.shift() for dequeuing, take O(n) time. That will not meet the requirement of O(1) for dequeuing.
Queue

References

Wikipedia

TypeScript data structure: Singly linked list

Sun, 06 Jun 2021 15:15:00 GMT

Linked List

In computer science, a linked list is a linear collection of data elements, in which linear order is not given by their physical placement in memory. Instead, each element points to the next. It is a data structure consisting of a group of nodes which together represent a sequence. Under the simplest form, each node is composed of data and a reference (in other words, a link) to the next node in the sequence. This structure allows for efficient insertion or removal of elements from any position in the sequence during iteration. More complex variants add additional links, allowing efficient insertion or removal from arbitrary element references. A drawback of linked lists is that access time is linear (and difficult to pipeline). Faster access, such as random access, is not feasible. Arrays have better cache locality as compared to linked lists.

Singly Linked List

I implemented without the tail pointer.

Operation	Description	Big O
pushFront(value)	Adds an item to the front of the list	O(1)
popFront()	Remove front item and return its value	O(1)
front()	Get value of the front item	O(1)
pushBack(value)	Adds an item to the end of the list	O(n)
popBack()	Remove front item and return its value	O(n)
back()	Get value of the end item	O(n)
reverse()	Reverses the list	O(n)
has(value)	Return boolean if the list has a value	O(n)
remove(value)	Removes the first item in the list with this value	O(n)
isEmpty	Returns true if empty	O(1)
size	Returns number of data elements in list	O(1)

This is my notebook when implementing the reverse operation.

Completed Source code

You can find the source code in my TS data structure repo

trungk18/typescript-data-structures/tree/master/data-structures/linked-list

import { Comparator } from '../model/comparator'

export class Node<T> {
  constructor(public val: T, public next?: Node<T>) {}
}

export class LinkedList<T> {
  private _head: Node<T>;
  private _count: number;
  get head() {
    return this._head;
  }

  constructor(private _comparatorFunction = new Comparator<T>()) {
    this._head = null;
    this._count = 0;
  }

  /**
   * Returns true if empty
   */
  get isEmpty(): boolean {
    return this.size === 0;
  }

  /**
   * Returns number of data elements in list
   */
  get size(): number {
    return this._count;
  }

  /**
   * Adds an item to the front of the list
   * Time complexity: O(1)
   */
  pushFront(value: T): LinkedList<T> {
    this._count++;
    let node = new Node(value);
    node.next = this._head;
    this._head = node;
    return this;
  }

  /**
   * Remove front item and return its value
   * Time complexity: O(1)
   */
  popFront(): T {
    if (!this._head) {
      return undefined;
    }
    this._count--;
    let val = this._head.val;
    this._head = this._head.next;
    return val;
  }

  /**
   * Get value of the front item
   * Time complexity: O(1)
   */
  front(): T {
    if (!this._head) {
      return undefined;
    }
    return this._head.val;
  }

  /**
   * Adds an item to the end of the list
   * Time complexity: O(n)
   */
  pushBack(value: T): LinkedList<T> {
    let newNode = new Node(value);
    this._count++;
    if (!this._head) {
      this._head = newNode;
      return this;
    }
    let curr = this._head;
    while (curr.next) {
      curr = curr.next;
    }
    curr.next = newNode;
    return this;
  }

  /**
   * Remove front item and return its value
   * Time complexity: O(n)
   */
  popBack(): T {
    if (!this._head) {
      return undefined;
    }
    if (this.size === 1) {
      let val = this._head.val;
      this._head = null;
      this._count--;
      return val;
    }
    let curr = this._head;
    while (curr.next.next) {
      curr = curr.next;
    }
    let val = curr.next.val;
    curr.next = null;
    this._count--;
    return val;
  }

  /**
   * Get value of the end item
   * Time complexity: O(n)
   */
  back(): T {
    if (!this._head) {
      return undefined;
    }
    let curr = this._head;
    while (curr.next) {
      curr = curr.next;
    }
    return curr.val;
  }

  /**
   * Reverses the list
   * Time complexity: O(n)
   */
  reverse(): LinkedList<T> {
    let curr = this._head;
    let prev = null;
    let next = null;
    while (curr) {
      next = curr.next;
      curr.next = prev;
      prev = curr;
      curr = next;
    }
    this._head = prev;
    return this;
  }

  /**
   * Return boolean if the list has a value
   * Time complexity: O(n)
   */
  has(value: T): boolean {
    if (!this._head) {
      return undefined;
    }
    let curr = this._head;
    while (curr) {
      let hasValue = this._comparatorFunction.equal(value, curr.val);
      if (hasValue) {
        return true;
      }
      curr = curr.next;
    }
    return false;
  }

  /**
   * Removes the first item in the list with this value
   * Return true if delete success.
   * Time complexity: O(n)
   */
  remove(value: T): boolean {
    if (!this.head) {
      return false;
    }
    if (this._comparatorFunction.equal(this.head.val, value)) {
      this._head = this._head.next;
      this._count--;
      return true;
    }
    let curr = this._head;
    while (curr.next) {
      if (this._comparatorFunction.equal(curr.next.val, value)) {
        curr.next = curr.next?.next;
        this._count--;
        return true;
      }
      curr = curr.next;
    }
    return false;
  }

  print(): string {
    let arr = [];
    let curr = this._head;
    while (curr) {
      arr.push(curr.val);
      curr = curr.next;
    }
    return arr.join(' -> ');
  }

  clear(): void {
    this._head = null;
    this._count = 0;
  }
}

References

Difference between: function Person(){}, var person = Person(), and var person = new Person()?

Sat, 29 May 2021 08:15:00 GMT

Technically speaking, function Person(){} is just a normal function declaration. The convention is to use PascalCase for functions that are intended to be used as constructors.

function Person(name) {
  this.name = name
}

var person = Person() invokes the Person as a function, and not as a constructor. Invoking as such is a common mistake if the function is intended to be used as a constructor. Typically, the constructor does not return anything, hence invoking the constructor like a normal function will return undefined and that gets assigned to the variable intended as the instance.

var person = Person('John')
console.log(person) // undefined
console.log(person.name) // Uncaught TypeError: Cannot read property 'name' of undefined

var person = new Person() creates an instance of the Person object using the new operator, which inherits from Person.prototype. An alternative would be to use Object.create, such as: Object.create(Person.prototype).

var person = new Person('John')
console.log(person) // Person { name: "John" }
console.log(person.name) // "john"

Reference

Warning: Can’t perform a React state update on an unmounted component

Sat, 15 May 2021 08:15:00 GMT

If you are a react developer, there is a good chance that you faced this warning at least once:

Warning: Can’t perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

I got this issue as well and recently, I found an excellent blog post that explains why it happens and how to fix it. In short, it is happening when you are updating a component state after a task that takes time to complete. By the time it finishes, you have already shown another component.

You can see how it is reproduced below.

https://codesandbox.io/s/github/sag1v/react-async-state-debuggrio

And this is the full blog post from Sagiv Ben Giat.

https://www.debuggr.io/react-update-unmounted-component/

The proper and reusable fix is introducing a new hook named useIsMountedRef to check before you update your component state.

function useIsMountedRef() {
  const isMountedRef = useRef(null)
  useEffect(() => {
    isMountedRef.current = true
    return () => (isMountedRef.current = false)
  })
  return isMountedRef
}

Angular - Set page title automatically!

Sat, 01 May 2021 08:15:00 GMT

Hey guys, long time no Angular post.

I have been busy with Angular Spotify and Angular Singapore.

Today, I’ll share a block of code with you that my friend @nartc mentioned recently.

That’s how the output looks like

What we will do

Our code will basically do:

Listen to Router events
Filter the ResolveEnd events
Find the deepest activated route (usually is the current activated component)
Get the data.title that we set up on the router configuration
Set the HTML document title with the found title.

Source code

First, we need to configure the router with an additional title

const routes: Routes = [
  {
    path: '',
    component: HomeComponent,
    data: {
      title: 'Home',
    },
  },
  {
    path: 'dashboard',
    component: DashboardComponent,
    data: {
      title: 'Dashboard',
    },
  },
]

On the app.component.ts, setup the listener and extract the title

export class AppComponent implements OnInit {
  name = 'Angular ' + VERSION.major
  constructor(private readonly title: Title, private readonly router: Router) {}

  ngOnInit() {
    this.setupTitleListener()
  }

  private setupTitleListener() {
    this.router.events
      .pipe(filter(e => e instanceof ResolveEnd))
      .subscribe((e: ResolveEnd) => {
        const { data } = getDeepestChildSnapshot(e.state.root)
        if (data?.title) {
          console.log(data.title)
          this.title.setTitle(data.title)
        }
      })
  }
}

function getDeepestChildSnapshot(snapshot: ActivatedRouteSnapshot) {
  let deepestChild = snapshot.firstChild
  while (deepestChild?.firstChild) {
    deepestChild = deepestChild.firstChild
  }
  return deepestChild || snapshot
}

Voila, that’s all

Demo

Open angular-auto-set-page-title.stackblitz.io to view it on your browser.

Angular Singapore

Sat, 17 Apr 2021 10:15:00 GMT

Hey guys,

Recently I started a new group called Angular Singapore with the target to advocate and grow the Angular developer community in Singapore.

Activities

Our main activity includes:

Monthly meetup on the first Tuesday of the month. We invite speaker to come and talk about Angular with us. Follow @angularsg for the upcoming events :)
FREE one-on-one support. If you have any questions or need any advices, book our time here. We are here to help! https://calendly.com/trungvose/ama-w-trung
Office-hour sessions where we share our experience with live coding.

This is our first meetup photos. I’ll take a good one for the second meetup then 🙂

Speak with us

Send us your talk at @angularsg
We will get back to you!

Contact us

Where	What
@angularsg	Upcoming events
discord.gg/W5HCQfubJR	Discussion, questions, anything
calendly.com/angular-singapore	Talk to us, anything!
youtube.com/AngularSingapore	Our monthly recorded meetup, office hour and more

A simple Spotify client built with Angular 11, Nx workspace, ngrx, TailwindCSS and ng-zorro

Wed, 07 Apr 2021 10:15:00 GMT

Working application

Check out the live application -> https://spotify.trungk18.com

Spotify premium is required for the Web Playback SDK to play music. If you are using a free account, you can still browse the app, but it couldn’t play the music. Sorry about that 🤣

Support

If you like my work, feel free to:

⭐ this repository. And we will be happy together :)
Tweet about Angular Spotify
Get me a coffee ☕️

Thanks a bunch for stopping by and supporting me!

Who is it for 🤷‍♀️

I still remember Window Media Player on windows has the visualization when you start to play the music, and I wanted to have the same experience when listening to Spotify. That is the reason I started this project.

I found that there weren’t many resources on building a proper real-world scale application, and that’s my focus for sharing. I made a Jira clone application as the first one for that purpose. Nx workspace is getting more and more attention from the Angular community, but people are always confused about how to architect and set up a Nx project. I hope Angular Spotify will give you more insight on that despite the fact that it is my first project using Nx 🤣

You know I am one of the moderators of Angular Vietnam. Recently, I also started Angular Singapore. This piece of work is my another long-term plan to bring Angular knowledge to more people. I desire to advocate and grow the Angular developer community in Singapore and Vietnam :)

Tech stack

Angular 11
Nx Workspace
ngneat packages includes: ngneat/svg-icon and ngneat/until-destroy
ngrx and ngrx/component-store
ng-zorro UI component: tooltip, modal, slider, switch and more.
TailwindCSS
Netlify for deployment

I experimented with the ngrx/component store for AuthStore and UIStore. It might not be a best practice and I will refactor it very soon. Just FYI 🤣

High-level design

See my original notes on Nx workspace structure for NestJS and Angular

Principles

All components are following:

OnPush Change Detection and async pipes: all components use observable and async pipe for rendering data without any single manual subscribe. Only some places are calling subscribe for dispatching an action, which I will have a refactor live stream session with my friend @nartc to use the component store for a fully subscribe-less application.
SCAMs (single component Angular modules) for tree-shakable components, meaning each component will have a respective module. For example, a RegisterComponent will have a corresponding RegisterModule. We won’t declare RegisterComponent as part of AuthModule, for instance.
Mostly, everything will stay in the libs folder. New modules, new models, new configurations, new components etc… are in libs. libs should be separated into different directories based on existing apps. We won’t put them inside the apps folder. For example in an Angular, contains the main.ts, app.component.ts and app.module.ts

Structure

I followed the structure recommended by my friend @nartc. Below is the simplified version of the application structure.

.
└── root
    ├── apps
    │   └── angular-spotify
    └── libs
        └── web (dir)
            ├── shell (dir)
            │   ├── feature (angular:lib) - for configure any forRoot modules
            │   └── ui
            │       └── layout (angular:lib)
            ├── playlist (dir)
            │   ├── data-access (angular:lib, service, state management)
            │   ├── features
            │   │   ├── list (angular:lib PlaylistsComponent)
            │   │   └── detail (angular:lib PlaylistDetailComopnent)
            │   └── ui (dir)
            │       └── playlist-track (angular:lib, SCAM for Component)
            ├── visualizer (dir)
            │   ├── data-access (angular:lib)
            │   └── feature
            ├── home (dir)
            │   ├── data-access (angular:lib)
            │   ├── feature (angular:lib)
            │   └── ui (dir)
            │       ├── featured-playlists (angular:lib, SCAM for Component)
            │       ├── greeting (angular:lib, SCAM for Component)
            │       └── recent-played (angular:lib, SCAM for Component)
            └── shared (dir)
                ├── app-config (injection token for environment)
                ├── data-access (angular:lib, API call, Service or State management to share across the Client app)
                ├── ui (dir)
                ├── pipes (dir)
                ├── directives (dir)
                └── utils (angular:lib, usually shared Guards, Interceptors, Validators...)

Authentication Flow

I follow Implicit Grant Flow that Spotify recommended for client-side only application and does not involve secret keys. The access tokens that are issued are short-lived, and there are no refresh tokens to extend them when they expire.

View the Spotify Authorization Guide

Upon opening Angular Spotify, It will redirect you to Spotify to get access to your data. Angular Spotify only uses the data purely for displaying on the UI. We won’t store your information anywhere else.
Angular Spotify only keeps the access token in the browser memory without even storing it into browser local storage. If you do a hard refresh on the browser, It will ask for a new access token from Spotify. One access token is only valid for one hour.
After having the token, I’ll try to connect to the Web Playback SDK with a new player - Angular Spotify Web Player

Dependency Graph

Nx provides an dependency graph out of the box. To view it on your browser, clone my repository and run:

npm run dep-graph

A simplified graph looks like the following. It gives you insightful information for your mono repo and especially helpful when multiple projects are depending on each other.

Nx Computation Cache

Having Nx Cloud configured shorten the deployment time quite a lot.

Nx Cloud pairs with Nx in order to enable you to build and test code more rapidly, by up to 10 times. Even teams that are new to Nx can connect to Nx Cloud and start saving time instantly. Visit Nx Cloud to learn more.

Features and Roadmap

I set the tentative deadline for motivating myself to finish the work on time. Otherwise, It will take forever to complete :)

1.0 - Simple Spotify client

March 01 - 28, 2021

Proven, scalable, and easy to understand structure with Nx workspace
Play music using Spotify SDK
Load a maximum of 50 save playlists and top 100 songs per playlist.
Cool visualization

Live stream

Let work on it together!

I scheduled a few live stream sessions to show you how I continue developing Angular Spotify. Follow my twitter for the latest updates. See the scheduled events.

#	Time	Description/Link
1	Sat, 3rd April 2021, 10AM	Structure your Angular application with Nx workspace
2	Sat, 10th April 2021, 10AM	Build the album list page
3	Sat, 17th April 2021, 10AM	Build the album detail page
4	Sat, 24th April 2021, 10AM	Build the artist detail page
5	Sat, 1st May 2021, 10AM	Build the track list page
6	TBD	Setup i18n and support new language
7	TBD	Config Nx build:affected with Github action

I will also do some refactoring with @nartc for Angular Vietnam Office Hours. More detail is coming soon.

Time spending

It is a side project that I only spent time outside of the office hours to work on. I initially planned to complete the project within two weeks, but the first two weekends were not very productive, maybe because of the holiday mood from Lunar New Year :) But once the lego blocks are getting together, I feel the rhythm, and I know it has to be finished by the end of March.

I couldn’t get the full-time report from waka time because it only shows me the latest two weeks. 🤣

I have spent approximately 50 hours working on this project, which is almost the same amount that I worked on the first version of jira.trungk18.com.

The visualizer was the most exciting feature, and I decided to start this project because of that single component.

Accessibility ♿

Not all components have properly defined aria attributes, visual focus indicators, etc.

Setting up the development environment 🛠

git clone https://github.com/trungvose/angular-spotify.git
cd angular-spotify
npm start for starting Angular web application
The app should run on http://localhost:4200/

Unit/Integration tests 🧪

I skipped writing test for this project.

Compatibility

Web Playback SDK provided supports for Chrome, Firefox, Edge, IE 11, or above running on Mac/Windows/Linux.

It doesn’t support Safari or any mobile browser on Android or iOS

View completed list of supported browsers

Author: Trung Vo ✍️

A seasoned front-end engineer with seven years of passion in creating experience-driven products. I am proficient in Angular, React and TypeScript development.
Personal blog: https://trungvose.com/
Say hello: trungk18 [et] gmail [dot] com

Contributing

If you have any ideas, just open an issue and tell me what you think.

If you’d like to contribute, please fork the repository and make changes as you’d like. Pull requests are warmly welcome.

Credits and reference

Special thanks to my friend @nartc, who helped me review the code early.

Resource	Description
@koel/koel	A cool player made by @phanan, I reused the visualizer code from this repo with my additional customization
beeman/component-store-playground	A nice example of using Nx with ngrx/component-store, I refer to the project structure from this repo
Start using ngrx/effects for this	An excellent write up by Tim Deschryver

License

Feel free to use my code on your project. Please put a reference to this repository.

MIT

Nx Workspace structure for an application with NestJS and Angular

Wed, 24 Mar 2021 10:15:00 GMT

Original Gist

https://gist.github.com/trungk18/7ef8766cafc05bc8fd87be22de6c5b12

Principles

Below is the sample folder structure for Nx with NestJS and Angular. Our principles are:

SCAMs (single component Angular modules) for tree-shakable components, meaning each component will have a respective module. For example, a RegisterComponent will have a corresponding RegisterModule, we won’t declare RegisterComponent as part of AuthModule for example.
Mostly everything will stay in the libs folder. New modules, new models, new configurations, new components etc… are in libs. libs should be separated into different directories based on existing apps. We won’t put them inside the apps folder. For example in an Angular, it contains the main.ts, app.component.ts and app.module.ts

Structure

.
└── root
    ├── apps
    │   ├── api (nestjs)
    │   └── client (angular)
    └── libs (1)
        ├── api (dir)
        │   ├── core (dir)
        │   │   └── feature (nest:lib) (2)
        │   ├── feature-1 (dir)
        │   │   ├── data-access (nest:lib, service + entities)
        │   │   ├── feature (nest:lib, module + controller)
        │   │   └── utils (nest:lib, things like interceptors, guards, pipes etc...)
        │   └── feature-2 (dir)
        │       ├── data-access (nest:lib, service + entities)
        │       ├── feature (nest:lib, module + controller)
        │       └── utils (nest:lib, things like interceptors, guards, pipes etc...)
        ├── client (dir)
        │   ├── shell (dir)
        │   │   └── feature (angular:lib) (3)
        │   └── feature-1 (dir)
        │       ├── data-access (angular:lib, service, API calls, state management)
        │       ├── feature (4)
        │       │   ├── list (angular:lib e.g. ProductList)
        │       │   └── detail (angular:lib e.g. ProductDetail)
        │       ├── ui (dir)
        │       │   ├── comp-1 (angular:lib, SCAM for Component)
        │       │   └── pipe-1 (angular:lib, SCAM for Pipe)
        │       └── shared (dir)
        │           ├── data-access (angular:lib, any Service or State management to share across the Client app)
        │           ├── ui (dir, 5)
        │           └── utils (angular:lib, usually shared Guards, Interceptors, Validators...)
        └── shared (dir, most libs in here are buildable @nrwl/angular:lib)
            ├── data-access (my shared data-access is usually models, so it is a lib)
            ├── ui (optional dir, if I have multiple client apps)
            └── utils (optional dir, usually validation logic or shared utilities)
                ├── util1 (lib)
                └── util2 (lib)

(1) lib vs dir

a dir is just a directory.
a lib is generated by using Nx schematics

(2) api-core-feature: this is the CoreModule that will include all initial setups like Config and Database Connection etc… and importing other Modules. CoreModule will be imported by AppModule

(3) client-shell-feature: Same idea as NestJS’s CoreModule. This Shell includes RouterModule.forRoot()

(4) client-feature-1-feature: This can either a dir or a lib.

If this feature only has one Routable component, it is a lib.
If it has multiple Routable components, then it should be a dir. For example:

└── feature
    ├── list (angular:lib e.g ProductList)
    └── detail (angular:lib e.g. ProductDetail)

feature usually contains the ContainerComponent and the RouterModule.forChild()

(5) client-shared-ui is a little tricky. The general recommendation is to NOT grouped stuffs by type like components, pipes etc… into a single module but because these are shared, it is easy to get quite messy if not grouped by type. This is your call. We prefer to have a Single Component Per Module (SCAM) for each angular library.

This structure is proposed by my friend Chau Tran and I am applying it for my latest project!

Why?

Following the above structure will bring three advantages:

Consistency: eliminate mental overhead when we don’t have to think about where to put what in a big repo having from two apps and above.
Promote Single Component Per Module (SCAM) + Buildable libraries to get the benefits from the nx affected commands.
Prevent circular dependencies issue.

Some rules of thumb

data-access: data-access can import other data-access. But never import its feature . For example: user/data-access can import from product/data-access but it will never import from user/feature
feature: can only import its own data-access or the global shared/data-access. For example: user/feature can import from user/data-access but never from product/data-access.
util: Utils can be shared across data-access, util.

SVG fill color doesn't work with hex colors

Wed, 17 Mar 2021 10:15:00 GMT

Problem

Basically, this works fine with fill='red'

background: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' width='20' height='10' ><path fill='red' d='M 0,10 H 20 L 10,0 Z' /></svg>")

This doesn’t work as well with fill='#FF0000'

background: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' width='20' height='10' ><path fill='#FF0000' d='M 0,10 H 20 L 10,0 Z' /></svg>")

Reason and solution

# in URLs starts a fragment identifier. So, in order to make that work, write %23 instead of #. That is the value of escaped # character. It works with fill='%23FF0000'

background: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' width='20' height='10' ><path fill='%23FF0000' d='M 0,10 H 20 L 10,0 Z' /></svg>")

Wondering what is Fragment Identifiers, check this article

https://css-tricks.com/svg-fragment-identifiers-work/

Reference

https://stackoverflow.com/a/61099329/3375906

Demo

See the Pen Hexadecimal color values in SVG as data url by Gunnar Bittersmann (@gunnarbittersmann) on CodePen.

TypeScript unknown vs any types

Sat, 13 Mar 2021 10:15:00 GMT

TypeScript 3.0 introduced a new unknown type which is the type-safe counterpart of the any type.

The main difference between unknown and any is that unknown is much less permissive than any: we have to do some form of checking before performing most operations on values of type unknown, whereas we don’t have to do any checks before performing operations on values of type any.

Reference

The unknown Type in TypeScript - Marius Schulz This is a great article and I recommended you read the full one. I only quote some of the important parts :)
https://stackoverflow.com/a/51439876/3375906

The any Type

Let’s first look at the any type so that we can better understand the motivation behind introducing the unknown type.

The any type has been in TypeScript since the first release in 2012. It represents all possible JavaScript values — primitives, objects, arrays, functions, errors, symbols, what have you.

In TypeScript, every type is assignable to any. This makes any a top type (also known as a universal supertype) of the type system.

Here are a few examples of values that we can assign to a variable of type any:

let value: any

value = true // OK
value = 42 // OK
value = 'Hello World' // OK
value = [] // OK
value = {} // OK
value = Math.random // OK
value = null // OK
value = undefined // OK
value = new TypeError() // OK
value = Symbol('type') // OK

The any type is essentially an escape hatch from the type system. As developers, this gives us a ton of freedom: TypeScript lets us perform any operation we want on values of type any without having to perform any kind of checking beforehand.

In the above example, the value variable is typed as any. Because of that, TypeScript considers all of the following operations to be type-correct:

let value: any

value.foo.bar // OK
value.trim() // OK
value() // OK
new value() // OK
value[0][1] // OK

In many cases, this is too permissive. Using the any type, it’s easy to write code that is type-correct, but problematic at runtime. We don’t get a lot of protection from TypeScript if we’re opting to use any.

What if there were a top type that was safe by default? This is where unknown comes into play.

The unknown Type

Just like all types are assignable to any, all types are assignable to unknown. This makes unknown another top type of TypeScript’s type system (the other one being any).

Here’s the same list of assignment examples we saw before, this time using a variable typed as unknown:

let value: unknown

value = true // OK
value = 42 // OK
value = 'Hello World' // OK
value = [] // OK
value = {} // OK
value = Math.random // OK
value = null // OK
value = undefined // OK
value = new TypeError() // OK
value = Symbol('type') // OK

All assignments to the value variable are considered type-correct.

What happens though when we try to assign a value of type unknown to variables of other types?

let value: unknown

let value1: unknown = value // OK
let value2: any = value // OK
let value3: boolean = value // Error
let value4: number = value // Error
let value5: string = value // Error
let value6: object = value // Error
let value7: any[] = value // Error
let value8: Function = value // Error

The unknown type is only assignable to the any type and the unknown type itself. Intuitively, this makes sense: only a container that is capable of holding values of arbitrary types can hold a value of type unknown; after all, we don’t know anything about what kind of value is stored in value.

Let’s now see what happens when we try to perform operations on values of type unknown. Here are the same operations we’ve looked at before:

let value: unknown

value.foo.bar // Error
value.trim() // Error
value() // Error
new value() // Error
value[0][1] // Error

Narrowing the unknown Type

We can narrow the unknown type to a more specific type in different ways, including the typeof operator, the instanceof operator, and custom type guard functions.

The following example illustrates how value has a more specific type within the two if statement branches:

function stringifyForLogging(value: unknown): string {
  if (typeof value === 'function') {
    // Within this branch, `value` has type `Function`,
    // so we can access the function's `name` property
    const functionName = value.name || '(anonymous)'
    return `[function ${functionName}]`
  }

  if (value instanceof Date) {
    // Within this branch, `value` has type `Date`,
    // so we can call the `toISOString` method
    return value.toISOString()
  }

  return String(value)
}

In addition to using the typeof or instanceof operators, we can also narrow the unknown type using a custom type guard function:

/**
 * A custom type guard function that determines whether
 * `value` is an array that only contains numbers.
 */
function isNumberArray(value: unknown): value is number[] {
  return (
    Array.isArray(value) && value.every(element => typeof element === 'number')
  )
}

const unknownValue: unknown = [15, 23, 8, 4, 42, 16]

if (isNumberArray(unknownValue)) {
  // Within this branch, `unknownValue` has type `number[]`,
  // so we can spread the numbers as arguments to `Math.max`
  const max = Math.max(...unknownValue)
  console.log(max)
}

Notice how unknownValue has type number[] within the if statement branch although it is declared to be of type unknown.

Using Type Assertions with unknown

If you want to force the compiler to trust you that a value of type unknown is of a given type, you can use a type assertion like this:

const value: unknown = 'Hello World'
const someString: string = value as string
const otherString = someString.toUpperCase() // "HELLO WORLD"

Be aware that TypeScript is not performing any special checks to make sure the type assertion is actually valid. The type checker assumes that you know better and trusts that whatever type you’re using in your type assertion is correct.

This can easily lead to an error being thrown at runtime if you make a mistake and specify an incorrect type:

const value: unknown = 42
const someString: string = value as string
const otherString = someString.toUpperCase() // BOOM

The value variable holds a number, but we’re pretending it’s a string using the type assertion value as string. Be careful with type assertions!

Convert Promise to Observable

Sun, 07 Mar 2021 10:15:00 GMT

Promise is the answer to the callback hell problem. With the introduction of async/await syntax, Promise is getting so popular. But if you work with Angular, you’ll probably need an Observable from Promise sometimes. There are few ways for you to do so.

Assume that I have a function, getPromise, that resolves after two seconds and does a simple console.log.

const getPromise = (source: string) => {
  return new Promise(resolve => {
    console.log('Promise created for', source)
    setTimeout(() => resolve(`Promise Resolved: ${source}`), 2000)
  })
}

1. Direct Execution / Conversion

Use from to directly convert a previously created Promise to an Observable.

import { from } from 'rxjs'

// getPromise() is called once, the promise is passed to the Observable
const observableFrom$ = from(getPromise('FROM'))
observableFrom$.subscribe(console.log)
observableFrom$.subscribe(console.log)

observableFrom$ will be a hot Observable that effectively replays the Promises value to Subscribers.

It’s a hot Observable because the producer (in this case, the Promise) is created outside of the Observable. And because Promise is eager, you’ll start seeing Promise created for FROM on the browser when running from(getPromise()) console immediately after you call from(getPromise("FROM"))

Promise created for FROM
Promise Resolved: FROM
Promise Resolved: FROM

Multiple subscribers will share the same Promises, which means if you subscribe to observable$ multiple times, you’ll still see only one Promise created for FROM.

Use defer with a Promise factory function as input to defer the creation and conversion of a Promise to an Observable.

import { defer } from 'rxjs'

// getPromise() is called every time someone subscribes to the observable$
const observableDefer$ = defer(() => getPromise('DEFER'))
observableDefer$.subscribe(console.log)
observableDefer$.subscribe(console.log)

observableDefer$ here will be a cold Observable.

It’s a cold Observable because the producer (the Promise) is created inside of the Observable. Each subscriber will create a new Promise by calling the given Promise factory function.

This allows you to create an observableDefer$ without creating and thus executing a Promise right away and without sharing this Promise with multiple subscribers. Each subscriber to observableDefer$ effectively calls from(promiseFactory()).subscribe(subscriber). Meaning if you subscribe to observableDefer$ multiple times, you’ll see Promise created for FROM each time.

Promise created for DEFER
Promise created for DEFER
Promise Resolved: DEFER
Promise Resolved: DEFER

3. Many Operators Accept Promises Directly

Most RxJS operators that combine (e.g. merge, concat, forkJoin, combineLatest …) or transform observables (e.g. switchMap, mergeMap, concatMap, catchError …) accept promises directly. If you’re using one of them anyway, you don’t have to use from to wrap a promise first (but to create a cold observable you still might have to use defer).

// Execute two promises simultaneously
forkJoin(getPromise(1), getPromise(2)).pipe(
  switchMap(([v1, v2]) => v1.getPromise(v2)) // map to nested Promise
)

Check the documentation or implementation to see if the operator you’re using accepts ObservableInput or SubscribableOrPromise.

type ObservableInput<T> = SubscribableOrPromise<T> | ArrayLike<T> | Iterable<T>
// Note the PromiseLike ----------------------------------------------------v
type SubscribableOrPromise<T> =
  | Subscribable<T>
  | Subscribable<never>
  | PromiseLike<T>
  | InteropObservable<T>

Source code

Reference

Convert Promise to Observable - answer by frido

Migrate Angular to ESLint

Sat, 23 Jan 2021 04:18:00 GMT

TSLint is deprecated

TSLint has been a default configuration for linting with Angular CLI for a long time, until its author decided to deprecated TSLint. If you run npm run lint in your project that was created with CLI, you will get the below warning.

As suggested in the warning message, head over to angular-eslint, and we will prepare to migrate away from TSLint.

Migrate to angular-eslint

I will use this opportunity to migrate angular-tetris to Angular 11 and angular-eslint

Prerequisite

angular-eslint support Angular CLI 10.1.0 and onwards, including Angular CLI 11.x.

So that, make sure that you update your Angular CLI first before going ahead. Suppose you install @angular/cli globally. Please run the following command to update its version.

npm i @angular/cli

If you have @angular/cli as the devDependencies, you can run.

npx ng update @angular/cli

To perform update both the CLI and all of @angular related packages, you can run.

npx ng update @angular/cli @angular/core

Step 1: Add relevant dependencies

The first step is to run the schematic to add @angular-eslint to your project:

npx ng add @angular-eslint/schematics

This command adds the needed dependencies for angular-eslint, which looks like the below screenshot.

Step 2: Run the convert-tslint-to-eslint schematic on a project

The next thing to do is consider which “project” you want to migrate to use ESLint. If you have a single application in your workspace, you will likely have just a single entry in the projects configuration object within your angular.json file. If you have a projects/ directory in your workspace, you will have multiple entries in your projects configuration, and you will need to chose which one you want to migrate using the convert-tslint-to-eslint schematic.

In my use case, I only have a single application - angular-tetris

I will run the following command to migrate to ESLint.

npx ng g @angular-eslint/schematics:convert-tslint-to-eslint angular-tetris

It will do two things.

Update angular.json to replace tslint with angular-eslint for linting configuration.

Create a .eslintrc.json file based on your tslint.json file

The content of the file will be similar to a sample configuration here

I recommended you to read the full Notes on ESLint Configuration

Now, if you run npx ng lint, it will use ESLint under the hood.

⚠️ I faced a strange error when running this command on another project

Invalid rule result: Instance of class Promise

I look it up on google but all of the reported issues were related to @angular/devkit version and stuff, which didn’t fix mine.

I ended up doing two manual steps, as explained above:

Update angular.json to replace tslint with angular-eslint for linting configuration. You can copy from this code
And created a .eslintrc.json, and filled in content from what I already have for angular-tetris .eslintrc

Step 3: Remove `tslint` and `codelyzer` from package.json

You could either do it manually by removing those from package.json, but remember to run another npm i to update your package-lock.json.

Or you could run npm uninstall -S tslint codelyzer for that purpose.

And then manually delete tslint.json

Fix all the lint errors in Angular Tetris

After having eslint set up, I run npm run lint and get many errors.

I added one more command on package.json to automatically fix problems if possible.

"lint:fix": "ng lint --fix",

After cleaning all of the errors, that’s how it looks.

Setup husky and pre-commit hooks

Having lint setup is useless if you have to run it manually every time before you make a commit. Because most of the time, we will forget about running lint part. 😂 Pre-commit checks are commonly used to run linting scripts and tests, allowing each commit to be as clean as possible.

If we only setup lint to run on CI, developers allow to put not very clean code to our branch. Imagine a CI process take 15 minutes to run and when a developer push a commit, and move on to another task. If he realizes the CI has been failed after 10 minutes, he has to switch back to the other branch and fix the code, reducing productivity. We should set up lint on both pre-commit hook and CI.

And you should never use --no-verify to skip the lint process locally.

Husky

Husky make git hooks easy. It can prevent bad git commit, git push and more

Install husky by running

npm i -D husky

And then modify the package.json to looks like below.

npm run lint will always run when I try to commit a code.

Test husky

I defined a variable that doesn’t satisfy camelCase or UPPER_CASE, Test_Var. When trying to commit the code, husky prevents me from committing because lint doesn’t pass.

Works great.

Takeaways

Migrate from TSLint to ESLint is simple with @angular-eslint.
Set up a pre-commit hook to catch lint errors early and keep the code base clean.

Homework

Notice that npm run lint will lint all the files in our application, which we only want to run on CI. We want to run lint only on modified files or on staged files for local development. It will enhance the development experience a lot more. It would be best if you considered doing some research about it. Let me know in the comment what is your solution :)

Source code

https://github.com/trungvose/angular-tetris/pull/12

Capture picture from your Webcam in Angular

Sat, 16 Jan 2021 04:15:00 GMT

Use case

If you trade crypto often, you will notice that their verification process involves a step to upload a photo of you with your identity card. Or you can capture it via webcam. Refer to the below picture taken from Binance.

After selecting the Take Photo option, it will ask for your permission to use the webcam. If you allow, then you can start to take a photo with your webcam.

Output

We will build something similar to the output below.

Web API MediaDevices

The MediaDevices interface provides access to connected media input devices like cameras and microphones and screen sharing. In essence, it lets you obtain access to any hardware source of media data.

We will utilize the MediaDevices for accessing the webcam. Some methods worth mentioning:

navigator.mediaDevices.enumerateDevices(): requests a list of the available media input and output devices, such as microphones, cameras, headsets, and so forth.
getUserMedia(): with the user’s permission through a prompt, turns on a camera and/or a microphone on the system

It will ask for your permission, similar to the below photo.

WebcamSnapshotModule

I started by creating a new fresh:

WebcamSnapshotComponent
WebcamSnapshotModule

SCAMs (single component Angular modules) are Angular modules scoped to a single declarable, and you should follow that to create reusable pieces for your application.

Refer to the below step how to do it on stackblitz

One additional step I need to do it to export WebcamSnapshotComponent on the WebcamSnapshotModule

@NgModule({
  imports: [CommonModule],
  declarations: [WebcamSnapshotComponent],
  exports: [WebcamSnapshotComponent],
})
export class WebcamSnapshotModule {}

WebcamSnapshotComponent

Now we have the component and module ready. Let go ahead and write the actual code for accessing the webcam.

webcam-snapshot.component.html

Open webcam-snapshot.component.html and put in the code.

<div class="video-container">
  <video
    [class.show]="!isCaptured"
    [class.hide]="isCaptured"
    #video
    id="video"
    [width]="WIDTH"
    [height]="HEIGHT"
    autoplay
  ></video>
  <canvas
    [class.show]="isCaptured"
    [class.hide]="!isCaptured"
    #canvas
    id="canvas"
    [width]="WIDTH"
    [height]="HEIGHT"
  ></canvas>
</div>

<div class="snap-container">
  <button class="btn btn-primary" *ngIf="!isCaptured" (click)="capture()">
    Snap Photo
  </button>
</div>

I have a video tag for displaying the webcam stream. Also, a canvas to render the image after taking the photo with a button name Snap Photo. Please be noted that both video and canvas have the template reference by using # to access it using ViewChild.

webcam-snapshot.component.ts

Now let look at the code that does the heavy lifting part.

export class WebcamSnapshotComponent implements AfterViewInit {
  WIDTH = 640;
  HEIGHT = 480;

  @ViewChild("video")
  public video: ElementRef;

  @ViewChild("canvas")
  public canvas: ElementRef;

  captures: string[] = [];
  error: any;
  isCaptured: boolean;

  async ngAfterViewInit() {
    await this.setupDevices();
  }

  async setupDevices() {
    if (navigator.mediaDevices && navigator.mediaDevices.getUserMedia) {
      try {
        const stream = await navigator.mediaDevices.getUserMedia({
          video: true
        });
        if (stream) {
          this.video.nativeElement.srcObject = stream;
          this.video.nativeElement.play();
          this.error = null;
        } else {
          this.error = "You have no output video device";
        }
      } catch (e) {
        this.error = e;
      }
    }
  }

  capture() {
    this.drawImageToCanvas(this.video.nativeElement);
    this.captures.push(this.canvas.nativeElement.toDataURL("image/png"));
    this.isCaptured = true;
  }

  drawImageToCanvas(image: any) {
    this.canvas.nativeElement
      .getContext("2d")
      .drawImage(image, 0, 0, this.WIDTH, this.HEIGHT);
  }
}

I have:

WIDTH and HEIGHT const for the webcam and canvas size
video and canvas refer to the template using the template reference. By default, you can only access them after the view has been init using ngAfterViewInit. That’s why I implement AfterViewInit interface instead of OnInit hook. See more about that
setupDevices is where I start to ask for permission using video. getUserMedia return a Promise. That’s why I am using async/await. You could still use then if you are comfortable with that. Noted that the returned stream could be null if your device has no video output device.
capture is to take the current video screenshot and draw it into our canvas using drawImageToCanvas. At the same time, I also push the data into the captures array. It is just base64 encoded image data. You could use that for uploading to the server if required.

Source code and demo

Please open this stackblitz in a new window for testing. If it is not working, try click Refresh on stackblitz.

It happens to me as well :(

Conclusion

You just saw how to use Angular to capture images from the webcam using a web browser. You can always use a library for that purpose. But it is essential to understand how things work under the hood :)

Reference

Webcam Image Capture with Angular

Observable for Angular Output

Sat, 09 Jan 2021 04:15:00 GMT

I have one suggestion for you guys for using Observable for Output in Angular. I thought you might not know about that because it wasn’t get mentioned in the documentation. Take a look at the below code and and I will explain on the later part.

Before

@Output() someEvent = new EventEmitter();
this.someSource$.pipe(
   /* additional logic transformation */
).subscribe(data => this.someEvent.emit(data));

After

@Output() someEvent = this.someSource$.pipe(
  /* additional logic transformation */
);

As you can see, the before and after code was pretty much identical. Its use-case is applicable when you want to use Output to emit something for the Parent Component when someSource$ emit data. But why it works?

To go a bit deeper, you need to understand two things:

Event Binding syntax (eventName)
class EventEmitter

Event Binding Syntax ()

Event binding is what you see when using a parenthesis and a event name on the template part, e.g. <child (someEvent)="invokeSomeEvent()"></child>.

Basically, Angular Compiler will parse all the template to Abstract Syntax Tree (AST) so that I can have all information regarding the current template. For the event binding, Angular knows which event get binding on the template itself.

If you look at source code of output_interpreter, there is one path to check if the current event is SubscribeObservable, it will automatically subscribe to that Observable.

What does this mean? If event is either Observable/Subject, Event Binding syntax () will automatically do the subscribe.

EventEmitter class

EventEmitter is a subclass of Subject under the hood. And as you might have already known, Subject acts as both Observable and Observer. With the code on the above output_interpreter, if you change an EvenEmitter with a Subject/Observable, it will be automatically subscribed.

When you understand the two concepts Event Binding syntax and EventEmitter, I hope you get why the above code works.

Some use-case

Interval Output
State Selector (ngrx)
… Anything related to streams…

Example

Angular team also use this approach for one of their search-box component example. Thanks chandlerfang for the input!

View the source code

@Component({
  selector: 'aio-search-box',
  template: `
    <input
      #searchBox
      type="search"
      aria-label="search"
      placeholder="Search"
      (keyup)="doSearch()"
    />
  `,
})
export class SearchBoxComponent implements AfterViewInit {
  private searchDebounce = 300
  private searchSubject = new Subject<string>()

  @Output() onSearch = this.searchSubject.pipe(
    distinctUntilChanged(),
    debounceTime(this.searchDebounce)
  )

  doSearch() {
    this.searchSubject.next(this.query)
  }
}

Have fun!

Thanks Chau Tran for the original Vietnamese version.

10 Modern CSS layout and sizing techniques

Fri, 25 Dec 2020 16:16:00 GMT

10 Modern CSS layout

This video from Una is amazing. You have to watch it. Below was the summary that I took from her video. You can try it live on 1linelayouts.glitch.me

10 Modern CSS layout and sizing techniques highlight just how robust and impactful a single-line of styling code can be.

1. Super Centered

place-items: center

2. The Deconstructed Pancake

flex: 0 1 <baseWidth>

grid-template-columns: minmax(<min>, <max>) ...

4. Pancake Stack

grid-template-rows: auto 1fr auto

5. Classic Holy Grail Layout

grid-template: auto 1fr auto / auto 1fr auto

6. 12-Span Grid

grid-template-columns: repeat(12, 1fr)

7. RAM (Repeat, Auto, Minmax)

grid-template-columns: repeat(auto-fit, minmax(<base>, 1fr))

8. Line Up

justify-content: space-between

9. Clamping My Style

clamp(<min>, <actual>, <max>)

10. Respect for Aspect

aspect-ratio: <width> / <height>

Trung Vo's RSS Feed

Upgrading to Angular 20: more AI gotcha than I expected

1. Where Angular Spotify stands today

2. Kicking off Claude Code for planning

3. Four prep PRs: peer-dependency analysis

3.1 Sentry (blocker) · PR #112

3.1.a Gotcha 1: right pattern, wrong source

3.2 ng-zorro (blocker) · PR #113

3.3 Gotcha 2: RxJS is not actually required for Angular 18 · PR #114

3.4 Cypress (non-blocker) · PR #115

4. Four subagents, one parallel run

5. Source

6. Two lessons

How to hide Agent View by default on startup in Antigravity

Steps

Upgrade to Angular 20 from Angular 13 - Part 7: Angular 20 with Claude Code

1. What changed

2. Dependency upgrades

3. Build system and TailwindCSS

3.1 Esbuild migration (success)

3.2 Tailwind v4 attempt (failure)

3.3 Investigating Tailwind v4

3.4 Downgrading to Tailwind v3

4. Karma to Vitest

5. ESLint flat config

6. Storybook removal

7. Claude Code session

8. Deploy output path changed

9. Source code

10. What I learned

Fuzzy search everywhere on macOS with fzf and fd

What is fzf

fzf preview

What I actually needed

Why fd over find

Control what fd searches with .ignore

Wire it up in .zshrc

iTerm2 hotkey to trigger fzf-open

Make it fast with a dedicated script

Cmd+Up and Cmd+Down in fzf

Final Result

Speed up zsh startup by lazy loading nvm

Profiling with zprof

nvm is the culprit

Lazy loading nvm

Ater result

One thing to watch out for

Conclusion

Upgrade to Angular 20 from Angular 13 - Part 6: Angular 19 with Claude Code

1. Approach

2. Dependency upgrades

2.1 standalone: true removal

2.2 typescript-eslint v8 jump

2.3 browserTarget rename

3. Result

4. Source code

5. What I learned

6. What’s next

Fast terminal navigation for running multiple AI agents in Antigravity

Why Antigravity

Terminal navigation keybindings

1. Focus into the terminal

2. Open and close terminal tabs

3. Navigate between tabs

4. Navigate between panes within a tab

5. Resize and maximize

Upgrade to Angular 20 from Angular 13 - Part 5: Angular 18 with Claude Code

1. The approach

2. Phase 1: Dependency upgrades

2.1 The Quill v2 migration

3. Phase 2: NgModule cleanup

3.1 Replacing modules with route configs

3.2 Replacing AppRoutingModule with provideRouter

4. The result

5. Source code

6. The hidden gotcha: service providers

7. What I learned

8. What’s next

Upgrade to Angular 20 from Angular 13 - Part 4: Angular 17 with Claude Code

1. Approach

2.1 `standalone: true` removal

2.2 `typescript-eslint` v8 jump

2.3 `browserTarget` rename

2.3 Optional: `--dangerously-skip-permissions`

Instantiate errors using `new`

5.2.3 `_` prefix/suffix

6.2.2 Prefer optional over `|undefined`