DEV Community: Colum Ferry

Qwikify your Development with Nx

Colum Ferry — Tue, 15 Aug 2023 16:00:56 +0000

In the ever-evolving web development landscape, efficiency and modularity have become paramount. This is where Nx and Qwik come into play.

Qwik is a modern web framework that focuses on application performance by reducing the amount of JavaScript that needs to be shipped to the browser. You can learn more about how Qwik achieves this with Resumability here.

Nx is a powerful tool that helps you build extensible and maintainable codebases that scale as your application and team grows. Nx utilises computation cache and workspace analysis to ensure maximum efficiency and developer experience. You can learn more about Nx here.

In this blog post, we’ll explore how to combine the strengths of Nx and Qwik to create a todo app. To do this, we’ll take advantage of an Nx Plugin that was created by the Qwikifiers team to maximise the integration between Qwik and Nx, called qwik-nx.

You do not necessarily need to use an Nx Plugin for Qwik. Instead, you could use the Qwik CLI to create your application and add Nx later.
This blog post has decided to use theqwik-nx plugin to leverage better DX provided by the generators offered by the Plugin.

You can learn more about this integration in the video below:

Creating the Workspace

Let's start by setting up our development environment. We'll create an Nx workspace and integrate Qwik into it. Begin by generating an empty integrated workspace:

npx create-nx-workspace@latest qwik-todo-app

_You can also use the preset created by the qwik-nx plugin by running npx -y create-qwik-nx or npx -y create-nx-workspace@latest --preset=qwik-nx. This will skip a few of the next steps by installing the appropriate dependencies and generating your Qwik app.

The create-qwik-nx package is an example of creating an Install Package with Nx. You can learn more here: https://nx.dev/extending-nx/recipes/create-install-package_

Next, navigate into the workspace and install the qwik-nx plugin.

npm install --save-dev qwik-nx

You can view a compatibility matrix for which version of qwik-nx works with each version of nx here.

Generate the App

One of the benefits of using an Nx Plugin is that it comes with additional features such as automatic migrations, executors to act on your code and generators to scaffold code (like CodeMods).

Now, let’s use the application generator provided by qwik-nx to scaffold the todo application:

nx g qwik-nx:app todo

This will generate the starter project that Qwik itself provides in your Nx Workspace. It will also install all the necessary packages to build a Qwik application.

At this point, you can already run the nx serve todo and nx build todo commands to have a feel around of the application that was created.

Generate a new Route

Qwik has another package called Qwik City that uses directory-based routing to handle navigation within your application. You can learn more about directory-based routing with Qwik City here.

The qwik-nx plugin can help generate new routes within our application. Let’s use it to generate a route where we can store our todo logic.

nx g qwik-nx:route --name=todo --project=todo

After running this command, you’ll see a new directory and file created in your workspace:

The newly created file should look like this

import { component$ } from '@builder.io/qwik';

export default component$(() => {
  return <div>This is the todo</div>;
});

As you can see, it’s very simple, just a standard Qwik Component.

If you run nx serve todo and navigate to http://localhost:4200/todo you can see that the route works and the component renders the content correctly.

Build a Basic UI

We want to build a todo application, so let’s add some UI elements to make this look more like an actual todo application.

Update apps/todo/src/routes/todo/index.tsx to match the following:

import {component$} from '@builder.io/qwik';
import {Form} from "@builder.io/qwik-city";

export default component$(() => {
  return <div>
    <h1>Todos</h1>
    <div>
      <label>
        <input type="checkbox"/> {"My First Todo"}
      </label>
    </div>
    <Form>
      <input type="hidden" name="id" value={1}/>
      <input type="text" name="message"/>
      <button type="submit">Add</button>
    </Form>
  </div>;
});

You’ll see the page update and look like the following

Awesome!

However, you’ll notice that when you click Add, nothing happens! Let’s add some logic to store new todos.

Generate a Library

Nx helps you organise your workspace in a modular fashion by creating workspace libraries that focus on specific functionality.

Instead of organising your features into subfolders of your application, with Nx, you’ll extract them into workspace libraries (libraries that are not intended to be published, but still used by other libraries and applications in your repository). This helps to create a much stronger boundary between modules and features in your application as libraries have a public API (the index.ts file), allowing you to control exactly what can be accessed by consumers.

You can learn more about defining and ensuring project boundaries here.

Also, by doing this, you start to build out a project graph for your workspace and your application. Defining your architecture in this manner also helps to reduce the areas in your application that each change affects.

You can learn more about the Project Graph here.

Using this feature of Nx, we can organise the state management of our todo application into its own library, separating the logic from the application itself.

Let’s generate a new library with the help of qwik-nx.

nx g qwik-nx:lib data-access

We do not need some of the files that were automatically generated so we can delete them:

libs/data-access/src/lib/data-access.tsx
libs/data-access/src/lib/data-access.css
libs/data-access/src/lib/data-access.spec.tsx

Add a Qwik Context

Qwik uses Contexts to help store state across both the server-side and client-side and across routes within the application.

We’ll use a Context to store the todos in the application, but first, let’s create a file to store the TS Interfaces we’ll use in our application.

Create libs/data-access/src/lib/api.ts and add the following:

export interface Todo {
  id: number;
  message: string;
}

Next, let’s create a new file libs/data-access/src/lib/todo.context.tsx and add the following content:

import {
  component$,
  createContextId,
  Slot,
  useContextProvider,
  useStore,
} from '@builder.io/qwik';
import { Todo } from './api';

interface TodoStore {
  todos: Todo[];
  lastId: number;
}
export const TodoContext = createContextId<TodoStore>('todo.context');

export const TodoContextProvider = component$(() => {
  const todoStore = useStore<TodoStore>({
    todos: [],
    lastId: 0,
  });

  useContextProvider(TodoContext, todoStore);

  return <Slot />;
});

This will create our Context and set up a Store within our application to store the todos. Qwik takes advantage of signals to update state and inform the framework of which components need to be re-rendered when the state changes.

You can learn more about how Qwik uses Signals here.

Finally, let’s update the public entry point to the library to expose our Context and Interface.

Using the Context

Let’s update the root page to add our Context Provider. Open apps/todo/src/root.tsx and add TodoContextProvider after QwikCityProvider in the component tree. Your file should look like the following:

import { component$, useStyles$ } from '@builder.io/qwik';
import {
  QwikCityProvider,
  RouterOutlet,
  ServiceWorkerRegister,
} from '@builder.io/qwik-city';
import { RouterHead } from './components/router-head/router-head';

import globalStyles from './global.css?inline';
import { TodoContextProvider } from '@qwik-todo-app/data-access';

export default component$(() => {
  /**
   * The root of a QwikCity site always start with the <QwikCityProvider> component,
   * immediately followed by the document's <head> and <body>.
   *
   * Don't remove the `<head>` and `<body>` elements.
   */
  useStyles$(globalStyles);

  return (
    <QwikCityProvider>
      <TodoContextProvider>
        <head>
          <meta charSet="utf-8" />
          <link rel="manifest" href="/manifest.json" />
          <RouterHead />
        </head>
        <body lang="en">
          <RouterOutlet />
          <ServiceWorkerRegister />
        </body>
      </TodoContextProvider>
    </QwikCityProvider>
  );
});

Update libs/data-access/src/index.ts to match the following:

export * from './lib/todo.context';
export * from './lib/api';

Now that our Context is in place, let’s use it in our todo route to manage our todos.

Update apps/todo/src/routes/todo/index.tsx to match the following:

import {component$} from '@builder.io/qwik';
import {Form} from "@builder.io/qwik-city";
import {TodoContext} from "@qwik-todo-app/data-access";

export default component$(() => {
  const todoStore = useContext(TodoContext);

  return <div>
    <h1>Todos</h1>
    {todoStore.todos.map((t) => (
        <div key={`todo-${t.id}`}>
          <label>
            <input type="checkbox" /> {t.message}
          </label>
        </div>
      ))}
    <Form>
      <input type="hidden" name="id" value={1}/>
      <input type="text" name="message"/>
      <button type="submit">Add</button>
    </Form>
  </div>;
});

Our store has no todos in it when the application starts up, so if you serve the application you will no longer see any todos listed. Let’s fix that!

Adding a `routeLoader$` to load data on Navigation

Qwik allows you to fetch data when a route is navigated to, allowing you to fetch data before the page is rendered. The data will be fetched on the server before the component is rendered and downloaded to the client.

You can learn more about routeLoader$ here

It does this by providing a function called routeLoader$. We’ll use this function to preload our store with some todos that will theoretically exist in a database.

For this blog post, we’ll create an in-memory db to store some initial todos.

We’ll start by updating our libs/data-access/src/lib/api.ts to add our in-memory DB.

export interface Todo {
  id: number;
  message: string;
}

interface DB {
  store: Record<string, any[]>;
  get: (storeName: string) => any[];
  set: (storeName: string, value: any[]) => boolean;
  add: (storeName: string, value: any) => boolean;
}
export const db: DB = {
  store: { todos: [] },
  get(storeName) {
    return db.store[storeName];
  },
  set(storeName, value) {
    try {
      db.store[storeName] = value;
      return true;
    } catch (e) {
      return false;
    }
  },
  add(storeName, value) {
    try {
      db.store[storeName].push(value);
      return true;
    } catch (e) {
      return false;
    }
  },
};

Now that we have this, let’s use it in our /todo route to load some data when the user navigates to /todo.

Update apps/todo/src/routes/todo/index.tsx to match the following:

import {component$} from '@builder.io/qwik';
import {Form, routeLoader$} from "@builder.io/qwik-city";
import {TodoContext, db} from "@qwik-todo-app/data-access";

export const useGetTodos = routeLoader$(() => {
  // A network request or db connection could be made here to fetch persisted todos
  // For illustrative purposes, we're going to seed a rudimentary in-memory DB if it hasn't been already
  // Then return the value from it
  if (db.get('todos')?.length === 0) {
    db.set('todos', [
      {
        id: 1,
        message: 'First todo',
      },
    ]);
  }
  const todos: Todo[] = db.get('todos');
  const lastId = [...todos].sort((a, b) => b.id - a.id)[0].id;
  return { todos, lastId };
});

export default component$(() => {
  const todoStore = useContext(TodoContext);
  const persistedTodos = useGetTodos();

 useTask$(({ track }) => {
    track(() => persistedTodos.value);
    if (persistedTodos.value) {
      todoStore.todos = persistedTodos.value.todos;
      todoStore.lastId =
        todoStore.lastId > persistedTodos.value.lastId
          ? todoStore.lastId
          : persistedTodos.value.lastId;
    }
  });

  return <div>
    <h1>Todos</h1>
    {todoStore.todos.map((t) => (
        <div key={`todo-${t.id}`}>
          <label>
            <input type="checkbox" /> {t.message}
          </label>
        </div>
      ))}
    <Form>
      <input type="hidden" name="id" value={1}/>
      <input type="text" name="message"/>
      <button type="submit">Add</button>
    </Form>
  </div>;
});

When you serve the application, you’ll see the first todo is fetched and rendered correctly!

Handle the Form Action to add todos

Qwik also allows you to handle form actions on the server using the routeAction$ API. Let’s create the logic to add new todos to the store.

You can learn more about routeAction$ here.

Update apps/todo/src/routes/todo/index.tsx

import {component$} from '@builder.io/qwik';
import {Form, routeLoader$} from "@builder.io/qwik-city";
import {TodoContext, db} from "@qwik-todo-app/data-access";

export const useGetTodos = routeLoader$(() => {
  // A network request or db connection could be made here to fetch persisted todos
  // For illustrative purposes, we're going to seed a rudimentary in-memory DB if it hasn't been already
  // Then return the value from it
  if (db.get('todos')?.length === 0) {
    db.set('todos', [
      {
        id: 1,
        message: 'First todo',
      },
    ]);
  }
  const todos: Todo[] = db.get('todos');
  const lastId = [...todos].sort((a, b) => b.id - a.id)[0].id;
  return { todos, lastId };
});

export const useAddTodo = routeAction$(
  (todo: {id: string, message: string}) => {
    const success = db.add('todos', {
      id: parseInt(todo.id),
      message: todo.message,
    });
    return { success };
  },
  zod$({ id: z.string(), message: z.string() })
);

export default component$(() => {
  const todoStore = useContext(TodoContext);
  const persistedTodos = useGetTodos();
  const addTodoAction = useAddTodo();


 useTask$(({ track }) => {
    track(() => persistedTodos.value);
    if (persistedTodos.value) {
      todoStore.todos = persistedTodos.value.todos;
      todoStore.lastId =
        todoStore.lastId > persistedTodos.value.lastId
          ? todoStore.lastId
          : persistedTodos.value.lastId;
    }
  });

  return <div>
    <h1>Todos</h1>
    {todoStore.todos.map((t) => (
        <div key={`todo-${t.id}`}>
          <label>
            <input type="checkbox" /> {t.message}
          </label>
        </div>
      ))}
    <Form action={addTodoAction}>
      <input type="hidden" name="id" value={todoStore.lastId + 1} />
      <input type="text" name="message"/>
      <button type="submit">Add</button>
    </Form>
    {addTodoAction.value?.success && <p>Todo added!</p>}
  </div>;
});

Awesome! We can now add todos to our application!

However, you might have noticed that our file is starting to get very long. Not only that there’s a lot of logic in the route file itself. Let’s use Nx to separate the logic into the library we created earlier to keep logic collocated.

Improve the Architecture

To separate the logic, create a new file libs/data-access/src/lib/todos.ts and move the logic for loading and adding todos into their own functions:

import { db, Todo } from './api';

export function getTodos() {
  // A network request or db connection could be made here to fetch persisted todos
  // For illustrative purposes, we're going to seed a rudimentary in-memory DB if it hasn't been already
  // Then return the value from it
  if (db.get('todos')?.length === 0) {
    db.set('todos', [
      {
        id: 1,
        message: 'First todo',
      },
    ]);
  }
  const todos: Todo[] = db.get('todos');
  const lastId = [...todos].sort((a, b) => b.id - a.id)[0].id;
  return { todos, lastId };
}

export function addTodo(todo: { id: string; message: string }) {
  const success = db.add('todos', {
    id: parseInt(todo.id),
    message: todo.message,
  });
  return { success };
}

Next, update libs/data-access/src/index.ts

export * from './lib/todo.context';
export * from './lib/api';
export * from './lib/todo';

Finally, let’s update apps/todo/src/routes/todo/index.tsx to use our newly created functions:

import { component$, useContext, useTask$ } from '@builder.io/qwik';
import {
  Form,
  routeAction$,
  routeLoader$,
  z,
  zod$,
} from '@builder.io/qwik-city';
import { addTodo, getTodos, TodoContext } from '@acme/data-access';

export const useGetTodos = routeLoader$(() => getTodos());

export const useAddTodo = routeAction$(
  (todo) => addTodo(todo),
  zod$({ id: z.string(), message: z.string() })
);

export default component$(() => {
  const todoStore = useContext(TodoContext);
  const persistedTodos = useGetTodos();
  const addTodoAction = useAddTodo();

  useTask$(({ track }) => {
    track(() => persistedTodos.value);
    if (persistedTodos.value) {
      todoStore.todos = persistedTodos.value.todos;
      todoStore.lastId =
        todoStore.lastId > persistedTodos.value.lastId
          ? todoStore.lastId
          : persistedTodos.value.lastId;
    }
  });

  return (
    <div>
      <h1>Todos</h1>
      {todoStore.todos.map((t) => (
        <div key={`todo-${t.id}`}>
          <label>
            <input type="checkbox" /> {t.message}
          </label>
        </div>
      ))}
      <Form action={addTodoAction}>
        <input type="hidden" name="id" value={todoStore.lastId + 1} />
        <input type="text" name="message" />
        <button type="submit">Add</button>
      </Form>
      {addTodoAction.value?.success && <p>Todo added!</p>}
    </div>
  );
});

If you run nx serve todo again, you’ll notice that our refactor will not have changed anything for the user, but it has made the codebase more manageable!

Now, if we need to update the logic for loading or adding todos, we only need to retest the library, and not the full application, improving our CI times!

Conclusion

The collaboration between Nx and Qwik has led us to create a todo app that showcases efficient development practices and modular design. By centralizing route logic in a library, we've not only demonstrated the capabilities of Nx and Qwik but also highlighted how this approach can significantly improve cache and CI times.

This journey through Qwik and Nx demonstrates how thoughtful architecture and the right tools can significantly enhance your development experience. So go ahead, Qwikify your development and build amazing web applications with ease!

Learn More

Also, if you liked this, click the 👏and make sure to follow Colum and Nx on X (formerly Twitter) for more!

Using NgRx Standalone APIs with Nx

Colum Ferry — Tue, 21 Feb 2023 14:47:25 +0000

Version 15 of NgRx introduced Standalone APIs to the package, enabling usage of the NgRx with Standalone Component-based Angular applications. This allows for a simpler integration of NgRx to your application.

Nx has added support for using these Standalone APIs from NgRx when generating NgRx stores with our @nrwl/angular:ngrx generator when you give it a path to a Routes definition file. (Usually denoted by *.routes.ts)

In this article, we’ll walk through using Nx to create a new Standalone Component-based Angular application and add NgRx to it, using ONLY Nx Generators!

If you prefer a video, we have one!

Create a new Nx Workspace

npx create-nx-workspace myorg

Select:
Standalone Angular app
Yes to using Standalone Components
Yes to add routing
Any option for the stylesheet format
Yes to Nx Cloud

The result should look something like this:

Now run cd myorg to enter the workspace.

The src/main.ts should look different than you remember with standard NgModule-based Angular applications.

You should see something similar to

import { bootstrapApplication } from '@angular/platform-browser';
import {
  provideRouter,
  withEnabledBlockingInitialNavigation,
} from '@angular/router';
import { AppComponent } from './app/app.component';
import { appRoutes } from './app/app.routes';

bootstrapApplication(AppComponent, {
  providers: [provideRouter(appRoutes, withEnabledBlockingInitialNavigation())],
}).catch((err) => console.error(err));

This is important, as this is the file where your root NgRx providers need to be placed, within the providers option of the bootstrapApplication function.

Nx will aid this also!

Generate the root state

nx g @nrwl/angular:ngrx --root --parent=src/main.ts

You’ll be asked for a name for the feature state, but you can ignore this and simply press enter in your terminal, it is not necessary at this stage.

Say false to Facades also.

The generator will now make changes to your main.ts file and install the NgRx packages for you!

Your main.ts file should now look like this

import { bootstrapApplication } from '@angular/platform-browser';
import {
  provideRouter,
  withEnabledBlockingInitialNavigation,
} from '@angular/router';
import { AppComponent } from './app/app.component';
import { appRoutes } from './app/app.routes';
import { provideStore, provideState } from '@ngrx/store';
import { provideEffects } from '@ngrx/effects';

bootstrapApplication(AppComponent, {
  providers: [
    provideEffects(),
    provideStore(),
    provideRouter(appRoutes, withEnabledBlockingInitialNavigation()),
  ],
}).catch((err) => console.error(err));

Notice the addition of provideEffects() and provideStore() to the providers array.

Generate a new feature library

NgRx works better when you split your store based on the features you have within your application. This is a pretty common use case. Nx allows you to do this very easily and in a very structured way.

First, let’s generate a new feature library, called feature-users, in Nx that will house everything related to our feature including the NgRx State.

nx g @nrwl/angular:lib feature-users --standalone --routing --lazy --parent=src/app/app.routes.ts

This command does a few things:

It creates a new library in our Nx Workspace
It uses an Angular Standalone Component as the entrypoint
It adds a routing configuration to the library and adds the component as the default route.
It will add a lazy-loaded route to the application’s app.routes.ts file, wiring up the application to the library!

Some files you may want to explore in your own time are:

src/app/app.routes.ts
feature-users/src/lib/lib.routes.ts

Add feature state to the feature library

Now that we have a feature library for our users feature, let’s generate the feature state! It’s as simple as one command.

nx g @nrwl/angular:ngrx users --parent=feature-users/src/lib/lib.routes.ts --route=''

You’ll be asked if this is the root state of the application, enter N. Then say no to Facades (unless you really want them).

The --route option here is used to dictate what route within our routes definition file (lib.routes.ts) should have the state attached to it. This is to allow the NgRx Standalone APIs to be attached to that route.

We can see that if we look at the lib.routes.ts file

import { Route } from '@angular/router';
import { FeatureUsersComponent } from './feature-users/feature-users.component';
import { provideStore, provideState } from '@ngrx/store';
import { provideEffects } from '@ngrx/effects';
import * as fromUsers from './+state/users.reducer';
import { UsersEffects } from './+state/users.effects';

export const featureUsersRoutes: Route[] = [
  {
    path: '',
    component: FeatureUsersComponent,
    providers: [
      provideState(fromUsers.USERS_FEATURE_KEY, fromUsers.usersReducer),
      provideEffects(UsersEffects),
    ],
  },
];

The command will also have generated our

Actions	Reducers
Selectors	Effects

And with that, we now have NgRx installed and integrated into our application!

If you’d like to confirm the integration, you can run the following commands and see successful outputs!

nx build

nx test

nx test feature-users

Conclusion

This guide has shown how easy it is to set up NgRx with Nx and how to take advantage of the latest Standalone APIs with your application. All with just 5 Nx commands!

With the Angular roadmap pointing to Standalone Components becoming the preferred option for developing Angular applications, this support will be crucial in the future, and Nx will help you achieve it with the best possible DX!

You can checkout an example repository that was created following the steps above here: https://github.com/Coly010/nx-ngrx-standalone

Learn More

🧠 Nx Docs
👩‍💻 Nx GitHub
💬 Nrwl Community Slack
📹 Nrwl Youtube Channel
🥚 Free Egghead course
🧐 Need help with Angular, React, Monorepos, Lerna or Nx? Talk to us 😃

Also, if you liked this, click the 👏 and make sure to follow Colum and Nx on Twitter for more!

Setting up Module Federation with Server-Side Rendering for Angular

Colum Ferry — Wed, 11 Jan 2023 16:23:18 +0000

Module Federation is a technology provided by webpack that enables modules to be federated across different origins at runtime. This means that Webpack will simply ignore these modules at build time, expecting them to be available to be fetched across the network at runtime.

This technology has enabled a much cleaner approach to Micro Frontend Architecture but also is employable as a strategy to implement incremental builds for large applications, reducing overall build times. This can lead to faster feedback cycles and less money spent on CI workflows.

Nx offers great out-of-the-box support and developer experience for Module Federation for Angular and React. You can learn more about it from the resources below:

📄 Module Federation Recipes on Nx
📺 Speed up your Angular serve and build times with Module Federation and Nx

However, until now, it has only supported Client-Side Rendering (CSR). Essentially it worked only for Single Page Applications (SPAs). While this is still valuable, it is becoming ever more apparent that Server-Side Rendering (SSR) is becoming the de-facto standard for building web applications, due to the multitude of benefits it provides.

(What is server-side rendering: definition, benefits and risks).

Since version 15.4, Nx now offers Module Federation with support for SSR! 🎉

Now we can get both, the benefits of Module Federation and SSR in our Nx Workspaces!

How it works

A traditional SSR application is rendered on the server. It receives the requested route from the browser, Angular evaluates that route, and the server generates the HTML and sends it back to the browser.

With Module Federation and SSR, it takes that concept and the concept of MF to allow portions of the app to be run on their own server. The host server will receive the route and if it’s a route pointing to a remote, it will ask the remote to process the route, then send the rendered HTML to the browser.

This gives us full power of SSR but also still allowing us to break our build into multiple smaller builds. It also means that we could redeploy the remote server with new changes without having to redeploy the host server, allowing for independent deployability of features within the overall application.

Example

Let’s walk through how to set this up with Nx for Angular. We will generate a host application (dashboard) and a remote application (login).

npx create-nx-workspace@latest myorg

You’ll be prompted for the type of workspace you want to create, and the preset to use.

Answer with the following:

✔ Choose what to create · integrated
✔ What to create in the new workspace · apps
✔ Enable distributed caching to make your CI faster · No

You will also be prompted whether to add Nx Cloud to your workspace. We won’t address this in this article, but it is highly recommended to use this along with Module Federation to allow for the cache of your remote applications to be shared amongst teammates and CI, further improving your build times. You can learn more about Nx Cloud here: https://nx.app.

When your workspace is created, run cd myorg.

Next, we will need to install the Official Nx Angular Plugin:

npm install @nrwl/angular

Once this is installed, we only need one command to scaffold out our full Module Federation with SSR architecture:

npx nx g host dashboard --remotes=login --ssr

We will see in the terminal that this generates a bunch of files. What it actually creates is:
Two applications with Angular Universal (SSR)
Webpack Configuration for Browser and Server with Module Federation

We can serve our dashboard (host) application, along with our login (remote) application, by simply running the command:

npx nx serve-ssr dashboard

This will build the browser and server bundles of our login application, then run the login using node.
The login application will be run without any file watchers, meaning that if you make a change to the code for the login application, it will not be reflected automatically. More on this later.

Note: Nx will cache the build of the browser and server bundles for the login application. If you were to run the command again, it would simply use the cache rather than actually rebuilding the application! 🔥.

Once this is complete, it will then build and run the server for the dashboard application, with file watchers, allowing it to pick up changes to the code.

You should see a success message like this in the terminal:

Compiled successfully.
** Angular Universal Live Development Server is listening on http://localhost:4200, open your browser on http://localhost:4200 **

Let’s open a new tab in our browser, and open Network tab in the DevTools. After this, navigate to http://localhost:4200. You should see the following:

The most interesting piece here is the first entry in the network log. Let’s look at it more closely:

We can see that the server returned the fully rendered HTML for the page!

Angular Universal will switch to CSR after the initial page load, which means if we were to click on the login link, it would use CSR to render that page. The Angular Module that is resolved and rendered still lives on the remote server, but Module Federation will still resolve this correctly! 🔥

But to see where the real magic happens, let’s manually navigate the browser to http://localhost:4200/login. You should see that in the Network tab, the fully rendered HTML for the login page has been returned!

Despite the code for that page living on a different, remote, server, the host server composed it correctly and was still able to return the correct HTML for that route, thanks to Module Federation!

And that’s it! It’s super simple to get Module Federation and SSR up and running with Nx!

Serving the login application and watching for changes

If you’re working on the login application, and are iteratively checking the results of your changes, you’ll want the server to rebuild when you make your change. You can easily enable that by using the devRemotes flag::

npx nx serve-ssr dashboard --devRemotes=login

Learn More

🧠 Nx Docs
👩‍💻 Nx GitHub
💬 Nrwl Community Slack
📹 Nrwl Youtube Channel
🥚 Free Egghead course
🧐 Need help with Angular, React, Monorepos, Lerna or Nx? Talk to us 😃

Also, if you liked this, click the 👏 and make sure to follow Colum and Nx on Twitter for more!

Component-First Architecture with Standalone Components and Nx

Colum Ferry — Thu, 03 Nov 2022 12:59:49 +0000

When Angular 2 released its first pre-release versions, it had no concept of NgModule. We attached Components as Directives to Components that needed them.

import { Component } from ‘@angular/core’;
import { ButtonComponent } from ‘./button.component’;

@Component({
   …,
   directives: [ButtonComponent]
})
export class HomeComponent {}

But it all changed in Angular 2-rc.5. This version saw the introduction of NgModules. The additional metadata was required for the compiler and to help accurately create injection hierarchies for the dependency injection system.
This completely changed how Angular apps were architectured and designed. It also added a level of complexity to building Angular apps and another concept new Angular developers had to learn and understand.

Optional NgModules soon became the top feature request on the Angular repository.

Introducing Standalone Components

In the past year, the Angular Team tackled this and the solution is Standalone Components. Released under the Developer Preview label during the last few iterations of Angular 14, they’ll be officially marked stable now in Angular 15.

Standalone Components offer a much simpler approach to application development and better fit the current trend of frontend development that focuses on the composition of components.

Let’s take a look at some of the differences now that we have Standalone Components.

Creating Components

Creating components in Angular originally required that we create a Component and declare it in an existing or new NgModule. With Standalone Components, we now just set the standalone: true property in the Component Decorator metadata and we no longer need to declare it in an NgModule.

If the Standalone Component requires Components, Pipes or Directives that are exported from an existing NgModule or Standalone Component, Pipe or Directive, then we just need to use the new imports: [] property on the Component Decorator metadata to import them. You can see an example of the changes below:

Using Standalone Components

As mentioned above, Standalone Components can directly import other Standalone Components to allow using them in your template. If you need to maintain some level of interoperability between NgModules and Standalone Components, Standalone Components can also be imported to NgModules.

Routing

With NgModules becoming optional, there needed to be a new method to route through our applications without having to make use of RouterModule.forRoot() and RouterModule.forChild().

The Angular Team has created some Standalone APIs that provide this functionality without having to use the NgModule equivalents. The provideRouter API replaces the RouterModule.forRoot(). They have also enabled lazy-loading of routes constants, meaning we can directly reference other exported route declarations, rather than only NgModules.

Testing

Testing with Standalone Components becomes much easier. We no longer need to configure TestBed to include all the NgModules that our component requires to function because the Component itself already imports them. The only additional configuration you may find yourself doing with TestBed will be to set up Mocks and Spies.

Bootstrapping an Application

Previously, bootstrapping an application involved two distinct efforts:
Telling Angular which NgModule to bootstrap
Stating which Component the NgModule should bootstrap

The NgModule used to bootstrap (usually AppModule) would also include all root-level providers and NgModules that implemented .forRoot.

With Standalone Components, there is a new function, bootstrapApplication, which replicates this functionality, but allows you to tell it the Standalone Component to bootstrap, along with all root-level providers. For example, this is where we would add provideRouter.

It’s already becoming obvious that building our Angular applications solely with the Standalone Components, Pipes, Directives and APIs is much much simpler and more straightforward than working with NgModules. However, NgModules provided a clear concept of how to architect our applications with patterns such as CoreModules, SharedModules and FeatureModules.

This leaves a gap for similar patterns to be utilized when using Standalone Components.

What is Component-First Architecture?

Component-First Architecture is a pattern for architecting our applications to fill the void left by the patterns that sprung up around NgModules. It also has a core concept.

The concept that your application is entirely controlled by your components

Component-First architecture is composed of four main pillars.

Standalone Components and declarables
Reduced Provider Indirection
Dedicated Routes File / Component
Component-led State Management

Standalone Components and Declarables

Applications should be a composition of Standalone Components, Pipes and Directives

Standalone Declarables import exactly what they need to operate. From this, the reasoning of how they work becomes much more straightforward. Testing becomes easier as there is less setup to do on the testing side. Debugging becomes much easier and we can see everything impacting the Component, Pipe or Directive just by looking at its decorator metadata.

I also believe dev tools in general could become much smarter. All our files will have direct TS Imports to the other files they depend on. With this information, we could build an architecture graph that could help find circular dependencies as well as enabling Nx affected-like incremental building of our applications.

Reduced Provider Indirection

Services that can be used globally should use `providedIn: ‘root’ while component-specific services should be provided directly in that component’s decorator metadata.

This again feeds into the idea that we can see instantly just from looking at the decorator metadata exactly what is required, which makes it much easier to reason about our application as a whole and can help prevent issues relating to the dependency injection hierarchy that could cause multiple instances of services that we expect to be singletons.

Dedicated Routes File

There should be a dedicated *.routes.ts file for each feature / domain as the entrypoint

By having a dedicated routes file as the entry point to our features, we can reimplement the FeatureModule pattern we’ve grown accustomed to with NgModules while having the added benefit of being able to easily identify where our routing configuration is throughout our application. We can use this to also build a map of routing throughout our application.

Component-led State Management

Our components should lead how we manage the state within our application. Use global stores for shared state, otherwise offload component and feature-related state to our components.

Using a tool like NgRx Component Store, each component can then manage its own state using reactive methods. This leads to less indirection about where state is managed for the Component. It is provided to the Component directly and therefore continues to fill the philosophy that we should know everything about our component simply by looking at its decorator metadata. All children of the component can access it and therefore allows a child -> parent -> child data flow.

Even with NgRx Component Store, global state management can still be achieved, allowing us to set up dedicated stores for shared state within our application. All we have to do is add providedIn: ‘root’ to the service for the store and then we can inject it into any Component or Service / Component Store that requires it.

Finally, feature-level stores can also be created. As Component Stores are provided as a service, if we create a Component Store for a full feature and inject it to the entry component of a feature, all children of that feature can access the store and interact with it.

Example Directory Structure

Following this pattern we would end up with a folder structure where it’s easy to identify features, routing configuration and where state is managed throughout our application.

How can Nx help?

Nx offers three core elements that can greatly aid in following this architecture pattern.

Generators - to help us easily scaffold code following the guidelines.
Standalone Component Support - at a much higher level than is currently offered by the Angular CLI.
Workspace Libraries - to help us split features by domain into separate libraries that offer a public API exporting only our entry points.

The generators offered by Nx allow us to not only generate applications and libraries that are setup to use Standalone Components, they also allow us to automatically attach routing configurations for new libraries to existing Routes Files.

Below is a list of commands that will scaffold our architecture and automatically wire up our routing configurations.

You can see a video of some of this in action here: https://www.youtube.com/watch?v=e-BpE9d3NIw

Conclusion

Standalone Components offer a much better DX than NgModule applications but there was initially a gap in how we should architect our applications with just Standalone Components. This article has talked through one approach that should make it easy and straightforward to continue building Angular applications in a way that we are familiar with and which builds on the greater DX of Standalone Components.

Learn More

🧠 Nx Docs
👩‍💻 Nx GitHub
💬 Nrwl Community Slack
📹 Nrwl Youtube Channel
🥚 Free Egghead course
🧐 Need help with Angular, React, Monorepos, Lerna or Nx? Talk to us 😃

Also, if you liked this, click the 👏 and make sure to follow Colum and Nx on Twitter for more!

Generating Standalone Component-based Angular Applications and Libraries with Nx

Colum Ferry — Fri, 30 Sep 2022 14:31:02 +0000

Angular recently released Standalone Components in an effort to address one of their highest voted community issues; to make NgModule optional.
This was of course met with great excitement from the community, and it offers a much simpler approach to the development of Angular applications.

Prefer a video version? We’ve got you covered! Check out our video on this here https://youtu.be/e-BpE9d3NIw

Originally with Angular, we would bootstrap an AppModule that declared an AppComponent and this would be seen to be the root of our application. This was achieved by calling the bootstrapModule function in the src/main.ts file. However, as the goal was to make NgModule optional, Angular needed to create a method of bootstrapping a Standalone Component. Therefore, they created the bootstrapApplication function that allows for a Standalone Component to be bootstrapped, as well as allowing top-level providers such as Routing to be initialized from the src/main.ts file.

Despite now having an approach for building Angular applications with no NgModules, the Angular CLI does not yet provide a schematic to generate this for us automatically. It currently still defaults to the NgModule-based approach to application development.

With Standalone Components offering a potentially much improved developer experience, we felt it made sense to allow Standalone Component-based applications and libraries to be generated from a single command, filling the void in the Angular CLI. So we updated our @nrwl/angular plugin to do just that!

This article will walk through how to set up an Nx Workspace with the @nrwl/angular plugin preinstalled, and then how to use the generators the plugin offers to scaffold Standalone Component-based applications and libraries from the CLI. It will also cover how to automatically wire routing between the application and lazy-loaded feature libraries.

Note: I have renamed the concept of "Feature Modules" to "Feature Libraries" as the former term no longer makes sense in a Standalone Component world.

Initial Setup

First, create a new Nx Workspace by running the following command:

npx create-nx-workspace@latest myorg --preset=angular --appName=app1 --style=css

You'll be prompted for some additional options, you can answer them how you please.

The command will create a new directory for us named myorg. So we'll want to ensure we are working in that directory by running:

cd myorg

The first command will have done the following:

Created our Nx Workspace
Installed the @nrwl/angular plugin and its required dependencies
Created an initial application named app1

The application it created will be following the NgModule approach, so we can safely ignore it.

Generating a Standalone Component-base Application

However, we really want to check out a Standalone Component-based application, so lets go ahead and generate one!

npx nx g @nrwl/angular:app myapp --standalone --routing

This command will generate our application and also configure an initial routing setup for us. You'll notice immediately that there was no app.module.ts file created.

If we look at apps/myapp/src/app/app.component.ts, we'll see the following

import { NxWelcomeComponent } from './nx-welcome.component';
import { RouterModule } from '@angular/router';
import { Component } from '@angular/core';

@Component({
  standalone: true,
  imports: [NxWelcomeComponent, RouterModule],
  selector: 'myorg-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css'],
})
export class AppComponent {
  title = 'myapp';
}

There are two main things to call out here, so let's take a look at them.

@Component({
    standalone: true,
    ...
})

We can see a new boolean standalone: true added to the decorator metadata. This tells Angular and its compiler that this Component is a Standalone Component and therefore does not be declared in an NgModule to be used.

@Component({
    imports: [NxWelcomeComponent, RouterModule],
    ...
})

An imports property is also set in the decorator metadata, and it allows us to import Standalone Components and NgModules that our Component requires to be compiled and function correctly. We can now use directives, services, pipes etc. that would be exported by NgModules in our component, without our component requiring a parent NgModule. This provides interoperability between NgModules and Standalone Components which is incredibly useful while we still have NgModules around, either from the official Angular packages or from third-party packages.

If we run npx nx serve myapp and navigate to localhost:4200 we can see that the application functions exactly the same as with an NgModule-based app.

I mentioned previously that the src/main.ts file also changes to support Standalone Components. It's worth taking a look at it to see the differences, but we generate what is required automatically for you anyway!

Generating a Standalone Component Feature Library

Angular developers will be familiar with the concept of Feature Modules, however, as we are not using NgModules this term doesn't quite make sense. Nx has always had the concept of Workspace Libraries, where an application can be split into domain libraries that are consumed directly by the application and do not need to be published.

By combining both of these concepts, we can create the term "Feature Library" which allows us the same benefits of Feature Modules but with Standalone Components.

In Nx, we can generate a library for our feature, have it create an initial Standalone Component and allow it to be routed to, eagerly or lazily, by the application.

This will make more sense after we generate a library which can be done by running the following command

npx nx g @nrwl/angular:library mylib --standalone --routing

You'll see that this command creates a Standalone Component named mylib as well as a routes.ts file. If we take a closer look at routes.ts, we'll see that it is just a standard Route[] configuration and that it gets exported from index.ts.

import { Route } from '@angular/router';
import { MylibComponent } from './mylib/mylib.component';

export const MYLIB_ROUTES: Route[] = [{ path: '', component: MylibComponent }];

Angular realised that by making NgModule optional, they needed a better method to handle routing that by having to use RouterModule.forChild() and their answer was to allow loadChildren to point directly to the exported Route[] configuration.

We can edit apps/myapp/src/main.ts to add a route to our new feature library:

import { enableProdMode, importProvidersFrom } from '@angular/core';
import { bootstrapApplication } from '@angular/platform-browser';
import { RouterModule } from '@angular/router';
import { AppComponent } from './app/app.component';
import { environment } from './environments/environment';

if (environment.production) {
  enableProdMode();
}

bootstrapApplication(AppComponent, {
  providers: [
    importProvidersFrom(
      RouterModule.forRoot([
          { 
              path: 'mylib', 
              loadChildren: () => import('@myorg/mylib').then(m => m.MYLIB_ROUTES) 
          }
      ], { initialNavigation: 'enabledBlocking' })
    ),
  ],
}).catch((err) => console.error(err));

You can see above that we just point directly to the exported const MYLIB_ROUTES in our route. By running npx nx serve myapp and navigating to http://localhost:4200/mylib you can see at the bottom that the Standalone Component has been rendered correctly!

But we can do more

The @nrwl/angular:library generator also offers support for automatically wiring the route to your Feature Library to your application, all from the one command. Let's generate a new library to see this in action.

npx nx g @nrwl/angular:library dashboard --standalone --routing --lazy --parent=apps/myapp/src/main.ts

This command will

generate our dashboard library with a Standalone Component
configure routing for the library
attach to the route to myapp

If we take a look at apps/myapp/src/main.ts again, we can see our new route was added automatically!

import { enableProdMode, importProvidersFrom } from '@angular/core';
import { bootstrapApplication } from '@angular/platform-browser';
import { RouterModule } from '@angular/router';
import { AppComponent } from './app/app.component';
import { environment } from './environments/environment';

if (environment.production) {
  enableProdMode();
}

bootstrapApplication(AppComponent, {
  providers: [
    importProvidersFrom(
      RouterModule.forRoot(
        [
          {
            path: 'dashboard',
            loadChildren: () =>
              import('@myorg/dashboard').then((m) => m.DASHBOARD_ROUTES),
          },
          {
            path: 'mylib',
            loadChildren: () =>
              import('@myorg/mylib').then((m) => m.MYLIB_ROUTES),
          },
        ],
        { initialNavigation: 'enabledBlocking' }
      )
    ),
  ],
}).catch((err) => console.error(err));

Conclusion

Standalone Components offers a much better DX than NgModule based approach to Angular application development and Nx aims to make it as straightforward and as simple as possible to adopt!

Learn More

🧠 Nx Docs
👩‍💻 Nx GitHub
💬 Nrwl Community Slack
📹 Nrwl Youtube Channel
🥚 Free Egghead course
🧐 Need help with Angular, React, Monorepos, Lerna or Nx? Talk to us 😃

Also, if you liked this, click the 👏 and make sure to follow Colum and Nx on Twitter for more!

Setup Module Federation in Angular using Nx

Colum Ferry — Tue, 12 Jul 2022 17:17:01 +0000

As our Angular applications grow, building the application takes longer and longer. This means we sometimes spend more time waiting on the application to build than actually writing code. This becomes even more frustrating when we take into consideration that we usually only need to focus on one specific part of the full monolithic application.

At this point, we usually look to split the monolithic application into smaller subsections.

The idea of Micro Frontends lends itself well to achieving this, but we do not need to use Micro Frontends to achieve it. Instead, the technology behind modern Micro Frontend solutions is where the real power is at.

You can learn more about this concept here.

Webpack 5 introduced the Module Federation Plugin which has rapidly become the go-to solution for splitting large monolithic applications into smaller composable pieces.

In this article, we'll walk through how Nx makes it extremely straightforward to set up Module Federation for an Angular application, both from scratch and also for converting an existing Angular application into multiple composable slices.

Convert an existing monolithic application

Let's say we have a single Angular application in an Nx Workspace with the following architecture:

If you are not already using Nx, and want to take advantage of this, consider migrating to Nx first. You can find out more about that here

We can see that, despite being a single application, there are already some clearly defined domains (or slices) within our application. This model of definable domains matches most typical application designs.

However, developers in your organization are complaining that they are waiting an ever-increasing length of time for their builds and serves to complete. They're also frustrated because they only need to target one area of the overall application and don't care necessarily about the domains they aren't interested in.

The agreed solution is that every domain in the application will become its own application owned by a feature team, and they'll all be composed in the host application. This results in an architecture like this:

To achieve this in an Nx Workspace, it is as simple as running the following command:

npx nx g @nrwl/angular:setup-mf ourapp --mfType=host

This will set up Webpack's Module Federation Plugin for the application and configure it as a host application, ready to consume remote applications.

The command above did the following:

Adds a module-federation.config.js file containing the necessary configuration for Module Federation
Adds a webpack.config.js and webpack.prod.config.js which uses the config from module-federation.config.js and the withModuleFederation to configure the underlying webpack config to use Module Federation.
Changes the build and serve target to use @nrwl/angular:webpack-browser and @nrwl/angular:module-federation-dev-server respectively, which allow for custom webpack configs to be passed to the underlying Angular builder

Now, we'll want to create remote applications for each domain. Nx has a generator to help us do it, and it even lets us tell it the name of the host application so that it can do some automatic wiring and routing configuration.

npx nx g @nrwl/angular:remote featureA --host=ourapp
npx nx g @nrwl/angular:remote featureB --host=ourapp
npx nx g @nrwl/angular:remote featureC --host=ourapp

For each of the domains, this generator did the following:

Creates a new Angular application in the workspace specific for the feature.
Adds a module-federation.config.js file containing the necessary configuration for Module Federation.
Adds a webpack.config.js and webpack.prod.config.js which uses the config from module-federation.config.js and the withModuleFederation to configure the underlying webpack config to use Module Federation.
Changes the build and serve target to use @nrwl/angular:webpack-browser and @nrwl/angular:webpack-server respectively, which allow for custom webpack configs to be passed to the underlying Angular builder.
Adds a new serve-static target which uses @nrwl/angular:file-server executor to serve the previously built files as though on a web-server.
Updates the Host application's module-federation.config.js to point to the remote application.
Updates the Host application's app.module.ts to set up a Route for the remote application.

Within each of our remote applications, we'll want to wire up the RemoteEntryModule to use the feature modules that had existed in the monolith. At this time, we'll also want to remove them from ourapp. This means that ourapp no longer needs to build them!

As you have probably deduced already, instead of one application that needs to build everything, we now have four applications that only need to build the code that they are interested in.

However, serving our new architecture is exactly the same! We just need to run

npx nx serve ourapp

This does behave slightly differently from our usual Angular serve. That is because by default when we try to serve our host, Nx will only serve the static files for each of the remote applications (unless told to do otherwise, more on that later).

So, let's say we're actively working on featureB, then we would simply run:

npx nx serve ourapp --devRemotes=featureB

This will use webpack-dev-server to serve the host application (ourapp) and the remote application (featureB). This will be all set up with live reloading etc. The other remote applications (featureA, featureC) will still be served, but just as static files!

This introduces an incredible benefit to our developer experience. Now, instead of having webpack build and serve everything in the application, we only build and serve what we actually want, which is usually only one domain (or slice) of the application. Yet, we maintain the usual experience of navigating through our application as though everything was served!

There's no additional overhead of rebuilding them because they will be fetched from cache! And, if you have Nx Cloud turned on, you may never have to build domains you are not working in, because someone else in your team, or the CI machine itself, will have already built those remote applications, and you'll get to take advantage of the distributed cache!!

You can now continue developing as normal, but everything will just be a lot faster, and you'll have Module Federation set up in your Workspace, which puts you in a good position to then take it further and truly go down the Micro Frontend route if that is your desire.

Setting up new workspaces for Module Federation

If you do not have an existing application that you're splitting out into multiple slices, but rather you have a new application and you wish to take advantage of the Module Federation architecture, Nx can help you quickly scaffold out the host application as well as all the remotes you need with one command:

npx nx g @nrwl/angular:host shell --remotes=featureA,featureB,featureC

Running this command will do the following:

Create the host application named Shell
Create three remote applications for each feature listed
Wire up the remote applications to the host application

Now you can run nx serve shell and it'll build and serve the full architecture!

Conclusion

As you can see, Nx makes it super straightforward to set up Module Federation for new and existing applications!!

We would love for you to try it out and let us know what you think!

Also, make sure you don’t miss anything by

Following us on Twitter, and
Subscribe to the YouTube Channel for more information on Angular, React, Nx, and more!
Subscribing to our newsletter!

As always, if you are looking for enterprise consulting, training and support, you can find out more about how we work with our clients here.

Jumpstart your Angular 14 development with Storybook, Tailwind and Nx

Colum Ferry — Tue, 28 Jun 2022 15:32:54 +0000

With Angular 14 having just released recently, let us discuss how you can take advantage of some of the most popular tools in the JavaScript ecosystem to increase your efficiency and productivity when building Angular applications.

In this article, we will setup an Nx workspace that is preconfigured for Angular development, and integrate Storybook and Tailwind using generators provided by Nx. We will then build a simple Button component using only Storybook and Tailwind.

Workspace Setup

First, let’s start by creating a new Nx Workspace that contains the official Angular plugin. It’s as simple as running a single command:

npx create-nx-workspace@latest demo --preset=angular

We will then be prompted to answer questions about what we’re creating.
Give the application a name of myapp and then select the default answers for the rest of the prompts.

This will create our workspace and install the dependencies required to build Angular applications! Ensure you're at the root of the new workspace by running cd demo.

We want to build a component that will be shared among many applications, so let’s create a Shared Components library to store it. This allows us to add more components in the future and keep them scoped to a shared domain. Run the following command

npx nx g @nrwl/angular:lib shared/components

This will create a workspace library with a name of shared-components but with a directory structure of shared/components.

This can be beneficial for domain driven development and is a good architectural pattern to follow when working within an Nx Workspace.

Add Storybook

Now, let’s add Storybook to our workspace, and more importantly, to our shared-components library. This is as simple as running the following command:

npx nx g storybook-configuration shared-components

Say No to all the prompts that are asked in the terminal.

This will install Storybook, create the necessary Storybook configuration files and add two targets to the shared-components project.json file, enabling us to run Storybook for the library.

Add Tailwind

Next, we want to add Tailwind support to our workspace. Again, Nx offers a command to do this for us! Just run:

npx nx g setup-tailwind myapp

This will add the Tailwind directives to our styles.css file in apps/myapp/src/style.css and create a tailwind.config.js file for our application.

However, Storybook will not be aware of Tailwind for our shared-components library. To allow this, we need to do the following:

Add apps/myapp/src/styles.css to styles array of build-storybook
Copy and Paste tailwind.config.js from myapp to libs/shared/components.

Note: We need to copy and paste the tailwind.config.js file from the application for our UI Library to allow Storybook to find the Tailwind classes correctly.
This is not the most scalable solution to this problem as there will be a duplication of configuration across all the libraries in the workspace. Changing the root configuration will not edit all the other libraries’ configurations.
You can find a better approach to solving this problem in Leosvel’s blog post: https://leosvel.dev/blog/set-up-tailwind-css-with-angular-in-an-nx-workspace/#sharing-the-tailwind-css-configuration-between-the-application-and-the-buildable-library

And that's it! We're now ready to start building components independently of our application using Storybook!

Let's build a Button component

The first thing we want to do is generate a component to store our button. We'll take advantage of the SCAM pattern and use Nx's SCAM generator. Run the following command:

npx nx g @nrwl/angular:scam button --inlineTemplate --inlineStyle --export --project=shared-components

This will generate an NgModule, a Component and use inline template and inline styles (also following the Single File Component pattern) within our shared-components library and export it to be consumed by other libraries or applications.

A new file should be generated at libs/shared/components/src/lib/button/button.component.ts with the following contents:

import { Component, OnInit, NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'demo-button',
  template: ` <p>button works!</p> `,
  styles: [],
})
export class ButtonComponent implements OnInit {
  constructor() {}

  ngOnInit(): void {}
}

@NgModule({
  imports: [CommonModule],
  declarations: [ButtonComponent],
  exports: [ButtonComponent],
})
export class ButtonComponentModule {}

It's a pretty straightforward component! Let's edit the template slightly to:

Use Tailwind for styling
Allow content projection

Replace the contents of template: with:

<button
   class="
      inline-flex
      items-center
      justify-center
      px-5
      py-5
      border
      border-transparent
      text-base
      font-medium
      rounded-md
      text-white
      bg-indigo-600
      hover:bg-indigo-700
      "
>
  <ng-content></ng-content>
</button>

Now, we can automatically generate a Storybook story for this component, allowing us to see and design this component independently from consuming applications. We can do this by running the following command:

npx nx g @nrwl/angular:stories shared-components --generateCypressSpecs=false

This will create a new file libs/shared/components/src/lib/button/button.component.stories.ts with a Storybook story automatically created!

Next, if you run npx nx storybook shared-components, you can see in the terminal that Storybook will run and create an instance on http://localhost:4400/. If you navigate to that URL, you will see Storybook is running correctly!

Our button doesn't have any text because it uses content projection. We can solve this by making a few quick edits to our story.

We'll set up a "Harness" component, that will be scoped to just the story and is used to host and render our actual ButtonComponent. This pattern allows us to set up a Storybook Control that will allow us to easily change the text that is rendered within the button!

Replace the contents of libs/shared/components/src/lib/button/button.component.stories.ts with

import { moduleMetadata, Story, Meta } from '@storybook/angular';
import { Component, Input } from '@angular/core';
import { ButtonComponent } from './button.component';

@Component({
  selector: 'demo-button-harness',
  template: '<demo-button>{{ text }}</demo-button>'
})
class ButtonHarnessComponent {
    @Input() text = 'Button';
}

export default {
  title: 'ButtonComponent',
  component: ButtonHarnessComponent,
  decorators: [
    moduleMetadata({
      imports: [],
      declarations: [ButtonComponent]
    })
  ],
} as Meta<ButtonHarnessComponent>;

const Template: Story<ButtonHarnessComponent> = (args: ButtonHarnessComponent) => ({
  props: args,
});


export const Primary = Template.bind({});
Primary.args = {
    text: 'Button'
}

You should then see the following in Storybook:

And that's it! How easy is that!?

Nx truly helps you to hit the ground running with Angular development thanks to all of it's one-command integrations!

Recap

With Nx, we were able to create a workspace with a structure that allows for a better separation of domains.
1. npx create-nx-workspace@latest demo --preset=angular
Nx also offered us commands to easily integrate modern tooling allowing us to develop rapidly.
1. npx nx g storybook-configuration
2. npx nx g setup-tailwind
Nx offered some commands to help us scaffold out code making us even more productive, while sticking to consistent structures and patterns.
1. npx nx g @nrwl/angular:lib
2. npx nx g @nrwl/angular:scam
Finally, Nx reuses a CLI API we are familiar with to interact with our app and libraries
1. npx nx storybook shared-components

Migrating to Nx

Do you already have an Angular application using the Angular CLI and want to take advantage of all the cool tooling that Nx offers? Don't worry! The Nx CLI offers a single command that will automatically migrate most Angular workspaces to use Nx.

It has been recently refactored to support multi-project workspaces as well as some known standard deviations from Angular's opinionated workspace scaffolding.

You can use the command below in your Angular Workspace to kick off the migration.

ng add @nrwl/angular

Note: You need to ensure you use the correct command based on the version of Angular your workspace is using. The easiest way would be to ensure your Angular workspace is at the latest Angular version and then run the command!

Otherwise, you can read more about migrating to Nx here, including the command to run based on your version of Angular: https://nx.dev/migration/migration-angular

Conclusion

Hopefully you can see just how easy it can be to integrate tooling and build out applications and component libraries using modern tooling such as Storybook and Tailwind with Nx!

We would love for you to try it out and let us know what you think!

Also, make sure you don’t miss anything by

Following us on Twitter, and
Subscribe to the YouTube Channel for more information on Angular, React, Nx, and more!
Subscribing to our newsletter!
As always, if you are looking for enterprise consulting, training and support, you can find out more about how we work with our clients here.

Angular CLI and Nx - Why?

Colum Ferry — Wed, 22 Jun 2022 12:07:45 +0000

In this blog, I’ll present a comparison of both the Angular CLI and the Nx CLI and present some evaluations on the current state of each.

What is Nx?

One of the more powerful additions to Angular 2+ was when the Angular CLI was introduced. This dramatically lowered the entry barrier for newcomers, allowing them to focus on learning Angular instead of having to deal with the underlying tooling setup. Also, features like code generation as well as automated code migrations (ng update) help during the development and the maintenance of the project.

When Nrwl founders Jeff Cross and Victor Savkin left the Angular Team at Google they saw the huge potential of such developer tooling, but with the aim to improve it with a particular focus on the needs of the community and companies outside of Google. Nx was heavily inspired by the Angular CLI and is now years later a fully standalone, widely adopted, and quickly growing build system with almost 2 million downloads per week. The Nx core team closely collaborates with the Angular team as well as with other teams on Jest, Cypress, Storybook, ESLint, and more, effectively serving as an integrative part with a mission to deliver the best possible integration between the various tools.

When Angular CLI users try out Nx they immediately feel at home due to the familiarity of the commands, but also get to experience the increased power and particularly the focus on modern community tooling. Let's explore more.

The Current State of Affairs

Angular CLI

In recent releases, the Angular CLI kept reducing its feature set, mainly due to tools such as Protractor as well as TSLint being deprecated. As a result, starting with Angular 14, the Angular CLI provides the following when generating a new application:

Angular application
Unit testing solution with Karma
(note, linting doesn't come out of the box, however, when trying to run the lint command it can be set up automatically for you)

Nx CLI

Nx, on the other hand, generates an Angular workspace with the following setup:

Angular Application
Jest for Unit Testing
Cypress for E2E Testing
ESLint for Linting
Prettier for improving code style consistency and readability

But it offers even more tooling integrations via generators:

Storybook
NgRx
Tailwind
Micro Frontend Support
Module Federation Support
Standalone Component-based Applications and Libraries Support

Command Comparison

Everything you’re used to running with the Angular CLI will still work in the Nx CLI.
As a quick reference, here is a list of commands provided by the Angular CLI and their counterparts in the Nx CLI.

Angular CLI	Nx CLI
ng build app1	nx build app1
ng serve app1	nx serve app1
ng test app1	nx test app1
ng lint app1	nx lint app1
ng upgrade	nx migrate

Feature Comparison

The Nx CLI can do everything the Angular CLI can do, and more. Let’s take a look at a more comprehensive feature comparison between the two CLIs.

	Angular CLI	Nx CLI
Code Generation	Yes	Yes
Caching	Cache of build	Cache of build, lint, test (and others!)
Migrations	Yes	Yes
Out-of-box Unit Testing	Yes	Yes
Out-of-box Linting	No*	Yes
Out-of-box E2E Testing	No	Yes
Micro Frontend Support	No	Yes
Publishable Libraries	Yes	Yes
Remote Caching	None	Yes

* It’s worth noting that if you run ng lint in a new project, the command will ask if you want to install ESLint. You can then lint your project. However, it does not have a linting setup provided out of the box.

Code Generation

Both CLIs offer built-in code schematics/generators to help scaffold code quickly. However, Nx provides all the schematics that Angular provides as well as additional generators to help improve your developer experience even further.

We have generators to integrate tools such as

Tailwind - nx g setup-tailwind <projectName>
Storybook - nx g storybook-configuration <projectName>
NgRx - nx g ngrx <storeName> --project=<projectName>

As well as generators to help you scaffold out

Micro Frontends - nx g host shell & nx g remote remoteApp
Single Component Angular Modules (SCAMs) - nx g scam myscam
- Standalone Component-based applications - nx g app --standalone
- Standalone Component-based libraries - nx g library --standalone
Web Workers - nx g web-worker <workerName> --project=<projectName>

Caching

Angular's caching solution is built on top of Webpack's incremental build cache. This helps speed up rebuilds as the cache is persisted onto disk. Nx doesn't change that. It leverages Angular's builder but in addition, also adds Nx's own computation cache on top.

See the graphic below where we compare the result of getting a cache hit on the Angular CLI with the result of getting a cache hit on the Nx CLI.

The initial webpack build with Angular CLI takes ~12s, the following cache hit build takes ~4s.
The initial webpack build with Nx CLI takes ~10s, the following cache hit build takes ~14ms.

Being tied to Webpack, Angular's cache is just local to your workstation and only for builds. Nx instead is able to cache any custom operation you specify, including your builds, lint, and tests. In addition, you have the ability to split your project into smaller consumable units, that can also be tested and linted. This means we can take advantage of parallelization to run tests and lints in parallel and take better advantage of the cache of any projects that have not changed! All of this results in faster CI times and a better local developer experience.

By integrating with Nx Cloud you also get the opportunity to

distribute the cache remotely such that other co-workers, as well as your CI system, can leverage it to speed up operations
automatically distribute your task execution across multiple agents on CI

Migrations

Angular has always been committed to ensuring evergreen development. It introduced the concept of automatically upgrading your workspace and running code migrations to reduce the chance of running into breaking changes between versions. This can be done using the ng update command. Once the command is run, Angular will install the new versions of packages and run any code migrations that will be required.

Nx is also committed to providing the same experience, however, it is a little bit more nuanced about it. The nx migrate command should be used in two steps. The first run of nx migrate will update the dependencies versions in the package.json file and also generate a file named migrations.json. However, it will not automatically install the new packages or run the code migrations. You can do this by running nx migrate --run-migrations.

The reason behind this comes from what we have learned from working with large multi-team organizations. Some automatic code migrations will generate a lot of changes and this can become difficult to review in a subsequent PR. It can be even more difficult for reviewers if there are multiple different code migrations within a single PR.

By creating a migrations.json file that contains each of the migrations to be run, we can be more selective with the migrations we run, meaning we can create multiple PRs to focus on each migration, allowing for incremental updates and the ability re-run migrations.

This can also be helpful when we have teams that have long-lived feature branches and we need to reduce the impact of changes and risk of merge conflicts and it also allows these teams to re-run migrations on their own branches.

You can read more about our approach to updating and migrations here: https://nx.dev/using-nx/updating-nx or watch this Egghead video on leveraging Nx migrations.

Configuration

The Angular CLI and Nx CLI uses a very similar approach to configuration to manage your projects and workspaces.

The Angular CLI uses a root angular.json file that contains the configuration of all projects in the workspace. This configuration is used to dictate how the project should be built and tested. Other tools may also configure how they should work within this configuration file.

The Nx CLI will place an angular.json configuration file at the root of your workspace which points to individual project.json files for each of the projects in your workspace. Each of these project.json files follows a similar structure to projects within Angular’s angular.json, except scoped to just one project.

This configuration splitting is extremely useful as it allows configuration to live beside the project it targets, making it much easier to find and reason about, as well as preventing large git merge conflicts when multiple teams have added new projects in their feature branches.

There is a very slight naming difference between some of the properties in both configuration files. You can see a mapping of those in the table below.

Angular CLI	Nx CLI
architect	targets
builder	executor
schematics	generator

Despite that, Nx contains a compatibility layer between itself and the Angular Devkit, allowing for Angular CLI configuration and Angular Schematics to work correctly, even when used in an Nx Workspace!

Architecture

A typical Angular Workspace consists of an application at the root of the workspace and then allows for the development of additional applications and libraries under a folder named projects.
While this can allow for the splitting of large applications into smaller manageable chunks, the tooling to manage this architecture is not provided by the Angular CLI.

Nx, on the other hand, embraces this separation of applications and libraries, encouraging the concept that an application is a composition of small, focused chunks (or libraries). This lends itself well to a Domain-driven architecture. Nx allows better separation of applications themselves into an apps folder and libraries into a libs folder. By breaking down our applications into these smaller, domain-focused libraries, Nx can increase the number of cacheable units within your workspace to dramatically increase developer experience and reduce testing and lint times.

Using an ESLint rule provided by Nx, we can also enforce some rules around what libraries can be used by other libraries and applications.
You can read more about that here: https://blog.nrwl.io/mastering-the-project-boundaries-in-nx-f095852f5bf4

Extensibility

The Angular CLI can be extended with schematics and builders that aim to allow library authors to provide opinionated code generation and different approaches to executing code in the workspace. An example of this would be ngx-build-plus which allows for an additional webpack configuration to be taken into account when building the Angular application. However, the Angular CLI isn’t fully pluggable and the Angular Devkit, which utilizes RxJS, can be difficult to approach if you ever do find the need to offer schematics as part of your package.

The Nx CLI is fully pluggable and embraces the idea of Nx Plugins that can be used to enhance your development experience. Nx offers some official plugins, but it also has a large listing of community plugins (https://nx.dev/community#plugin-directory) that aim to provide support for many tools and integrations!

Nx Plugins can be built with the Nx Devkit, which uses Async Generators and provides many helper functions to make it super easy to build your own code generators and code executors.

Nx even understands the concept of local plugins, which allows you to build a plugin in the same workspace as your application. This provides the opportunity to create opinionated code generators for your full organization to maintain consistency in development practices across all teams working on the application.

You can read more about the Nx Devkit here: https://nx.dev/guides/nx-devkit-angular-devkit

Switching from the Angular CLI to the Nx CLI

Have you been convinced to try out the Nx CLI but already have an Angular application using the Angular CLI? Don’t worry! The Nx CLI offers a single command that will automatically migrate most Angular workspaces to use Nx. It has been recently refactored to support multi-project workspaces as well as some known standard deviations from Angular’s opinionated workspace scaffolding.

You can use the command below in your Angular Workspace to kick off the migration.

ng add @nrwl/angular

Otherwise, you can read more about migrating to Nx here, including the command to run based on your version of Angular: https://nx.dev/migration/migration-angular

Conclusion

Looking objectively across everything discussed within this post, it becomes clear that the Nx CLI offers everything that the Angular CLI does and then some. From more out-of-the-box tooling support to faster builds and more features, the Nx CLI dramatically improves your Angular development experience, while allowing you to reuse most of the knowledge you have gained from using the Angular CLI. And the large ecosystem of Nx Plugins means you can take advantage of all the features of Nx for more than just Angular applications if you need to!

Integrate the Remote apps with the Dashboard

Colum Ferry — Fri, 28 Jan 2022 09:28:11 +0000

This is the fourth and final article in a series of articles that aims to showcase the process of scaffolding and deploying a Micro Frontend Architecture using Nx and Netlify. We will build and deploy the remote applications. We’ll build a login app and a todo app and deploy each independently to Netlify.

You can view the code for this part here: https://github.com/Coly010/nx-mfe-netlify-series/tree/blog-part-four

Overview

In the previous articles, we scaffolded and deployed the Dashboard application, our host application, and built and deployed our Todo application and Login application, our remote applications.
The final step in our solution is to integrate the remote applications into the host application. When our host application loads, it’ll fetch code from the Todo application and the Login application via network requests, and load and use them correctly to compose a single system.

Integrate the Remote Applications

We’ll be using static Module Federation in this example to compose the Micro Frontends, however, it’s important to understand the limitations of this and why Dynamic Module Federation may be a better solution. You can read more about that here: https://www.angulararchitects.io/en/aktuelles/dynamic-module-federation-with-angular/

Set up Routing

We will use routing to route between our federated code. Our generators for scaffolding our remote applications has already done the heavy lifting for this. We can see this if we open apps/dashboard/src/app/app.module.ts. We can see the following routing configuration:

RouterModule.forRoot(
      [
        {
          path: 'todo',
          loadChildren: () =>
            import('todo/Module').then((m) => m.RemoteEntryModule),
        },
        {
          path: 'login',
          loadChildren: () =>
            import('login/Module').then((m) => m.RemoteEntryModule),
        },
      ],
      { initialNavigation: 'enabledBlocking' }
    ),

We already have routes set up to load the federated code with paths to each module. Let’s change it so that we try to redirect to the /todo route if the user has logged in. We can do this by:

Change the routes to be child routes
Adding a redirect route
Adding our AuthGuard as a CanActivate guard to /todo

When we do that our routing config should look like this:

RouterModule.forRoot(
      [
        {
          path: '',
          children: [
            {
              path: '',
              redirectTo: '/todo',
              pathMatch: 'full'
            },
            {
              path: 'todo',
              loadChildren: () =>
                import('todo/Module').then((m) => m.RemoteEntryModule),
              canActivate: [AuthGuard],
            },
            {
              path: 'login',
              loadChildren: () =>
                import('login/Module').then((m) => m.RemoteEntryModule),
            },
          ],
        },
      ],
      { initialNavigation: 'enabledBlocking' }
    ),

We just need to edit our app.component.html slightly now and then we can serve our MFE architecture and test it out!

<h1 style="text-align: center">MFE Architecture Series</h1>
<router-outlet></router-outlet>

As our Dashboard app is a host application, our generator creates a specific target that will let us serve the remote applications and the host application at once. This allows for quicker testing of our integration.

To do this, run yarn nx run dashboard:serve-mfe. Now if we navigate to https://localhost:4200, we’ll be presented with:

The Dashboard app tried to route to /todo but as we are not authenticated, it redirected us to /login. Both of these have been fetched via a network request from our other served apps.

We can verify this if we look at our Network Tab:

We requested the built components from our other served apps!
If we try to log in using the credentials:

Username: anything
Password: password

Nothing happens.

This is because our Micro Frontend architecture is currently rebundling our @mfe-netlfiy/shared/auth package into each app. Therefore, its state remains internal to each application that uses it. The applications are not sharing state. We can fix that by opening the webpack config for both our Dashboard and Login apps and adding @mfe-netlfiy/shared/auth to the shared mappings at the top of the file:

sharedMappings.register(
  tsConfigPath,
  [
    /* mapped paths to share */
    '@mfe-netlify/shared/auth',
  ],
  workspaceRootPath
);

Now, if we re-serve our apps by re-running yarn nx run dashboard:serve-mfe and follow the steps below to log in:

Username: anything
Password: password
Click login

We get redirected correctly to /todo and see the following:

Our Mirco Frontend Architecture is now sharing state across the apps! It’s all working locally!

Re-deploy to Netlify

Now we need to re-deploy it to Netlify. As we’ll be using static Module Federation, we need the deployed URLs of our remote applications as currently, it’s pointing to locally served apps. We can get these from Netlify.

Go to https://app.netlify.com.
Click on each remote application site
Take note of the URL for the site

In my case my URLs are:
Todo App: https://lucid-cray-c41a7f.netlify.app
Login App: https://wonderful-euclid-5a7ba0.netlify.app

We now need to update our Webpack config to point our apps to each of these URLs.

Open apps/dashboard/webpack.config.js and find the remotes: property. It should look similar to the following, except using your own deployed URLs.

remotes: {
        todo: 'https://lucid-cray-c41a7f.netlify.app/remoteEntry.js',
        login: 'https://wonderful-euclid-5a7ba0.netlify.app/remoteEntry.js',
      },

Now, to redeploy it, we simply need to make a git commit and push a commit to our remote repository. Netlify will pick up the change and automatically redeploy our apps!

git add .
git commit -m “feat: integrate remote apps to dashboard”
git push

Netlify will rebuild and redeploy our apps. If we go to the deployed Dashboard URL, it should work.

My deployed Dashboard URL is: https://trusting-wiles-249121.netlify.app/

Conclusion

With that, our Micro Frontend Architecture is complete! We built and deployed three apps and integrated two of them using Module Federation into a single system, deployed on Netlify.

Further Reading
Right now, anytime we push a commit to our repository, all apps are being redeployed. We can fix this to only deploy apps that are being affected by changes we’ve made.
We can use

Ignore Builds configuration in the netlify.toml. https://docs.netlify.com/configure-builds/file-based-configuration/#ignore-builds
Rares’ article on deploying Nx monorepos with Netlify https://www.netlify.com/blog/2020/04/21/deploying-nx-monorepos-to-netlify/

You can read more on Module Federation and Micro Frontends with Angular in Manfred Steyer’s articles series: https://www.angulararchitects.io/en/aktuelles/the-microfrontend-revolution-module-federation-in-webpack-5/

If you have enjoyed this series, check out the links below to stay informed of any future content!
Blog: https://blog.nrwl.io/
NxDevTools’ Twitter: https://twitter.com/NxDevTools
Nrwl’s Twitter: https://twitter.com/nrwl_io
Colum Ferry’s Twitter: https://twitter.com/FerryColum

Build and Deploy the Remote Applications to Netlify

Colum Ferry — Fri, 21 Jan 2022 12:07:11 +0000

This is the third article in a series of articles that aims to showcase the process of scaffolding and deploying a Micro Frontend Architecture using Nx and Netlify. We will build and deploy the remote applications. We’ll build a login app and a todo app and deploy each independently to Netlify.

Overview

In this article, we will build two applications that we will deploy separately to their own sites. We will configure them as Remote Micro Frontend Applications, exposing certain code via the Module Federation Plugin for webpack. This exposed code can then be consumed by our Dashboard application from the deployed location of the remote applications.

We will build a ToDo app, which will be non-functional and whose sole purpose is to be a placeholder to protect behind an authorization guard. It will contain a simple UI.

We will also build a Login app, which will provide a basic login form along with a shared auth lib containing a stateful service for managing the authed user.

Build ToDo App

Generate the app

Starting with the ToDo app, run the following command to generate the app with a Micro Frontend configuration.

yarn nx g @nrwl/angular:app todo --mfe --mfeType=remote --host=dashboard --port=4201 --routing=true

Let’s break down what is happening with this command.

It generates a standard Angular app with a routing configuration.
It adds an Angular Module that acts as a remote entry point for host applications.
It adds a webpack configuration exposing the Remote Entry Module to be consumed by Host applications.
It will add this application to the specified host application’s (dashboard) webpack configuration.
It adds this application to the host application’s serve-mfe target.
This target will serve all the remote applications along with the host application, launching your full Micro Frontend Architecture.
It changes the default serve port for the application to 4201.

Build the UI

Now we’ll build out the UI for the ToDo application. We’ll start by adding a route that will redirect automatically to the Remote Entry Module. This means that when we serve the ToDo app locally, we’ll see the Module that we’re working on for the MFE.

Open apps/todo/src/app/app.module.ts and find the RouterModule import in the NgModule. It should look like this:

RouterModule.forRoot([], { initialNavigation: 'enabledBlocking' }),

Edit it to match the following:

RouterModule.forRoot(
      [
        {
          path: '',
          loadChildren: () =>
            import('./remote-entry/entry.module').then(
              (m) => m.RemoteEntryModule
            ),
        },
      ],
      { initialNavigation: 'enabledBlocking' }
    ),

Next, we’ll edit the app.component.html file to only contain the RouterOutlet. Open the file and delete all the contents except for

<router-outlet></router-outlet>

If we serve our app using yarn nx serve todo and navigate to http://localhost:4201 we should see the following:

Our ToDo app has been configured correctly. Let’s edit the entry.component.ts file to show a very basic ToDo UI:

import { Component } from '@angular/core';

@Component({
  selector: 'mfe-netlify-todo-entry',
  template: `<div class="todo-list">
    <h1>Todo</h1>
    <div class="list">
      <label> <input type="checkbox" name="item" /> Item </label>
    </div>
  </div> `,
})
export class RemoteEntryComponent {}

When we save the file, webpack should rebuild the changes and our output should look like this:

That’s it. The UI for our ToDo app is complete.

Prepare for Netlify Deployment

We have one final step before we are ready to deploy the app. We need to add a netlify.toml file to the src/ folder of the ToDo app.
After creating the file, add the following to it:

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

[[headers]]
  # Define which paths this specific [[headers]] block will cover.
  for = "/*"

  [headers.values]
    Access-Control-Allow-Origin = "*"

To ensure, this file is copied correctly when the file is built, open up the project.json file for your ToDo app (apps/todo/project.json) and find the build option. It should look like this:

    "build": {
      "executor": "@nrwl/angular:webpack-browser",
      "outputs": ["{options.outputPath}"],
      "options": {
        "outputPath": "dist/apps/todo",
        "index": "apps/todo/src/index.html",
        "main": "apps/todo/src/main.ts",
        "polyfills": "apps/todo/src/polyfills.ts",
        "tsConfig": "apps/todo/tsconfig.app.json",
        "inlineStyleLanguage": "scss",
        "assets": [
          "apps/todo/src/favicon.ico",
          "apps/todo/src/assets"
        ],
        "styles": ["apps/todo/src/styles.scss"],
        "scripts": [],
        "customWebpackConfig": {
          "path": "apps/todo/webpack.config.js"
        }
      },

Add the netlify.toml file to the assets array so that it gets copied over in place. Your build config should look like this:

    "build": {
      "executor": "@nrwl/angular:webpack-browser",
      "outputs": ["{options.outputPath}"],
      "options": {
        "outputPath": "dist/apps/todo",
        "index": "apps/todo/src/index.html",
        "main": "apps/todo/src/main.ts",
        "polyfills": "apps/todo/src/polyfills.ts",
        "tsConfig": "apps/todo/tsconfig.app.json",
        "inlineStyleLanguage": "scss",
        "assets": [
          "apps/todo/src/favicon.ico",
          "apps/todo/src/assets",
          "apps/todo/src/netlify.toml"
        ],
        "styles": ["apps/todo/src/styles.scss"],
        "scripts": [],
        "customWebpackConfig": {
          "path": "apps/todo/webpack.config.js"
        }
      },

Let’s commit our changes and push to our remote repo:

git add .
git commit -m “feat: build the todo application”
git push

Now the application is ready to be deployed to Netlify!

Deploy the ToDo App

Let’s deploy our ToDo app to Netlify. Go to https://app.netlify.com.
You’ll be greeted with a screen similar to this, if you are logged in:

To set up our ToDo site, follow the steps below:
You can see a gif of this here

Click on Add new site
Click on GitHub when it prompts to Connect to Git provider.
Select your repository
Modify the Build command and Publish directory
- Build command should be yarn build todo
- Publish directory should be dist/apps/todo
Click Deploy site

Netlify will then import your repository and run the build command. After the build completes, Netlify will take the built files and deploy them to a newly generated domain. You can find this domain in the Info card on the Netlify Site. Clicking on the URL will take you to your deployed application.

With that, our ToDo app is complete!

Build the Login App

Moving on to the Login app. Here, we will build a few things:
A Shared Auth Library that can be used by any app or library in our Micro Frontend Architecture.
A Login library that will contain a login form and use the Auth library to set the authenticated user state.
The Login app, which will use the Login library to render the login form.

Scaffold the Application and Libraries

We’ll start by scaffolding the app and the libraries we’ll need:

yarn nx g @nrwl/angular:app login --mfe --mfeType=remote --host=dashboard --port=4202 --routing=true
yarn nx g @nrwl/angular:lib feat-login 
yarn nx g @nrwl/angular:lib shared/auth

Add Shared Auth Logic

Now that we have our libraries ready, let’s flesh out the logic for the shared auth library. We’re going to want two things:

A service that will log the user in and contain some state about the authed user
A route guard that can be used to check if there is an authenticated user

We can use generators to scaffold these out also! Run the following commands to do so:

yarn nx g @nrwl/angular:service auth --project=shared-auth
yarn nx g @nrwl/angular:guard auth --project=shared-auth --implements=CanActivate

These two commands have added four files to our shared/auth library:

libs/shared/auth/src/lib/auth.service.ts
libs/shared/auth/src/lib/auth.service.spec.ts
libs/shared/auth/src/lib/auth.guard.ts
libs/shared/auth/src/lib/auth.guard.spec.ts

For convenience, we’ll ignore the test files.
We’ll start with the auth.service.ts file. Open the file and replace its contents with the following:

import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs';

@Injectable({
  providedIn: 'root',
})
export class AuthService {
  private _activeUser = new BehaviorSubject<{ username: string } | undefined>(
    undefined
  );

  activeUser = this._activeUser.asObservable();

  login({ username, password }: { username: string; password: string }) {
    if (password === 'password') {
      this._activeUser.next({ username });
      return true;
    }
    return false;
  }
}

In this file, we’re doing the following:

Creating a BehaviorSubject to store some state relating to our User
Exposing an observable that can be used to read the current state of the User
Exposing a very trustworthy method to log the User in and set the state

Next, we’ll build the Auth Guard logic to prevent unwanted routing to protected routes. Open auth.guard.ts and replace the contents with the following:

import { Injectable } from '@angular/core';
import { CanActivate, Router, UrlTree } from '@angular/router';
import { map, tap, Observable } from 'rxjs';
import { AuthService } from './auth.service';

@Injectable({
  providedIn: 'root',
})
export class AuthGuard implements CanActivate {
  constructor(private authService: AuthService, private router: Router) {}

  canActivate():
    | Observable<boolean | UrlTree>
    | Promise<boolean | UrlTree>
    | boolean
    | UrlTree {
    return this.authService.activeUser.pipe(
      map((activeUser) => Boolean(activeUser)),
      tap((isLoggedIn) => {
        if (!isLoggedIn) {
          this.router.navigateByUrl('login');
        }
      })
    );
  }
}

In this file, we use the Auth Service we created to read the state of the authed user, map it to a boolean value that will be used as the result of the guard. We also create a side-effect that will force navigation to the login route if the user is not authenticated.

Finally, we need to expose both the guard and the service as exports from the library to allow them to be consumed by other libraries and applications. Open libs/shared/auth/src/index.ts and replace the contents with:

export * from './lib/auth.guard';
export * from './lib/auth.service';

With that, our shared auth library is ready to be used!

Build the Login form

Now that we have the shared auth library completed, we can focus on building the login form. We already generated the login feature (feat-login) library. This approach is an architectural practice promoted by Nrwl to help structure your monorepo logically. You can read more about that here: https://go.nrwl.io/angular-enterprise-monorepo-patterns-new-book

We need a component for our login form, so let’s generate one:

yarn nx g @nrwl/angular:component login --project=feat-login

First, open libs/feat-login/src/lib/feat-login.module.ts and add LoginComponent to the exports of the NgModule and ReactiveFormsModule to the imports array:

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { ReactiveFormsModule } from '@angular/forms';
import { LoginComponent } from './login/login.component';

@NgModule({
  imports: [CommonModule, ReactiveFormsModule],
  declarations: [LoginComponent],
  exports: [LoginComponent],
})
export class FeatLoginModule {}

This allows consuming libraries and apps to import the module and use the component easily.

Next, we’ll build the login form itself.
Open login.component.ts and replace it with the following:

import { Component } from '@angular/core';
import { FormControl, FormGroup, Validators } from '@angular/forms';
import { Router } from '@angular/router';
import { AuthService } from '@mfe-netlify/shared/auth';

@Component({
  selector: 'mfe-netlify-login',
  templateUrl: './login.component.html',
  styleUrls: ['./login.component.css'],
})
export class LoginComponent {
  loginForm = new FormGroup({
    username: new FormControl('', [Validators.required]),
    password: new FormControl('', [Validators.required]),
  });

  constructor(private authService: AuthService, private router: Router) {}

  login() {
    const username = this.loginForm.get('username')?.value;
    const password = this.loginForm.get('password')?.value;
    const loggedIn = this.authService.login({ username, password });

    if (loggedIn) {
      this.router.navigateByUrl('/');
    }
  }
}

With this component, we create a FormGroup that will be used to collect user input. It also has a method for handling the submission of the login form that will use our Auth Service to authenticate the user, and route us back to the root of the application, where we should now see the previously protected content.

With the logic taken care of, let’s flesh out the UI.
Open login.component.html and replace it with:

<div class="login-form">
  <form [formGroup]="loginForm" (ngSubmit)="login()">
    <input
      type="text"
      name="username"
      placeholder="username"
      formControlName="username"
    />
    <input
      type="password"
      name="password"
      placeholder="password"
      formControlName="password"
    />
    <button type="submit">Login</button>
  </form>
</div>

Finally, let’s add some CSS so it looks pretty. Open login.component.scss and add:

.login-form {
  padding: 1.5em;
  display: flex;
  flex-direction: column;
  align-items: center;
}
form {
  display: flex;
  flex-direction: column;
  align-items: center;
}
input {
  margin: 0.5em 0;
  padding: 0.5em;
  border: 1px solid grey;
  border-radius: 4px;
}
button {
  padding: 1em;
  appearance: none;
  border: 1px solid rgb(99, 99, 214);
  background-color: rgb(47, 72, 143);
  border-radius: 4px;
  text-transform: uppercase;
  color: white;
  cursor: pointer;
}

button:active {
  background-color: rgb(86, 106, 160);
}

With that, the login form should be ready to be used!

Integrate the Login form to the Login app

With the login form completed, it’s time to use it in the login application we generated earlier. Following similar steps as the ToDo application, let’s set up the routing to point to the Remote Entry Module.

Open apps/login/src/app/app.module.ts and find the RouterModule import in the NgModule. It should look like this:

RouterModule.forRoot([], { initialNavigation: 'enabledBlocking' }),

Edit it to match the following:

RouterModule.forRoot(
      [
        {
          path: '',
          loadChildren: () =>
            import('./remote-entry/entry.module').then(
              (m) => m.RemoteEntryModule
            ),
        },
      ],
      { initialNavigation: 'enabledBlocking' }
    ),

Next, we’ll edit the app.component.html file to only contain the RouterOutlet. Open the file and delete all the contents except for

<router-outlet></router-outlet>

Now, let’s edit the Remote Entry component to use our login form. First we need to import it to the Remote Entry Module, so let’s open entry.module.ts and replace it with:

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { RouterModule } from '@angular/router';

import { RemoteEntryComponent } from './entry.component';
import { FeatLoginModule } from '@mfe-netlify/feat-login';

@NgModule({
  declarations: [RemoteEntryComponent],
  imports: [
    FeatLoginModule,
    CommonModule,
    RouterModule.forChild([
      {
        path: '',
        component: RemoteEntryComponent,
      },
    ]),
  ],
  providers: [],
})
export class RemoteEntryModule {}

Now, let’s edit the RemoteEntryComponent to render our Login form. Open entry.component.html and replace it with:

import { Component } from '@angular/core';

@Component({
  selector: 'mfe-netlify-login-entry',
  template: `<mfe-netlify-login></mfe-netlify-login>`,
})
export class RemoteEntryComponent {}

Our Login app should be ready!
If we run yarn nx serve login and navigate to http://localhost:4202 we should see the following:

Awesome! We just need to add our netlify.toml file and we should be ready to deploy our Login app to Netlify! We’ll follow the same steps we used to create the file for the ToDo app.

Prepare for Netlify Deployment

We need to add the netlify.toml file to the src/ folder of the Login app.
After creating the file, add the following to it:

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

[[headers]]
  # Define which paths this specific [[headers]] block will cover.
  for = "/*"

  [headers.values]
    Access-Control-Allow-Origin = "*"

To ensure, this file is copied correctly when the file is built, open up the project.json file for your Login app (apps/login/project.json) and find the build option. It should look like this:

    "build": {
      "executor": "@nrwl/angular:webpack-browser",
      "outputs": ["{options.outputPath}"],
      "options": {
        "outputPath": "dist/apps/login",
        "index": "apps/login/src/index.html",
        "main": "apps/login/src/main.ts",
        "polyfills": "apps/login/src/polyfills.ts",
        "tsConfig": "apps/login/tsconfig.app.json",
        "inlineStyleLanguage": "scss",
        "assets": [
          "apps/login/src/favicon.ico",
          "apps/login/src/assets"
        ],
        "styles": ["apps/login/src/styles.scss"],
        "scripts": [],
        "customWebpackConfig": {
          "path": "apps/login/webpack.config.js"
        }
      },

Add the netlify.toml file to the assets array so that it gets copied over in place. Your build config should look like this:

    "build": {
      "executor": "@nrwl/angular:webpack-browser",
      "outputs": ["{options.outputPath}"],
      "options": {
        "outputPath": "dist/login/todo",
        "index": "apps/login/src/index.html",
        "main": "apps/login/src/main.ts",
        "polyfills": "apps/login/src/polyfills.ts",
        "tsConfig": "apps/login/tsconfig.app.json",
        "inlineStyleLanguage": "scss",
        "assets": [
          "apps/login/src/favicon.ico",
          "apps/login/src/assets",
          "apps/login/src/netlify.toml"
        ],
        "styles": ["apps/login/src/styles.scss"],
        "scripts": [],
        "customWebpackConfig": {
          "path": "apps/login/webpack.config.js"
        }
      },

Let’s commit our changes and push to our remote repo:

git add .
git commit -m “feat: build the login application”
git push

Now the application is ready to be deployed to Netlify!

Deploy the Login App

To deploy the Login app, we’ll follow the same steps we used to deploy the ToDo app.

Go to https://app.netlify.com.
Click on Add new site
Click on GitHub when it prompts to Connect to Git provider.
Select your repository
Modify the Build command and Publish directory.
- Build command should be yarn build login.
- Publish directory should be dist/apps/login.
Click Deploy site

Netlify will build your app then take the built files and deploy them to a newly generated domain. You can find this domain in the Info card on the Netlify Site. Clicking on the URL will take you to your deployed application.

With that, our Login app is complete!

Summary

In this article, we built and deployed our two remote applications! This sets us up for the next article where we will use Module Federation with our Dashboard application to remotely fetch the exposed modules from our remote apps and compose them into a single system.

Blog: https://blog.nrwl.io/
NxDevTools’ Twitter: https://twitter.com/NxDevTools
Nrwl’s Twitter: https://twitter.com/nrwl_io
Colum Ferry’s Twitter: https://twitter.com/FerryColum

Component-First State Management for Angular Standalone Components

Colum Ferry — Sun, 16 Jan 2022 13:42:57 +0000

Introduction

In 2021, Angular announced an RFC (Request For Comments) for Standalone Components. Optional NgModules have been a frequent ask from the framework's community since their introduction in Angular 2-rc.5. Standalone Components (and Directives and Pipes) are Angular's answer to this request. It paves the way for our Angular apps to be built purely with Components.

However, over the years we have built architectural patterns for Angular taking into account that NgModules exist and are the driving force of current Angular apps. With NgModules becoming optional, we need to think about new patterns that can help us to build the same resiliant and scalable apps, but using a simpler mental model of our apps.

This is where Component-First comes in to play. It is a collection of patterns for designing Angular apps, once we have Standalone Components, that emphasises that Components, as the main source of user interaction, are the source of truth for our apps.

We should be able to link all the components in our app together and know exactly how our app works.
There’ll be no magic happening off in some obscure module somewhere.

To achieve this, components need to manage their own routing and state.

In this article, we'll explore an approach to State Management that allows components to control their state and be their own source of truth.

If you're interested in seeing how Routing changes with Standalone Components, read the article I wrote on the matter below

Component-First Architecture with Angular and Standalone Components

Why do we need a different approach?

In the current state of Angular, the framework does not ship with a built-in solution to state management. It does provide the building blocks, but it does not take an opinionated stance on how to manage the state in your app. The Angular community has stepped in to fill that gap in the ecosystem with the creation of packages such as

NgRx
NgXs
... Others that I have not listed.

However, the ones I have listed, arguably the most popular in the ecosystem, rely on NgModules to instantiate the State Management Solution.

If we want to move to a truly NgModule-less developer experience, we need to transition away from any solution that relies on NgModule, otherwise we will always be coupling our components to NgModules. This coupling will continue to be more and more difficult to remove them over time. It also complicates the modelling of our system. Our state will be created and handled in a separate location from our components. This increased obscurity in how our state gets managed makes it more difficult for us to evaluate our components and how they function.

NgRx has already taken steps in the direction that I feel is perfect for a Standalone Components world. They created a package called Component Store which allows Components to manage their own state. It works and it is a great solution! If you've used it before and you're comfortable with RxJS, use it!

However, I have created a package, @component-first/redux, that implements the Redux pattern in a local component store that does not use RxJS that we can also use to achieve the same effect.

In the rest of this article, I'll illustrate how we can use this package to manage the state within our apps for Standalone Component.

Creating and using a Store for Standalone Components

Let's take the following component as an example. It will be a basic ToDo List component that manages its own list of todos and allow actions such as add and delete.

Our barebones component, without a store, should look similar to this:

@Component({
  standalone: true,
  selector: 'todo-list',
  template: `<input #newTodo type="text" /><button
      (click)="addTodo(newTodo.value)"
    >
      Add
    </button>
    <ul>
      <li *ngFor="let todo of todos">
        {{ todo.name }} <button (click)="deleteTodo(todo.id)">Delete</button>
      </li>
    </ul>`,
  imports: [CommonModule],
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class TodoListComponent implements OnInit {
  todos = {};
  incrementId = 1;

  constructor() {}

  ngOnInit() {
    this.todos = {
      0: { name: 'Example Todo' },
    };
  }

  addTodo(todo: string) {
    this.todos[this.incrementId++] = { name: todo };
  }

  deleteTodo(id: number) {
    delete this.todos[id];
  }
}

It's a pretty straightforward component that is internally managing it's own state. Creating a Store for it may be overkill, but it'll be a good example to showcase the component store.

First, we need to create the store. We create a file beside our component called todo-list.component.store.ts and it should look like this:

import { Store } from '@component-first/redux';
import { ChangeDetectorRef, Injectable } from '@angular/core';

// We need to define the shape of our state
interface TodoListState {
  todos: Record<string, { name: string }>;
  incrementId: number;
}

// We only want to inject our Store in our component, so do not provide in root
// We also need to extend the Store class from @component-first/redux
@Injectable()
export class TodoListComponentStore extends Store<TodoListState> {
  // We define actions and store them on the class so that they can be reused
  actions = {
    addTodo: this.createAction<{ name: string }>('addTodo'),
    deleteTodo: this.createAction<{ id: number }>('deleteTodo'),
  };

  // We also define selectors that select slices of our state
  // That can be used by our components
  selectors = {
    todos: this.select((state) => state.todos),
  };

  // We need a function that our Component can call on instantiation that
  // will create our store with our intiial state and the change detector ref
  create(cd: ChangeDetectorRef) {
    const initialState = {
      todos: {
        1: { name: 'Example Todo' },
      },
      incrementId: 2,
    };

    this.init(cd, initialState);

    // We then define the reducers for our store
    this.createReducer(this.actions.addTodo, (state, { name }) => ({
      ...state,
      todos: {
        ...state.todos,
        [state.incrementId]: { name },
      },
      incrementId: state.incremenet + 1,
    }));

    this.createReducer(this.actions.deleteTodo, (state, { id }) => ({
      ...state,
      todos: {
        ...state.todos,
        [id]: undefined,
      },
    }));
  }
}

It's as simple as that, and now our state management is self contained in a class and file that lives right beside our component. Now, lets modify our component to use our new store:

import { SelectorResult, LatestPipe } from '@component-first/redux';
import { TodoListComponentStore } from './todo-list.component.store';

@Component({
  standalone: true,
  selector: 'todo-list',
  template: `<input #newTodo type="text" /><button
      (click)="addTodo(newTodo.value)"
    >
      Add
    </button>
    <ul>
      <li *ngFor="let todo of todos | latest">
        {{ todo.name }} <button (click)="deleteTodo(todo.id)">Delete</button>
      </li>
    </ul>`,
  imports: [LatestPipe, CommonModule],
  providers: [TodoListComponentStore],
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class TodoListComponent implements OnInit {
  todos: SelectorResult<Record<string, { name: string }>>;

  constructor(
    private cd: ChangeDetectorRef,
    private store: TodoListComponentStore
  ) {
    this.store.create(cd);
  }

  ngOnInit() {
    this.todos = this.store.selectors.todos;
  }

  addTodo(name: string) {
    this.store.dispatchAction(this.store.actions.addTodo, { name });
  }

  deleteTodo(id: number) {
    this.store.dispatchAction(this.store.actions.deleteTodo, { id });
  }
}

It's pretty straightforward to use our new Store and it follows an API we are all somewhat familiar with providing you have used NgRx in the past. We did have to introduce a new pipe, latest, that will always fetch the latest value from the store on a Change Detection Cycle.

Advanced Techniques

Effects

The Store also supports Effects. This can be useful in a wide variety of situations, however, lets modify our TodoListComponentStore to have an effect that will fetch our Todo list from an API.

import { Store } from '@component-first/redux';
import { ChangeDetectorRef, Injectable } from '@angular/core';

interface TodoListState {
  todos: Record<string, { name: string }>;
  incrementId: number;
}

@Injectable()
export class TodoListComponentStore extends Store<TodoListState> {
  actions = {
    addTodo: this.createAction<{ name: string }>('addTodo'),
    deleteTodo: this.createAction<{ id: number }>('deleteTodo'),
    // We need a new action to load the todos from an API
    loadTodos: this.createAction('loadTodos'),
  };

  selectors = {
    todos: this.select((state) => state.todos),
  };

  create(cd: ChangeDetectorRef) {
    const initialState = {
      todos: {},
      incrementId: 0,
    };

    this.init(cd, initialState);

    this.createReducer(this.actions.addTodo, (state, { name }) => ({
      ...state,
      todos: {
        ...state.todos,
        [state.incrementId]: { name },
      },
      incrementId: state.incremenet + 1,
    }));

    this.createReducer(this.actions.deleteTodo, (state, { id }) => ({
      ...state,
      todos: {
        ...state.todos,
        [id]: undefined,
      },
    }));

    // We create an effect that will occur when the LoadTodos action is dispatched
    this.createEffect(this.actions.loadTodos, () => {
      // It will make an API call
      fetch('api/todos').then((response) => {
        const todos = response.json();
        todos.forEach((todo) =>
          // Then it will dispatch our existing AddTodo action to add the todos
          this.dispatchAction(this.actions.addTodo, todo)
        );
      });
    });
  }
}

Now that we have added our effect, we can take advantage of it in our component by disptaching an action:

import { SelectorResult, LatestPipe } from '@component-first/redux';
import { TodoListComponentStore } from './todo-list.component.store';

@Component({
  standalone: true,
  selector: 'todo-list',
  template: `<input #newTodo type="text" /><button
      (click)="addTodo(newTodo.value)"
    >
      Add
    </button>
    <ul>
      <li *ngFor="let todo of todos | latest">
        {{ todo.name }} <button (click)="deleteTodo(todo.id)">Delete</button>
      </li>
    </ul>`,
  imports: [LatestPipe, CommonModule],
  providers: [TodoListComponentStore],
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class TodoListComponent implements OnInit {
  todos: SelectorResult<Record<string, { name: string }>>;

  constructor(
    private cd: ChangeDetectorRef,
    private store: TodoListComponentStore
  ) {
    this.store.create(cd);
  }

  ngOnInit() {
    this.todos = this.store.selectors.todos;
    // OnInit, load the todos!
    this.store.dispatchAction(this.store.actions.loadTodos);
  }

  addTodo(name: string) {
    this.store.dispatchAction(this.store.actions.addTodo, { name });
  }

  deleteTodo(id: number) {
    this.store.dispatchAction(this.store.actions.deleteTodo, { id });
  }
}

Global / Shared State

Now that we don't have NgModules, how can we share a store between components?

Note: I wouldn't recommend it, but it does have it's uses, such as a global notification system.

In Component-First, because all our components are children or siblings of each other, we can take advantage of Angular's Injection Tree and simply inject a parent's Store into our child component.

Let's say we had a component, TodoComponent, that was a child to TodoListComponent, then we could do the following:

@Component({
    ...
})
export class TodoComponent {

    constructor(private store: TodoListComponentStore) {}
}

I'd advise caution with this approach as it forces a coupling between TodoListComponent and TodoComponent where TodoComponent must always be a child of TodoListComponent. In some scenarios, this makes logical sense, but it's something to be aware of!

Play with the package

The @component-first/redux package is available on npm and you can use it to experiement with. Just note that the LatestPipe is currently not Standalone in the package (I do not want to ship the Standalone Shim provided by Angular), so you will have to add the LatestPipe to an NgModule's declarations. When Standalone Components arrive, I will make the pipe Standalone!

I hope this article helps to get you excited for Standalone Components and helps you start to think about some approaches we can take to architecture when they do arrive!

If you have any questions, feel free to ask below or reach out to me on Twitter: @FerryColum.

Scaffold and Deploy the Dashboard to Netlify

Colum Ferry — Wed, 12 Jan 2022 15:08:04 +0000

This is the second article in a series of articles that aims to showcase the process of scaffolding and deploying a Micro Frontend Architecture using Nx and Netlify. We will generate the Dashboard application as a host app and walk through the steps of deploying it to Netlify.

Scaffold the Dashboard

The Dashboard application will be a host MFE app. In the context of Micro Frontends, a host application fetches federated code from a series of remotely deployed applications at runtime. It acts as a container for the remotely deployed applications, hosting them in a specific area within the host app that makes sense for your system. It makes a request to the deployed remote applications to fetch a file that contains the exposed code that can then be consumed by the host application.

Nx ships with generators that allow you to easily generate a new application that will generate the appropriate webpack config to mark it as a host application. To do this, run the following command:

yarn nx g @nrwl/angular:app dashboard --mfe --mfeType=host --routing=true --style=scss

Running this command will do a few things:

It generates a new Angular app.
It will change the build and serve executor to one that supports a custom webpack config.
It will create a custom webpack.config.js file containing the required Module Federation setup.
It will install @angular-architects/module-federation package which contains some useful helpers.

Our Dashboard app is now ready to consume code from remote applications.
If we serve the application locally by running:

yarn nx serve dashboard

Our application should build and be served correctly. Navigating to http://localhost:4200 should result in the following:

However, it is not yet ready to be deployed.

Prepare the app for Deployment

When we build the dashboard, it builds to static files. An index.html, a bunch of JavaScript files and a CSS file. In a standard Angular app deployment, as with most SPAs, we do not route to other files hosted on the server. The SPA will prevent standard browser routing and, instead, it will load different JavaScript code based on the path in our URL. For this to occur after we deploy an SPA, we need to tell our web server that all routes should resolve to our index.html file, allowing Angular to handle the routing internally. Therefore, we need to tell Netlify how to handle requests to endpoints by routing them through to the index.html file.

Netlify provides a convenient method to configure how your site gets deployed. You can specify a netlify.toml file, which Netlify will automatically pick up and apply during the deployment process. Let’s create this file.

Create the file netlify.toml at the source root of your Dashboard app (apps/dashboard/src) and place the following content in it:

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

We also need to tell our executor to include this file in the build output. Open up the project.json file for your Dashboard app (apps/dashboard/project.json) and find the build option. It should look like this:

    "build": {
      "executor": "@nrwl/angular:webpack-browser",
      "outputs": ["{options.outputPath}"],
      "options": {
        "outputPath": "dist/apps/dashboard",
        "index": "apps/dashboard/src/index.html",
        "main": "apps/dashboard/src/main.ts",
        "polyfills": "apps/dashboard/src/polyfills.ts",
        "tsConfig": "apps/dashboard/tsconfig.app.json",
        "inlineStyleLanguage": "scss",
        "assets": [
          "apps/dashboard/src/favicon.ico",
          "apps/dashboard/src/assets"
        ],
        "styles": ["apps/dashboard/src/styles.scss"],
        "scripts": [],
        "customWebpackConfig": {
          "path": "apps/dashboard/webpack.config.js"
        }
      },

Add the netlify.toml file to the assets array so that it gets copied over in place. Your build config should look like this:

    "build": {
      ...
      "options": {
        ...
        "assets": [
          "apps/dashboard/src/favicon.ico",
          "apps/dashboard/src/assets",
          "apps/dashboard/src/netlify.toml"
        ],
        ...
      },

Let’s commit our changes and push to our remote repo:

git add .
git commit -m “feat: scaffold dashboard application”
git push

Now the application is ready to be deployed to Netlify!

Deploy the Dashboard

Let’s deploy our site to Netlify. Go to https://app.netlify.com.

To set up our Dashboard site, follow the steps below:

Click here to see a gif of the process

Click on the Import from Git button.
Click on GitHub when it prompts to Connect to Git provider.
Select your repository
Modify the Build command and Publish directory a. Build command should be yarn build dashboard b. Publish directory should be dist/apps/dashboard
Click Deploy site

Clicking on the URL will take you to your deployed application. It’s that easy!

Your Dashboard application has been deployed and is ready to be modified to consume the remote applications that we will build in the next article! Keep an eye on our blog and Twitter pages to be notified when it gets released. You can find links to these below.

Blog: https://blog.nrwl.io/
NxDevTools’ Twitter: https://twitter.com/NxDevTools
Nrwl’s Twitter: https://twitter.com/nrwl_io
Colum Ferry’s Twitter: https://twitter.com/FerryColum

DEV Community: Colum Ferry

Qwikify your Development with Nx

Creating the Workspace

Generate the App

Generate a new Route

Build a Basic UI

Generate a Library

Add a Qwik Context

Using the Context

Adding a routeLoader$ to load data on Navigation

Handle the Form Action to add todos

Improve the Architecture

Conclusion

Further Reading

Learn More

Using NgRx Standalone APIs with Nx

Create a new Nx Workspace

Generate the root state

Generate a new feature library

Add feature state to the feature library

Conclusion

Learn More

Setting up Module Federation with Server-Side Rendering for Angular

How it works

Example

Serving the login application and watching for changes

Learn More

Component-First Architecture with Standalone Components and Nx

Introducing Standalone Components

Creating Components

Using Standalone Components

Routing

Testing

Bootstrapping an Application

What is Component-First Architecture?

Standalone Components and Declarables

Reduced Provider Indirection

Dedicated Routes File

Component-led State Management

Example Directory Structure

How can Nx help?

Conclusion

Learn More

Generating Standalone Component-based Angular Applications and Libraries with Nx

Initial Setup

Generating a Standalone Component-base Application

Generating a Standalone Component Feature Library

But we can do more

Conclusion

Learn More

Setup Module Federation in Angular using Nx

Convert an existing monolithic application

Setting up new workspaces for Module Federation

Conclusion

Jumpstart your Angular 14 development with Storybook, Tailwind and Nx

Workspace Setup

Add Storybook

Add Tailwind

Let's build a Button component

Recap

Migrating to Nx

Conclusion

Angular CLI and Nx - Why?

What is Nx?

The Current State of Affairs

Angular CLI

Nx CLI

Command Comparison

Feature Comparison

Code Generation

Caching

Migrations

Configuration

Architecture

Extensibility

Switching from the Angular CLI to the Nx CLI

Conclusion

Integrate the Remote apps with the Dashboard

Overview

Integrate the Remote Applications

Adding a `routeLoader$` to load data on Navigation