DEV Community: Pahan Perera

Visual Introduction to Frontend Testing Types

Pahan Perera — Sat, 11 May 2024 06:03:27 +0000

Frontend web applications are very crucial part of any software system. That is where users interact with our system. Therefore it is important that we test our frontend application code before and after deployment.

Intention of this post is to provide an overview to different types of Frontend Tests by covering

An introduction to different types of Frontend Tests
Where each tests belong in software development cycle
Scope of each tests
Technologies and libraries that can be used in each tests

Also this post is written with the context of a ReactJS application, but overall concepts explained in this post can be easily applicable for any Frontend project.

So Let's Get Started...!

Introduction to Frontend Tests

Below visualization shows the types of testing that we are going to discuss today and where each tests belong in the development and deployment cycle.

Before we go further, Lets remind ourself about two types of components that we see in Component based Frontend Project.

Dumb/Static Components - Components that ONLY uses props to communicate with external world. Normally these components are the leaf components in our component tree.
Smart/Container Components - These components use Dumb/Static components to make a more opinionated user experience. They communicate with external world in different ways including fetch APIs, mutating global state of the application and reacts to global state changes. Custom Hooks that we write normally goes into this category.

Following diagram summarize what we just talked.

Now let's go in details of each test types

Unit Tests

Unit Tests are the most famous type of developer testing type. It tests each unit or component in our frontend application in isolation. If we think of our component tree, unit tests cover our list of Dumb/Static Components

Technologies can be used

Jest - https://jestjs.io/ (Javascript Testing Framework and Runner)
React Testing Library - https://testing-library.com/docs/react-testing-library/intro/

Component Tests

We can identify this type as a variant of Unit Tests that specialized in testing Smart Components. Since Smart Components communicate with external world in different ways, it is important to mock these communication channels and external boundaries, so that we can test these Components in isolation.

Technologies can be used

Jest - https://jestjs.io/ (Javascript Testing Framework and Runner)
React Testing Library - https://testing-library.com/docs/react-testing-library/intro/
Mock Service Worker - https://mswjs.io/ (Mocking the API Responses in the browser without creating a separate mock server)
Cypress Component Testing - https://docs.cypress.io/guides/component-testing/overview

Snapshot Tests

Our components changes frequently. But as developers, sometimes we only updates the component logic which does not change how the component renders on the page. Snapshot Tests make sure visualization of the component does not change unexpectedly.

Technologies can be used

Jest - https://jestjs.io/docs/snapshot-testing (Javascript Testing Framework and Runner)
React Testing Library - https://testing-library.com/docs/react-testing-library/intro/
Storybook Snapshot Testing - https://storybook.js.org/docs/writing-tests/snapshot-testing

Component Level Accessibility Tests

Accessibility tests are very important to make sure the application we build is accessible for all types of users. Normally Accessibility Tests are done manually by Accessibility Testing Experts, but there are very powerful libraries that capable of catching some obvious accessibility issues in the early stage of development cycle.

Technologies can be used

Jest - https://jestjs.io/ (Javascript Testing Framework and Runner)
React Testing Library - https://testing-library.com/docs/react-testing-library/intro/
Axe Tools - https://www.deque.com/axe/devtools/web-accessibility/ (Provides React SDK that tests for accessibility issues in component rendering)
StoryBook - https://storybook.js.org/docs/writing-tests/accessibility-testing

Contract Testing

Most Frontend Application requires a Backend API Server to fetch data. Contract Testing helps us to make sure the API contract between the Frontend Application and the Backend API Server (i.e API Request and Response) is valid and no compatibility issues after deploy.

If we follow Consumer Driven Contact Testing (See this playlist for more info) we can achieve following

The new version of Frontend Application that is about to get deploy is compatible with the backend API server that is already deployed.
If you are about to deploy a new version of backend API server, we can make sure we are not breaking current version of the Frontend Application that is already deployed.

Post Deployment Testing

Most of the post deployment testing types including End-to-End Tests, Accessibility Tests and Performance Tests simulate the loading of the application in a web browser and trigger user interactions as an actual user would do in the application.

End-to-End Tests

End-to-End Tests automatically loads the web application in the browser and simulates the user activities. For example test script would find a button in the browser and click on that and waits, similar to how actual user would do. Then our web application runs its logic, call an API server and gets all the data and display accordingly. Then test script assert the rendered data as it intends to show it to the user.

Normally these test scripts are align with user stories and can be written in gherkin format as well.

https://dev.to/pahanperera/gherkin-style-e2e-tests-for-a-web-application-using-cucumberjs-4djl

Technologies can be used,

Cypress - https://docs.cypress.io/guides/overview/why-cypress
Selenium - https://www.selenium.dev/documentation/overview/ (End-to-End Test Runner)

Accessibility Tests

Similar to End-to-End Tests, Accessibility tests also automatically loads the web application in the instrumented/simulated web browser and check for the visual output of the final rendered web application.

These tests covers

Evaluating page structure, color contrast, form labels, and multimedia alternatives
Validating Screen Readers
Keyboard only navigation

Technologies can be used,

Axe Tools - https://www.deque.com/axe/devtools/web-accessibility/

https://www.applause.com/blog/accessibility-testing-what-you-should-know/

Performance Tests

Performance Tests determines the quality of the web application and generate reports/audits for performance, accessibility, progressive web apps, SEO, and more.

Technologies can be used,

Google Lighthouse - https://developer.chrome.com/docs/lighthouse/overview

Based on the nature of our frontend application, we may need to focus more on getting certain metrics right, rather than trying get everything.

Conclusion

There are lot of other Frontend tests types that are not mentioned in this post and depending on the nature of the project we have to decide what are the types of testing are best fit for our frontend application.

I hope this post gave you an idea of what types of Frontend test that you can do to make sure you deliver an quality product to your customers.

❤️ Appreciate your feedback and thank you very much for reading.

How to create a shared context between asynchronous calls in nodejs

Pahan Perera — Sat, 28 May 2022 02:02:28 +0000

👋 Hello Everyone..!!!

As a javascript developer, even though you don't implement your own asynchronous functions very often, you are very likely to need to use them in your everyday project.

Typically there are two/three ways to deal with asynchronous functions.

Callbacks
Promises
Async/Await (i.e Promises)

You can read more about these here.

Problem Statement

When you have a chain of asynchronous calls (callbacks or promises), how do you share a common context between all these calls?

Let's think of the following example.

You are writing a function called getCustomerOrders() that returns customer details along with his/her active orders. Inside that function you have to call asynchronous getCustomer() and asynchronous getOrders() where both of these function needs a customerId from in the Request.

Solution is simple right? 😊

You just extract the customerId from the Request and pass it to both getCustomer() and getOrders() as function parameters.



const getCustomer = async (customerId: string): Promise<Customer> => {
    return fetchCustomerFromApi(customerId);
};

Yes, this is probably the best way that you share context between asynchronous calls. But do you know an alternative way to share context without passing as parameters?

AsyncLocalStorage

AsyncLocalStorage class of async_hooks module is released as part of Node.js 14.

As per the NodeJS official documentation

These classes are used to associate state and propagate it throughout callbacks and promise chains. They allow storing data throughout the lifetime of a web request or any other asynchronous duration. It is similar to thread-local storage in other languages.

In simple terms, this acts as a global variable that scoped to a particular asynchronous execution context.

Let's see AsyncLocalStorage in action

Let's see how we can refactor our getCustomerOrders() example to use AsyncLocalStorage

First, import AsyncLocalStorage from async_hooks module.



import { AsyncLocalStorage } from "async_hooks";

Next, you have to create instance from AsyncLocalStorage representing the data that you are going to share. In this example we are going to store the customerId.



const userAsyncLocalStorage = new AsyncLocalStorage<{ customerId: string }>();

Now, you have to wrap the getCustomerOrders() function using AsyncLocalStorage.run function. This is where all the magic happens. As the first parameter to the run function, you can pass the data that you want to share.



userAsyncLocalStorage.run(
    {
      // customerId is read from the Request
      customerId: "123456789",
    },
    async () => {
      const customer = await getCustomer();
      const orders = await getOrders();
      // write data to Response 
      console.log({
        customer,
        orders,
      });
    }
  );

Finally, inside the getCustomer() and getOrders() you can retrieve customerId as below.



const getCustomer = async () => {
    const { customerId } = userAsyncLocalStorage.getStore();
    return fetchCustomerFromApi(customerId);
}

That is the end of very basic application using AsyncLocalStorage.

Usage

Global state or variables are generally considered bad
as they make testing and debugging a lot harder. Therefor the pattern of using AsyncLocalStorage to share business data across multiple asynchronous calls (like we share customerId) is not recommended.

But AsyncLocalStorage pattern comes in handy when you develop/use APM Tools, which collect performance metrics.

This post explains how you can use AsyncLocalStorage to create a simple logger component.

Also NodeJS Frameworks like adonisjs uses AsyncLocalStorage extensively during the HTTP requests and set the HTTP context as the state.

You can read more about that here.

❤️ Appreciate your feedback and thank you very much for reading...!!

Service Worker Caching Strategies

Pahan Perera — Wed, 26 Jan 2022 05:47:49 +0000

Service workers are an essential part of developing rich and powerful web applications. It provides the technical foundation to features like offline support, periodic background syncs and push notifications and eventually supports Progressive Web Apps (PWA).

In order to provide great offline support, necessary resources and (sometimes) data need to be cached within the web browser.

At a high-level, a web application can have multiple levels of caching.

Service Worker Cache - This is only enabled programmatically by installing a service worker into the web application. Once enabled, resources are cached using Cache Storage or IndexedDB. There are different caching strategies in this level, and we will talk more about it later in this post.
HTTP Cache / Browser Cache - Browsers tend to cache resources in the browser. If the cache has not yet expired, the browser automatically uses the cached response avoiding an external network request. However this behavior can be changed using certain response headers.
https://web.dev/http-cache/
Server-Side Cache - Network components like CDN are used to achieve this level of caching. However this does not help the offline support of your web application, but it drastically reduces content loading time over the network.
https://vercel.com/docs/concepts/edge-network/overview

If the content is not found in any of these levels, request will reach the origin server.

https://web.dev/service-worker-caching-and-http-caching/

In this post, we will focus on different Service worker caching strategies. Each strategy will have its pros and cons and you can implement one or more strategies depending on your application characteristics.

Also I have created a playground that demonstrate how each caching strategy works.

Please note, that this application does not have any actual service worker implementation, and intention was to create a visualization that mimics the actual behavior.

I recommend to continue reading this post in a desktop (wide) browser, since you might not be able to properly interact with the codesandbox app that is embedded in this post.

Let's get started...!

Stale While Revalidate

The stale-while-revalidate strategy checks the cache first and respond immediately if there is a cached response. Meanwhile a revalidation request will be initiated to the server and that new response will be cached for the future use.

This is a fairly common strategy where having the most up-to-date resource is not vital to the application.

https://developers.google.com/web/tools/workbox/modules/workbox-strategies#stale-while-revalidate

Cache First (Cache Falling Back to Network)

If there is a cached response, that will be served immediately and network will not be used at all. But if there is no cached response, it will fall back to network to get the latest response.

For assets that are non-critical, Cache First is the best option. Also this will gradually cache the responses as you use the app.

https://developers.google.com/web/tools/workbox/modules/workbox-strategies#cache_first_cache_falling_back_to_network

Network First (Network Falling Back to Cache)

As the first attempt, it will try to get the response from network. If it is successful, that response will be served while stored in the cache as well. If the network is not accessible, cached response is used.

For requests that are updating frequently, the network first strategy is the ideal solution.

https://developers.google.com/web/tools/workbox/modules/workbox-strategies#network_first_network_falling_back_to_cache

Network Only

This does not involve any cache. Always relies on the network to get the response.

https://developers.google.com/web/tools/workbox/modules/workbox-strategies#network_only

Cache Only

Network will not be used at all. This is a less commonly used since, you have do a pre-caching step before this strategy to work.

https://developers.google.com/web/tools/workbox/modules/workbox-strategies#cache_only

Conclusion

Today we learnt about different caching levels of a web application and different caching strategies that can be used in Server Worker based caching implementation.

Hope you enjoyed playing with the demo application. you can find the full app here.

https://codesandbox.io/s/sw-cache-visualizer-vw649

If you want to try some of these patterns, you can use the https://developers.google.com/web/tools/workbox library that provides all the features out-of-the-box.

As an example

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';

registerRoute(
  ({url}) => url.pathname.startsWith('/images/avatars/'),
  new StaleWhileRevalidate()
);

❤️ Appreciate your feedback and thank you very much for reading.

How to write E2E tests in plain text using Cucumber.js

Pahan Perera — Wed, 12 Jan 2022 05:56:55 +0000

End-to-End (E2E) Testing is a testing methodology used in software development life cycle (SDLC) to test the functionality of an application deployed as a complete system. This simulates real world user scenarios starting from frontend application, and verifies the application works as expected. After completion of this test, not only the frontend application but all the other sub-systems are validated as well.

There are some advance, developer friendly Javascript based E2E Testing Frameworks such as Cypress, Protractor and React Testing Library.

But Cucumber is well-known for its native support for Behavior Driven Development (BDD).

What is Behavior Driven Development (BDD)?

Behavior Driven Development (BDD) is an approach that defines the behavior of an application through examples of plain text (gherkin syntax). At the beginning of the development, this human readable document defines the application specifications, but later it can be used as an executable that runs the E2E tests.

This powerful approach helps the cross functional team (marketing, product owners, developers) to create a shared understanding of the application features and minimizes the gap between technical and non-technical team members.

More information about BDD

Aforementioned feature specifications are written using gherkin syntax with familiar Given, When, Then format.



Feature: Add Todo
  Scenario: add simple todo
    Given I load the TodoApp
    When I add new todo called "Pay rent"
    Then I should see a "pending" todo called "Pay rent"

Like any other E2E Testing Framework, Cucumber.js also expects an assertion library such as assert or chai and WebDriver for browser automation such as selenium-webdriver.

In this post, I will focus on

Installing Javascript version of Cucumber (cucumber.js) on a simple Todo App written in React.
Write some feature specifications in gherkin format
Execute those feature specifications as E2E tests.

Our final application and e2e tests configuration would look like following.

You can also refer to my github project that has everything covering in this post.

Let's get started...!

Create a simple web app and install cucumber.js

You can use any web application that you have for this or create a simple app like my simple todo app.

Install dependencies



yarn install -D @cucumber/cucumber chromedriver selenium-webdriver

You might need to install an assertion library that you prefer. But to keep things simple, I am using NodeJS inbuilt assert library.

Update the scripts in package.json to run the tests as well



"scripts": {
    ...
    "e2e": "cucumber-js e2e-tests"
},

Also if you want to define advance configurations you can create a cucumber.js file.

Also make sure the app is running at http://localhost:3000, so that our e2e tests can run against that.

Write a Gherkin based feature specification

Inside the e2e-tests folder, add the following addTodo.feature file. (.feature extension is important for the cucumber.js)



Feature: Add Todo
  Scenario: add simple todo
    Given I load the TodoApp
    When I add new todo called "Pay rent"
    Then I should see a "pending" todo called "Pay rent"

Write Step Definitions

Step definitions are a code that you write to help converting gherkin based feature specification into a machine readable executables. For an example when you say When I add new todo called "Pay rent", step definitions explain what need to be done in the application.

Basically it will

Find the input field to enter the todo
Type "Pay rent" in that input field
Find the button which saves the todo
Click that button

In High level there are two steps

Configure the WebDriver

You need to configure a WebDriver so that your web application can be manupilated by the test scripts. In this example I am installing chromedriver which provides the chrome driver as a NodeJS Module (NPM).

Web Driver's driver object can be initiated as below.



this.driver = await new Builder()
  .forBrowser("chrome")
  .setChromeService(service)
  .setChromeOptions(chromeOptions)
  .build();

To learn more about installing drivers, you can refer this.

Write the step definitions

You can create a steps.js file inside the e2e-tests/lib folder



When("I add new todo called {string}", async function (todoText) {
  // 1. Find the input field to enter the todo
  const input = await this.getAddTodoInput();
  // 2. Type "Pay rent" in that input field
  await input.sendKeys(todoText);
  // 3. Find the button which saves the todo
  const btn = await this.getAddTodoButton();
  // 4. Click that button
  await btn.click();
});

As you can see, step definition function can be parameterized, providing ability to create generic function that works for multiple cases.

Also if you see, there are some utility functions like this.getAddTodoInput() that are used to detect the UI components within your web application. You can create a world.js with those utility function.



  async getAddTodoInput() {
    return this.driver.findElement(By.name("addTodoInput"));
  }

  async getAddTodoButton() {
    return this.driver.findElement(By.id("addTodoBtn"));
  }

  async getTodoCountText() {
    return this.driver.findElement(By.id("todoCountText"));
  }

To understand more about the steps.js and world.js please refer to this.

My goal here is to highlight some of the important areas that you need to focus on integrating cucumber.js to your next web application. Since this might be little confusing to a beginner, I really encourage you to refer to the sample application.

https://github.com/PahanPerera/simple-todo-app-with-bdd

This is how those low level components are stitching together to run the e2e tests

Finally you can run the e2e tests



yarn e2e

If you configure the HTML reporting, you can see a e2e-report.html file generated as well

Conclusion

BDD style E2E Tests might not be a fully convenient approach for a very technical developer, But it helps when you work in cross functional team. Also implement this approach in a real world software development life cycle can be more tricky than it appears.

Overall I think this is a very innovative concept that brings all the team members together and helps improving the productivity as well.

In this post, I roughly touched on the initial implementation that helps you to get started with your BDD style E2E Tests with Cucumber.js, Gherkin and Selenium Web Driver.

All the points that we discussed in this, can be found in this sample repo.
https://github.com/PahanPerera/simple-todo-app-with-bdd

❤️ Appreciate your feedback and thank you for reading...

Visual Explanation and Comparison of CSR, SSR, SSG and ISR

Pahan Perera — Tue, 04 Jan 2022 00:25:12 +0000

Hello there,

Next.js is a very popular React framework and one of the beautiful features is the ability to build your web application using different rendering techniques, such as

CSR - Client Side Rendering
SSR - Server Side Rendering
SSG - Static Site Generation
ISR - Incremental Static Regeneration

In this post, I will focus on explaining and comparing these techniques using visual diagrams with minimal texts, and my goal is to create a short note that you can quickly refer when needed.

Having said that, this post does not cover advance technical details and code snippets, that you might want to learn as a web developer.

Let's get started..!

Client Side Rendering

This is what most of the web frameworks like Angular and React support out of the box. This is commonly suitable for single page applications (SPA) and applications with lot of user interactions (e.g Games) and highly dynamic content such as forms, and chat applications.

Basically web browser will initially load an empty HTML file. Javascript and styles which are loaded after, are responsible for rendering the full user friendly page in the web browser.

Server Side Rendering

Main disadvantage of CSR is that it is not Search Engine Optimized. Therefore most of the web frameworks, provide the ability to render the pages in server as well.

Not like CSR, Each page will initiate a request to App Server, where it dynamically renders and serves full HTML for that page. Since it requests and renders the page each time user requests, page serve time is more than a CSR application.

Static Site Generation

To avoid the rendering in each request, why don't we generate those files in the build time, so that we can instantly serve the pages when user requests it.

This technique will come in handy if you want to build a web application with full of static content like a blog. One drawback is that the content might be out-of-date and your application is needed to build and deploy each time when you change the content. (in a CMS)

Incremental Static Regeneration

ISR is the next improvement to SSG, where it periodically builds and revalidates the new pages so that content never gets too much out-dated.

Comparison

To compare these four techniques, we will consider following metrics.

Build time - Less value the better.
Suitable for Dynamic Content - If this value is high, that technique is more suitable for applications with lot of dynamic content.
Search Engine Optimization - Most cases, it is best to have a good value for SEO.
Page Serve/Render Time - How long it takes to render the full page in the web browser. Less value the better.
Most Recent Content - Indication that it always delivers the latest content. More value the better.
Static Server / App Server - Does this technique need to have a static server or an app server. Normally static servers consume lot less resources than the app servers.

Some of the key thoughts are

Page Serve/Render Time is less in CSR compared to SSR, since after the initial assets load, CSR manage to load the rest of the pages very quickly. But in SSR, each page request will be served by the app server.
Page Serve/Render Time is more in ISR compare to SSG, since ISR periodically requests the updated page from the server.
ISR does not have the most recent content, since there can be a small window where user gets outdated content, just before the periodic content refresh.

Please note that, this comparison might not be accurate based on the different perspectives that you have. Feel free to correct me as well.

Conclusion

In Highlevel, we can divide these rendering techniques into two major categories based on the level of dynamic interactions that your app has.

CSR and SSR can be used to develop highly dynamic web application and both has its pros and cons depending on the scenario.
If you have a highly static content, you can use SSG or ISR. ISR is more advance and optimized, but it requires specific platforms to work.

❤️ Appreciate your feedback and thank you very much for reading.

React Micro Frontends with Webpack's Module Federation

Pahan Perera — Tue, 21 Dec 2021 05:39:29 +0000

Micro Frontends is a very popular topic in today's frontend world. Most of the teams tend to adopt this micro frontend strategy to develop their large and complex web applications, due to many advantages it provides such as,

Separate, decoupled codebases
Independent deployment
Incremental updates

Below diagram showcases some of the important concepts of micro frontends.

Most popular way of developing micro frontends is using HTML5 Web Components (Custom Elements). Angular like web frameworks has extended to support Web Components, while most of other libraries like React, supports it out of the box.

For more information about micro frontends you can refer to

What is Module Federation in Webpack ?

Webpack version 5 comes with a new feature called Module Federation, which helps to share code and dependencies between projects at runtime.

In high level, an application exposes certain component/s via a separate javascript file, and other application that wishes to use that component, async loads that remote javascript file and consume that component.

Recent times this feature has changed the way we develop micro frontends.

In this post, I will walk through how you can develop React based micro frontends using Webpack's Module Federation by creating a simple bank application that shows a list of accounts and account details on a selected account.

This is how our final application architecture would look like.

Let's get started..

All of the code in this post can be found here for your references.

Prerequisites

First of all, since this is about React and webpack, you should have a React application configured with Webpack.

Refer to this project if you need help doing that.

Also, as mentioned above, we will need three React projects for our application

accounts-summary-app - Micro frontend that provides the summary of all the accounts
account-details-app - Micro frontend that provides details of a selected account
main-app - app that hosts above two components. Also acts as a medium to communicate with each other.

Configure `ModuleFederationPlugin` in Micro Frontend Projects

ModuleFederationPlugin is a high level webpack plugin that provides a very convenient way to configure module federation in your projects. Also plugin comes along with webpack library without need of installing another dependency as well.

Responsibility of our micro frontend projects is to expose a component. So let's add following to webpack.config.js of accounts-summary-app project.

import the plugin



const { ModuleFederationPlugin } = require("webpack").container;

configure the plugin



  plugins: [
    new ModuleFederationPlugin({
      name: "AccountsSummaryApp",
      filename: "accountsSummaryApp_remote.js",
      exposes: {
        "./AccountsSummary": "./src/components/AccountsSummary",
      },
    }),
    ...
  ],

name is unique identification of your module. Normally this is the name of your micro frontend project.
filename is the name of the javascript file that exposes the components
exposes is a map (key and a value) of components that are exposed from this module. (key will act as an alias for the component while the value is where the component located in the project)

Now, let's run this project locally and see what happens.

As you can see, now webpack has bundled our AccountsSummary component into a separate javascript file, as we instructed in the webpack configuration.

Let's do the same to the account-details-app project as well



  plugins: [
    new ModuleFederationPlugin({
      name: "AccountDetailsApp",
      filename: "accountDetailsApp_remote.js",
      exposes: {
        "./AccountDetails": "./src/components/AccountDetails",
      },
    }),
    ...
  ],

In case you missed some thing, you can always refer to these two projects

accounts-summary-app
account-details-app

Configure `ModuleFederationPlugin` in Host App project.

Like I was explaining before, our host app, main-app is responsible for loading the components from micro frontend projects.

Like micro frontends configurations defines exposes, Host app's webpack configuration defines remotes that tells webpack where to find those external components.



  plugins: [
    new ModuleFederationPlugin({
      remotes: {
        AccountsSummaryApp_Remote: "AccountsSummaryApp@http://localhost:9001/accountsSummaryApp_remote.js",
        AccountDetailsApp_Remote: "AccountDetailsApp@http://localhost:9002/accountDetailsApp_remote.js",
      },
    }),
    ...
  ],

remotes is a map (key and value) that defines all the external modules that it consumes. Key will act as an alias for the module and value defines the remote javascript file location for that module.

value should have a special format like below

<Name of the Exposed Module>@<Remote URL of the javascript file>

Now that all the webpack configurations are completed, let's write some javascript code to load external components.

Load External Components to Host App

One of the beautify thing about this webpack module federation is that, developers can not feel a difference between importing a local component from its own project and remote component from an external javascript file.

React code will look like you are lazy loading a component.



const AccountsSummary = React.lazy(() =>
  import("AccountsSummaryApp_Remote/AccountsSummary")
);

and use that in your jsx



<Suspense fallback={<h1>Error while loading Account Summary</h1>}>
  <AccountsSummary onAccountSelected={handleAccountSelected} />
</Suspense>

One thing to note about the import is that to use same alias that you define in the host application along with the component alias that you defined in your micro frontend project

Communication between components

As mentioned earlier, external components are same as local components in your project. So standard ways of communication should be applicable here as well.

For this application, I have defined a shared state with in the host application and each component communicate via that shared state.

Refer to main-app to see the code.

Conclusion

This is very beginner level tutorial about how to develop Micro Frontends using Webpack's Module Federation feature. During this post I was able to briefly explain about

What are Micro Frontends
What is Webpack's Module Federation Feature
Configure Micro frontends to expose components
Configure Host app to use those exposed components
How to communicate between components

Full working example can be found here.

You can find the full React Template used in this sample bank application here.

That is all for now. Please share you feedbacks. Thank you for reading.

Implementing Light / Dark Mode in Angular

Pahan Perera — Sun, 05 Dec 2021 06:43:37 +0000

Light / Dark mode toggle is a very common feature in today's web applications. This feature may look very simple to the end users, but it takes some additional effort to correctly implement in a web application.

This post will focus on one of the most straightforward ways of implementing dark mode, using Angular and modern CSS features.

Also as a bonus, I will share a sample Angular project that has some additional features related to this.

Let's get started..!

Why is it (little) difficult in Angular?

In high level, A dark mode implementation requires a CSS-in-JS library so that CSS can be manipulated using Javascript. React Js like web libraries provide the flexibility to integrate any CSS-in-JS library that helps developers to implement dark mode easily.

But Angular is different. Being a framework, Most of the features are handled by the framework providing limited ways to change the underlying library. Also adding to that, default view encapsulation in Angular makes it very difficult to change component's styles from outside. (Obviously that is the purpose)

High level Architecture

CSS variables play an important role in this. Basically you can assign some CSS variables based on a property in the DOM (commonly a CSS class in body). Then you can change that property using Javascript, so that CSS variables change accordingly, affecting the child components styles as well.

I will explain this using an diagram

Firstly, set of CSS variables are defined and assigned based on the class in body element
These CSS variables are used in component styles
Update the class in body element to change the CSS variable assignment. Eventually affecting the component styling as well.

Let's do some coding..!

First let's define some style variables in global styles.scss file. (In this example I am using SCSS, but it is completed optional)



$bgColor_light: white;
$bgColor_dark: black;

$textColor_light: black;
$textColor_dark: white;

$borderColor_light: black;
$borderColor_dark: white;

// mixin that enables css variables in light mode
@mixin lighten() {
  --bgColor: #{$bgColor_light};
  --textColor: #{$textColor_light};
  --borderColor: #{$borderColor_light};
}

// mixin that enables css variables in dark mode
@mixin darken() {
  --bgColor: #{$bgColor_dark};
  --textColor: #{$textColor_dark};
  --borderColor: #{$borderColor_dark};
}

Now we need to call above mixins in a conditional way. We use CSS class name in the body to determine what mixin to call.



body.dark {
  @include darken();
}
body.light {
  @include lighten();
}

Now you can use these CSS variable to style an Angular components.



main {
  display: flex;
  height: 100vh;
  justify-content: center;
  align-items: center;
  flex-direction: column;
  background-color: var(--bgColor);
  color: var(--textColor);
}

Please make sure not to use the SCSS variables directly in your components, since those do not change once defined.

Finally, let's create an Angular component that updates the CSS class in document.body element programmatically.



  /**
   * Function that toggles the current mode
   * Exposed publicly
   */
  toggleMode() {
    this.document.body.classList.toggle(Mode.LIGHT);
    this.document.body.classList.toggle(Mode.DARK);
    if (this.currentMode === Mode.LIGHT) {
      this.updateCurrentMode(Mode.DARK);
    } else {
      this.updateCurrentMode(Mode.LIGHT);
    }
  }

That's all. Pretty simple and straightforward.

Check for User's Device Preference

Some devices provide users to set the device theme as part of system settings. So it is important that, our web application should adhere to this device theme, and load the mode appropriately.

You can easily check that using following @media query



@media (prefers-color-scheme: dark) {
    ...
}

But, we will be using it in your Javascript logic



/**


Init function that update the application based on the initial mode value
Flow as below
1 - If there is a saved mode in the browser - use this as the initial value
2 - If there is no saved mode, Check for the preferred device theme
3 - If device theme is dark, set the init value to dark 
4 - Else set the default value to light
*/
private init() {
const deviceMode = window.matchMedia("(prefers-color-scheme: dark)");
let initMode = this.modeStorage.get();
if (!initMode) {
  deviceMode.matches ? (initMode = Mode.DARK) : (initMode = Mode.LIGHT);
}
this.updateCurrentMode(initMode);
this.document.body.classList.add(this.currentMode);
}

Reference Project

As promised, I will share the sample project that I created to demonstrate above implementation and some additional features such as

Light / Dark Mode Toggle Button Component
Angular service that can be used to implement your own toggle component
Persistence via Local Storage (also ability to write other persistence methods - e.g Session Storage)
Mode change listener based on RxJS Observable
SCSS support with CSS variables
Load initial mode based on Device Theme Preference
Require no additional libraries
Well documented code

Github : Angular Light / Dark App

You can find all the development information in the README.md file.

That is all for now. Please share you feedbacks. Thank you for reading.

DEV Community: Pahan Perera

Visual Introduction to Frontend Testing Types

Introduction to Frontend Tests

Unit Tests

Component Tests

Snapshot Tests

Component Level Accessibility Tests

Contract Testing

Post Deployment Testing

End-to-End Tests

Accessibility Tests

Performance Tests

Conclusion

How to create a shared context between asynchronous calls in nodejs

Problem Statement

AsyncLocalStorage

Let's see AsyncLocalStorage in action

Usage

Service Worker Caching Strategies

Stale While Revalidate

Cache First (Cache Falling Back to Network)

Network First (Network Falling Back to Cache)

Network Only

Cache Only

Conclusion

How to write E2E tests in plain text using Cucumber.js

What is Behavior Driven Development (BDD)?

Create a simple web app and install cucumber.js

Install dependencies

Write a Gherkin based feature specification

Write Step Definitions

Configure the WebDriver

Write the step definitions

Conclusion

Visual Explanation and Comparison of CSR, SSR, SSG and ISR

Client Side Rendering

Server Side Rendering

Static Site Generation

Incremental Static Regeneration

Comparison

Conclusion

React Micro Frontends with Webpack's Module Federation

What is Module Federation in Webpack ?

Let's get started..

Prerequisites

Configure ModuleFederationPlugin in Micro Frontend Projects

Configure ModuleFederationPlugin in Host App project.

Load External Components to Host App

Communication between components

Conclusion

Implementing Light / Dark Mode in Angular

Why is it (little) difficult in Angular?

High level Architecture

Let's do some coding..!

Check for User's Device Preference

Reference Project

Configure `ModuleFederationPlugin` in Micro Frontend Projects

Configure `ModuleFederationPlugin` in Host App project.