DEV Community: Supriya M

Decoding StyleX: Meta's Cutting-Edge Styling System

Supriya M — Sun, 10 Nov 2024 07:14:18 +0000

Every year in October, the biggest international react conference takes place in Goa, India. Yes, I am talking about React India. This year (2024), was even more special for me as I got a chance to speak at this magnificent conference. Here's the recording of my talk if you've missed to watch it live. If you prefer reading over watching videos, then this blog is just for you! Let's dive into it.

What is StyleX?

StyleX is Meta's new, scalable styling library that is now used as the primary system behind platforms like Facebook, Instagram, and WhatsApp. It addresses the pain points experienced with CSS-in-JS approaches, particularly in massive React applications. By offering a hybrid solution that blends the best features of both atomic CSS and static CSS, StyleX offers an efficient, modular, and scalable alternative.

How and Why did Meta create StyleX?

Meta built StyleX to address specific challenges encountered with traditional CSS-in-JS libraries in large-scale projects:

Unused Styles: As projects grow, CSS often accumulates unused rules, bloating the stylesheet.
Performance Issues: CSS-in-JS solutions can result in large CSS files or performance bottlenecks, especially when bundled with the application.
CSS-in-JS Library Size: Many popular libraries used for styling in JavaScript add unnecessary weight to the bundle, impacting load times.

Introduction of StyleX: It was created in 2019 as part of a Facebook UI revamp and they made it open-source in December 2023.
CSS Optimization: Before using StyleX, a single page on Facebook would load around 15-45MB of CSS styles. This was drastically reduced to around 200-300KB with StyleX by utilizing a single CSS bundle.
Purpose of StyleX: It was developed to effectively manage the complexities of styling at scale. It addresses the challenges that arise when numerous developers create thousands of components, which often leads to specificity conflicts within CSS. By providing a structured framework for styling, StyleX helps maintain consistency and clarity in the styling process.
Atomic Class Generation: From the outset, StyleX consistently generates atomic classes, accepting the trade-off of having multiple class names per component for improved maintainability and reduced styling conflicts.

Key Features of StyleX:

Atomic CSS Generation: StyleX employs atomic CSS generation, which means it creates small, reusable classes for each style rule. This approach not only minimizes redundancy in the final CSS bundle but also improves performance by reducing the overall size of the stylesheets.
CSS Deduplication: By generating unique class identifiers for each style, StyleX effectively eliminates duplicate styles. This deduplication process ensures that each property-value pair is rendered only once, further contributing to a leaner CSS output.
“The Last Style Applied Always Wins!”: StyleX follows a predictable styling rule where the last style applied takes precedence. This feature simplifies debugging and enhances developer confidence, as it mitigates concerns about conflicting style rules.
Optimized for React: Designed specifically for React applications, StyleX integrates seamlessly into the React ecosystem. It allows developers to define styles directly within their components, fostering a more cohesive development workflow.
Flow and TypeScript Support: StyleX is written in "Flow" (created by Meta) and it also provides robust support for TypeScript, enabling type-safe APIs for styles and themes. This type safety enhances code reliability and maintainability, making it easier to manage complex styling scenarios.
Flexible Conditional Styling: With StyleX, developers can apply styles conditionally based on component states or props. This flexibility allows for dynamic styling that adapts to user interactions or changes in application state.
Scoped Styling: The scoped styling feature of StyleX ensures that styles are applied only to the components they are intended for. This prevents unintended side effects and specificity issues that often arise in larger codebases.
Fewer Runtime Calculations: StyleX minimizes runtime calculations by bundling all styles into a static CSS file at compile time. This optimization leads to faster rendering times and improved performance, especially in larger applications.
Better Code Maintainability: By co-locating styles with their respective components and utilizing atomic classes, StyleX promotes better code maintainability. Developers can easily understand and modify styles without sifting through extensive stylesheets.
Minimal CSS Output: The use of atomic CSS results in minimal CSS output, which is particularly beneficial for performance. As projects grow in size and complexity, StyleX ensures that the CSS bundle remains manageable without sacrificing functionality.
Works Well for Projects of All Sizes: While StyleX is suitable for projects of all sizes, it truly excels in larger applications. Its architecture is designed to handle the complexities of extensive styling needs without compromising on performance or maintainability.

Let's see how it works 🧑‍💻

The code examples in this article are written in React, and we will primarily work with two components, App.jsx and Button.jsx. Let's take a look at the basic structure of these components before we add styles.

import Button from "./components/Button";

const App = () => {
  return (
    <div>
      <h1>StyleX by Meta</h1>
      <Button text="Get Started" />
    </div>
  );
};

export default App;

// Button.jsx
import PropTypes from "prop-types";

const Button = ({ text }) => {
  return <button>{text}</button>;
};

Button.propTypes = {
  text: PropTypes.string.isRequired,
};

export default Button;

Adding styles using StyleX

import PropTypes from "prop-types";
import * as stylex from "@stylexjs/stylex";

const styles = stylex.create({
  base: {
    fontSize: 18,
    backgroundColor: "black",
    color: "white",
  },
});

const Button = ({ text }) => {
  return <button {...stylex.props(styles.base)}>{text}</button>;
};

Button.propTypes = {
  text: PropTypes.string.isRequired,
};

export default Button;

To use these styles, we need to import them from the styleX package and then define the styles using stylex.create method that takes an object as a parameter. We can then use the stylex.props method to apply the styles to the component.

In this example, base is the name of the style that we want to apply. We call them namespaces in StyleX. This is how our button component looks like now.

Adding styles to pseudo-classes

import PropTypes from "prop-types";
import * as stylex from "@stylexjs/stylex";

const styles = stylex.create({
  base: {
    fontSize: 18,
    backgroundColor: {
      default: "black",
      ":hover": "blue",
    },
    color: "white",
  },
});

const Button = ({ text }) => {
  return <button {...stylex.props(styles.base)}>{text}</button>;
};

Button.propTypes = {
  text: PropTypes.string.isRequired,
};

export default Button;

With StyleX, it's pretty simple to add styles to pseudo-classes. In the previous example, backgroundColor was a string. Here, we convert it to an object with the default value and a pseudo-class.

Working with media-queries

import PropTypes from "prop-types";
import * as stylex from "@stylexjs/stylex";

const styles = stylex.create({
  base: {
    fontSize: 18,
    backgroundColor: {
      default: "black",
      ":hover": "blue",
    },
    color: "white",
    width: {
      default: "100px",
      "@media (max-width: 476px)": "100%",
    },
  },
});

const Button = ({ text }) => {
  return <button {...stylex.props(styles.base)}>{text}</button>;
};

Button.propTypes = {
  text: PropTypes.string.isRequired,
};

export default Button;

One thing that we do differently in StyleX when compared to other styling libraries is the media queries. Here, we apply media queries to every namespace based on requirements. In this example, we are defining the width of the button to be 100px for larger screens and 100% width for smaller screens or mobile devices.

Let's see how "last style applied always wins"

Let's extend the previous example to see how we can create different variants of this button.

const styles = stylex.create({
  base: {
    fontSize: 18,
    backgroundColor: {
      default: "teal",
      ":hover": "blue",
    },
    color: "white",
    width: {
      default: "100px",
      "@media (max-width: 476px)": "100%",
    },
  },
  highlighted: {
    backgroundColor: "orange",
  },
  danger: {
    backgroundColor: "red",
  },
  primary: {
    backgroundColor: "green",
  },
});

const Button = ({ text, isHighlighted, variant }) => {
  return (
    <button
      {...stylex.props(
        styles.base,
        isHighlighted && styles.highlighted, // conditional styling
        styles[variant]
      )}
    >
      {text}
    </button>
  );
};

Button.propTypes = {
  text: PropTypes.string.isRequired,
  isHighlighted: PropTypes.bool,
  variant: PropTypes.oneOf(["danger", "primary"]),
};

Let's add a few more namespaces to stylex.create method and provide them with different background colors. Additionally, we are accepting 2 new props within our Button component. isHighlighted is a boolean prop that we use to apply the highlighted namespace. And variant is a prop that we use to apply the primary, danger or highlighted namespace.

// App.jsx
import Button from "./components/Button";

const App = () => {
  return (
    <div>
      <h1>StyleX by Meta</h1>
      <div {...stylex.props(styles.main)}>
        <Button text="Base Button" />
        <Button text="Highlighted Button" isHighlighted />
        <Button text="Danger Button" isHighlighted variant="danger" />
        <Button text="Primary Button" variant="primary" />
      </div>
    </div>
  );
};

export default App;

We create a few more copies of the Button component with different props being passed on. This is how our app looks like now.

Now, take a closer look at 'Danger Button'. Even though we have passed in isHighlighted as true, the highlighted namespace will not be applied. The danger variant is mentioned last and so it will be applied. Thus, the button will have a red background color.

Overriding styles from parent

We could override the style properties of this Button component from App.jsx directly.

//App.jsx

import Button from "./components/Button";

const styles = stylex.create({
  override: {
    backgroundColor: "purple",
    color: "white",
  },
  main: {
    margin: "1rem",
    display: "flex",
    alignItems: "center",
    gap: "2rem",
  },
});

const App = () => {
  return (
    <div>
      <h1>StyleX by Meta</h1>
      <div {...stylex.props(styles.main)}>
        <Button text="Base Button" />
        <Button text="Highlighted Button" isHighlighted />
        <Button text="Danger Button" isHighlighted variant="danger" />
        <Button text="Primary Button" variant="primary" />
        <Button
          text="Overriden Button"
          isHighlighted
          variant="danger"
          style={styles.override}
        />
      </div>
    </div>
  );
};

In this example, we are overriding the backgroundColor and color properties of the danger variant of the Button component. We define a new namespace called override and pass in the properties that we want to override. This namespace is passed to style prop.

In our button component, we shall consume this namespace too.

// Button.jsx

const styles = stylex.create({
  base: {
    fontSize: 18,
    backgroundColor: {
      default: "teal",
      ":hover": "blue",
    },
    color: "white",
  },
  highlighted: {
    backgroundColor: "orange",
    margin: "1rem",
  },
  danger: {
    backgroundColor: "red",
  },
  primary: {
    backgroundColor: "green",
    margin: "1rem",
  },
});

const Button = ({ text, isHighlighted, variant, style }) => {
  return (
    <button
      {...stylex.props(
        styles.base,
        isHighlighted && styles.highlighted,
        styles[variant],
        style
      )}
    >
      {text}
    </button>
  );
};

In this example, the override namespace currently allows any properties. However, StyleX gives us the capability to limit which properties can be overridden. This feature becomes particularly useful when using TypeScript.

import type { StyleXStyles } from "@stylexjs/stylex";

type Props = {
  // ...
  style?: StyleXStyles<{
    color?: string,
    backgroundColor?: string,
  }>,
};

This limitation ensures that only the backgroundColor and color properties can be overridden.

How does atomic classes work (internals)

If you scroll up to the previous example code, you will see that we have added margin: "1rem" style to 3 different namespaces - main in App.jsx, highlighted and primary in Button.jsx. When we inspect the element using Devtools, we can see that the different components (main container, highlighted button, and primary button) are attached with the same class name and there is only 1 class x42y017 that holds margin: "1rem" style.

That's how StyleX significantly reduced its bundle size by employing atomic classes. After reaching a certain threshold, no new classes are generated; instead, they simply reuse the existing classes.

Global Variables and Themes

Being able to override styles at a granular level is great! However, any given design systems need to support design tokens and themeing. That's where StyleX comes in. The design of the theming APIs in StyleX are directly inspired by React's Context APIs. Variables are defined with default values similar to how React Contexts are created, and themes can be created to “provide” different values for these variables for UI sub-trees.

We can create global styles by creating a x.stylex.js file. Make sure to follow this naming convension. In this file, we make use of stylex.defineVars as shown below.

// tokens.stylex.js
import * as stylex from '@stylexjs/stylex';
export const DARK = '@media (prefers-color-scheme: dark)';

// This function is processed at compile-time and CSS variable names are automatically generated.
export const colors = stylex.defineVars({
  primaryText: { default: 'black', [DARK]: 'white' },
  background: { default: 'white', [DARK]: 'black' },
  borderRadius: '4px’,
  border: '4px solid’,
  borderColor: { default: 'black', [DARK]: 'white' },
});

We are referring to the user's preferred theme and setting it to a constant value - DARK. Further, let's create a new theme using this colors variable.

// theme.js
import * as stylex from '@stylexjs/stylex';
import { colors, DARK } from './tokens.stylex';

// MyCustomTheme theme
export const myCustomTheme = stylex.createTheme(colors, {
  primaryText: { default: 'navy', [DARK]: 'cyan' },
  background: { default: '#ccc', [DARK]: 'black' },
  borderRadius: '2px’,
  border: '2px solid’,
  borderColor: { default: 'navy', [DARK]: 'cyan' },
});

Once the theme is created, it can be used just like any other style in StyleX.

// App.js
import { colors } from "./tokens.stylex";
import { myCustomTheme } from "./theme";

const styles = stylex.create({
  container: {
    color: colors.primaryText,
    backgroundColor: colors.background,
    border: colors.border,
    borderRadius: colors.borderRadius,
  },
  // other namespaces
});

const App = () => {
  return (
    <div {...stylex.props(myCustomTheme, styles.container)}>
      <h1>StyleX by Meta</h1>
      <p>
        StyleX is a CSS-in-JS library that generates atomic CSS classes at
        compile-time.
      </p>
      .. .. .. Button container .. .. ..
    </div>
  );
};

That's how we can see the same page with myCustomTheme in light and dark mode respectively.

That's a wrap 🎉

Hurray! We have successfully got a gist of working with StyleX. Thank you for reading through this article. I hope it provided a good understanding of what is StyleX, how did Meta create it, and how to use it. Please share your thoughts/queries in the comments section or on Twitter. If this blog is interesting to you, I would appreciate it if you could give this post a like (with your favorite emoji 😁).

Peace ✌

References

Connect with me on Topmate For Interview Preparation

Module Federation using ViteJS - Step into the Micro-frontend architecture

Supriya M — Fri, 05 Jan 2024 12:24:22 +0000

For backend developers, the microservice architecture represents a software development approach composed of small, independent services communicating over well-defined APIs. A similar concept for frontend applications is Micro-Frontends. This architectural pattern shares similarities and differences, akin to Microservices, specifically designed for front-end development. One crucial implementation tool enabling this architecture is Module Federation.

What is Module Federation?

Module federation is a concept where different builds come together to make one application. These separate builds act like containers and can expose and consume code between builds, creating a single, unified application. They are also termed as remote modules.

Local modules are standard modules within the current build, while remote modules, not part of the current build, are loaded at runtime from a remote container. Loading remote modules operates as an asynchronous operation.

Module Federation is unidirectional, involving one host while allowing an application to consume multiple remote builds. Each build acts as a container and can consume other builds as containers. This way, each build can access any other exposed module by loading it from its container.

Module Federation was introduced by Zack Jackson, a Webpack maintainer, and became a flagship feature of Webpack 5 in 2020. It serves as a plugin offering flexibility in project development. While Webpack was a popular bundling tool previously used in the Create React App, CRA was deprecated in early 2023, and Vite.js gained popularity as the Next Generation Frontend Tooling. Astro is built on top of Vite.

Today, we'll delve into Module Federation using the Vite Plugin, an excellent tool created by Originjs to develop micro-frontend applications with Vite.

Host and Remote Applications

When using Module Federation, two scopes come into play:

Host: This application typically serves as the primary or container application responsible for integrating and orchestrating multiple micro-frontends or modules. It's the central hub that imports and consumes functionalities or components from "remote" applications.

Remote: These applications are standalone modules or micro-frontends exposing certain functionalities, components, or features. They are self-contained entities developed, deployed, and maintained independently. They provide functionalities that can be consumed by the "host" application or other remotes via Module Federation.

Let's understand these terminologies with the help of an example

Suppose we have a remote application exposing the Header.tsx file. We've also developed two different host applications — a video listing application and a blog page. Both these applications require a common header component.

Remote Component - Header.tsx

To understand creating and exposing the Header component as a remote application, let's utilize Vite's react + typescript template:



# npm 7+, extra double-dash is needed:
npm create vite@latest remote-header -- --template react-ts

# yarn
yarn create vite remote-header --template react-ts

The above command creates a new react application. Now, let's create the Header component:



// ./src/components/Header.tsx
import React from "react";
import "./Header.css";

interface HeaderProps {
  title: "string;"
  logo?: string;
}

const Header: React.FC<HeaderProps> = ({ logo, title }) => {
  return (
    <header className="navbar">
      <div className="logo-container">
        {logo ? (
          <img src={logo} className="logo react" alt="React logo" />
        ) : (
          <small className="logo-text">Logo</small>
        )}
      </div>
      <h1 className="title">{title}</h1>
      <div className="login-btn-container">
        <button className="login-btn">Login</button>
      </div>
    </header>
  );
};

export default Header;

The header component accepts the title and logo as props, granting consuming applications the liberty to provide custom title and logo options.

To make this header component truly remote, we expose them using the @originjs/vite-plugin-federation plugin with the Vite config file.



// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import federation from "@originjs/vite-plugin-federation";

export default defineConfig({
  plugins: [
    react(),
    federation({
      name: "header_app", // any name of your choice
      filename: "remoteHeader.js",
      exposes: {
        "./Header": "./src/components/Header",
        // expose other components if required
      },
      shared: ["react", "react-dom"],
    }),
  ],
  build: {
    target: "esnext",
    cssCodeSplit: false,
  },
});

Ensure to remember the filename value within this configuration. It represents the manifest for all exposed modules. This value is further referenced within the host application. In this example, only the header component is exposed, although additional components can be added. Share any libraries the module depends on. In this case, the Header component shares React and React-DOM that is included in the shared group.

Finally, a few tweaks are made to the configuration. The code transpiles to ESNext, enabling the use of modern JavaScript features. Additionally, CSS file code splitting is disabled, consolidating all styles within the main bundle.

At this point, let us test how the header component looks.



// Testing the rendering of header component - App.tsx

function App() {

  return (
    <>
    <Header logo={reactLogo} title='Header Component'/> {/* Header with logo */}
    <div className='spacing'/>
    <Header  title='Header Component'/> {/* Header without logo */}
    </>
  )
}

// package.json

"scripts":{
    "dev": "vite --port 5001 --strictPort",
    "build": "tsc && vite build",
    "preview": "vite preview --port 5001 --strictPort"
}

Running yarn dev presents the output. We have a default logo shown if the user doesn't pass any icon.

To create a local build for this component, make sure to run a build first and then preview the component.
Observe that we have restricted this application to be deployed on port 5001.



yarn build && yarn preview

Upon execution, the main bundle, containing shared libraries and the exposed header component, becomes accessible at http://localhost:5001/assets/remoteHeader.js. This file is not generated when using the yarn dev command.

Observe that all the data is within the assets directory. This remoteHeader file and all of the bundles it references are just JavaScript files. Hence, they should be treated and deployed like assets.

Host Application with Videos.tsx Component

Now that our remote application is ready, let's create the host application and consume the Header component.
We'll develop a simple application displaying a list of video cards with title and author details.



// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import federation from "@originjs/vite-plugin-federation";

export default defineConfig({
  plugins: [
    react(),
    federation({
      name: "video_app",
      remotes: {
        headerApp: "http://localhost:5001/assets/remoteHeader.js",
        // consume other remote components
      },
      shared: ["react", "react-dom"],
    }),
  ],
  build: {
    target: "esnext",
    cssCodeSplit: false,
  },
});

In the Vite configuration, use the @originjs/vite-plugin-federation plugin to define headerApp as the remote points to the served location. Also, specify every shared library the host shares with the remote, ensuring uniformity across applications.

We can now extract and render the Header component as follows:



// App.tsx
import React from "react";
import VideoList from "./components/VideoList";
import { dataVideos } from "./utils/sampleData";
import customLogo from "./assets/react.svg";
import Header from "headerApp/Header";

const App: React.FC = () => {
  return (
    <div>
      <Header logo={customLogo} title="My Videos" />
      <VideoList videos={dataVideos} />
    </div>
  );
};

export default App;

The Header component is imported from headerApp/Header, accepting a custom logo and title string. The video list is rendered within the <VideoList> component.

Consuming Remote in a Webpack Application

Now that we have learned how to use module federation in Vite applications, let's understand how this remote component can be consumed by a host application created using Webpack.

Host Component - Blogs.tsx (Webpack Application)



// webpack.config.js

// ...rest of the config details

config.target: "es2020",
  experiments: {
    outputModule: true,
  },

config.plugins: [
    new ModuleFederationPlugin({
      name: "host_wp_blogs",
      library: { type: "module" },
      filename: "remoteHeader.js",
      remotes: {
        headerModule: "http://localhost:5001/assets/remoteHeader.js",
      },
      exposes: {},
      shared: {
        ...deps,
        react: {
          singleton: true,
          requiredVersion: deps.react,
        },
        "react-dom": {
          singleton: true,
          requiredVersion: deps["react-dom"],
        },
      },
    }),
    new HtmlWebPackPlugin({
      template: "./index.ejs",
      inject: false,
    }),
  ],

The remote component remoteHeader.js has been consumed within the Webpack's ModuleFederationPlugin. Note that we have named this remote as headerModule.
Considering that the remote application is built with ViteJS, include library: { type: "module" } in the module federation settings as Vite works on ECMAScript modules. Additionally, setup config.target to support modules. These changes ensure the proper linkage between the remote application built with ViteJS and the Webpack setup.



import React from "react";
import ReactDOM from "react-dom";

import "./index.css";
import BlogList from "./components/BlogList";
import { dataBlogs } from "./utils/sampleData";
import logo from "./assets/react.svg";
import HeaderModule from "headerModule/Header";
const Header = HeaderModule.default;

const App = () => (
  <div className="container">
    <Header logo={logo} title="My Blogs" />
    <BlogList blogs={dataBlogs} />
  </div>
);
ReactDOM.render(<App />, document.getElementById("app"));

In this scenario, the Header is imported as a module, accessing the default export assigned to a variable named Header.

Further options for extending the use of Module Federation

What an enriching learning experience! We've successfully created a remote module and integrated it into host applications. This example serves as a foundation for various extensions and adaptations.

In this scenario, the Video listing application (host) consumes two distinct remote components - Header and Subscribe Button. Interestingly, the same button component is utilized by yet another application.

Going a step further:

The header component serves a dual role as both a remote and a host application. It functions as a remote component for the Videos and Blogs application, while also serving as a host to consume the remote Login component.

Numerous possibilities exist for expanding the utilization of module federation in real-world scenarios. I would be interested in knowing the specifics of your implementation. Please share them in the comments section.

Conclusion

In this exploration of Micro-frontend Architecture through Module Federation using ViteJS, we've delved into a groundbreaking approach. Understanding the intricate dynamics between host and remote applications, we've unlocked the potential for seamless integration and autonomy.

This journey has shown how breaking down tasks into separate, cohesive parts can create strong, unified applications. As we wrap up, it's clear that the potential for innovative and scalable front-end development in Micro-frontend Architecture knows no bounds.

Thank you for joining me on this exploration today. Remember, continuous learning and adaptation are key in the ever-evolving landscape of software development.

Feel free to refer to my Github repo and show your support by starring it.

I hope you were able to take away something new and useful from this article! If you did, please drop a like on this post. 🙂

You can connect with me on Twitter, LinkedIn, and GitHub ✨

Peace ✌️

References

Introduction to React Server Components!

Supriya M — Sat, 29 Jul 2023 15:43:54 +0000

For a React developer, there are various ways to decide how we want to render a component. We could use the default client-side rendering (CSR) or choose between static site generation (SSG) and server-side rendering (SSR) based on the app requirements and interactivity. Now, we have got yet another way to work with React!

React Server Components is a new feature in React that allows developers to build more performant and flexible apps by blending server-side rendering with the interactivity of client-side JavaScript. In this beginner-friendly introduction blog, we will cover the basics of React Server Components and why they are useful.

This topic was recently introduced to me by the keynote speaker Tejas Kumar at the React Nexus 2023 Conference and by Tapas Adhikary at the JSLovers meet-up. Hence, I am here to share my understanding through this article!

What are React Server Components (RCS)?

React Server Components are a new feature in React that allows developers to write components that can be rendered on both the server and the client. This means that the initial render of the component would happen on the server, which can improve performance and reduce the time it takes for a user to see the content. After the initial render, the component can be hydrated on the client, which allows for interactivity and dynamic updates.

Why use React Server Components?

React Server Components allow you to render your React components on the server instead of the client. This has several benefits:

Zero Bundle Size: Server components don't bundle any code to the client. So if you use any third-party libraries inside a server component, it won't affect your client bundle size. This can significantly reduce your bundle size.
Faster Performance: Data fetching is faster since it happens on the server instead of the client. Server components have direct access to server data sources like databases and file systems.
Better SEO: Since the initial render of the component happens on the server, search engines can index the content more easily.
More flexible architecture: React Server Components allow developers to write components that can be rendered on both the server and the client, which can make it easier to build complex applications.
Code Splitting: Importing client components from server components act as a code-splitting. Only the client components needed for the initial render will be bundled, others will be loaded lazily.

So in summary, server components allow you to colocate your data-fetching logic with your UI components. This improves performance and bundle size, at the cost of some interactivity.

How to use React Server Components

To use React Server Components, you will need to use a framework that supports them, such as Next.js. The latest version of NextJS 13.4 uses RCS by default. You can then write components that can be rendered on both the server and the client. When the component is rendered on the server, it will return HTML that can be sent to the client. When the component is hydrated on the client, it will become interactive and dynamic.

To render a server component from your app, you simply import and render it like a normal component:

// components/ServerComponent.jsx
import React from "react";
import db from "db";
import User from "../models/UserModel";
import AddNewUser from "./AddNewUser";
import UserList from "./UserList";

export default aync function MyServerComponent() {
  const userList = await db.users.getAll();

  const addUserToDB = await (data) => {
    const newUser = new User(data);
    db.users.push(newUser);
  }

  return (
    <>
    <AddNewUser addUserToDB={addUserToDB}/>
    <UserList data={userList}/>
  )
};

Here we are fetching data from the database directly from the server component. This avoids the round-trip delay of making an API call from the client.

"use client";

import React, { useState } from "react";

const AddNewUser = ({ addUserToDB }) => {
  const [name, setName] = React.useState("");
  const [email, setEmail] = React.useState("");

  const handleSubmit = (e) => {
    e.preventDefault();
    addUserToDB(name, email);
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="text"
        placeholder="Name"
        value={name}
        onChange={(e) => setName(e.target.value)}
      />

      <input
        type="email"
        placeholder="Email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
      />

      <button type="submit">Add User</button>
    </form>
  );
};
export default AddNewUser;

Any component that starts with "use client" is considered a client component and will be rendered on the client. All other components are server components and will be rendered on the server.
Here AddNewUser is a client component since it starts with "use client". MyServerComponent and UserList do not have the directive, so they are server components.

When this component is rendered, MyServerComponent will run on the server and output HTML. This HTML will include the rendered result of <AddNewUser />. Then when the client receives this HTML, AddNewUser will hydrate and run on the client, gaining interactivity.

Things to note!

You can import Client Components inside Server Components.
You cannot import Server Components inside Client Components.
You can pass a Server Component as a child prop to a Client Component inside Server Component.

What can React Server Components NOT do?

RCS cannot use hooks provided by React like useState, useReducer, useEffect and so on, as they are rendered on the server.
RCS cannot use any utility functions that depend on browser-only APIs (ex: Local Storage)
RCS cannot be used when components need to have any sort of interactivity. This is where Client Component is used.

Conclusion

React Server Component is a new and exciting way to build modern, efficient, and scalable applications. They allow developers to render parts of their application on the server while maintaining the interactivity of a client-side app. Although it is still an experimental feature, RCS has a lot of potential and brilliant features that will undoubtedly improve the way modern apps will be built in the future, such as zero bundle size, faster performance, better SEO, and more flexible architecture. It is important to note that React Server Components are still under development and not recommended for production use yet. However, as developers, it is important to stay up-to-date with the latest features introduced to deliver the best results, and React Server Components are worth exploring 💪

I hope you were able to take away something new and useful from this article! If you did, please drop a like on this post. 🙂

You can connect with me on Twitter, LinkedIn, and GitHub ✨

Peace ✌

References

Simplify your lists using CSS Counters

Supriya M — Wed, 14 Jun 2023 12:22:47 +0000

If I was given a task to create an ordered list in HTML, this is how I would have implemented it.

...
<ol>
Ordered list
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
<li>Item 4</li>
</ol>
...

Further, If I had to extend it to a nested list, I would have implemented it as follows.

...
<ol>
Ordered list
<li><ol>
Item 1
<li>Sub item 1.1</li>
<li>Sub item 1.2</li>
</li></ol>
<li><ol>
Item 2
<li>Sub item 2.1</li>
<li>Sub item 2.2</li>
</li></ol>
<li><ol>
Item 3
<li>Sub item 3.1</li>
<li>Sub item 3.2</li>
<li>Sub item 3.3</li>
</li></ol>
</ol>
...

If I were to add another set of nesting, the same implementation technique would be repeated. I hope you are getting the point here. This would get tedious and redundant.

If you want to find an easier alternative to creating such lists, look no further than CSS counters! These powerful variables maintained by CSS allow you to automatically number headings, create dynamic pagination, and more. With CSS counters, you can easily adjust the appearance of content based on its location in a document. In this blog post, we'll explore how to use CSS counters to create numbered lists and other fun and interactive elements. So, let's get started!

An Introduction to CSS Counters

CSS counters are a powerful tool that allows you to automatically number elements in your HTML document. They are certain variables that can be incremented or decremented by CSS rules. You can use counters to automatically number headings, create ordered lists, and more. In this blog post, we will explore how to use CSS counters to create numbered lists.

Creating a Counter

To use a CSS counter, you must first define and initialize it with the counter-reset property. This property sets the initial value of the counter. You can define your own named counters, and you can also manipulate the counter's value with the counter-increment property. Here's an example of how to define and initialize a counter:

body {
  counter-reset: my-counter;
}

This code defines a counter named my-counter and initializes it to 0. You can then use this counter to automatically number elements in your HTML document.

Using the Counter

Once you have defined and initialized a counter, you can use it to automatically number elements in your HTML document. You can use the counter-increment property to increment the counter's value, and the content property to display the counter's value. Here's an example of how to use a counter to automatically number headings:

h1 {
  counter-increment: my-counter;
  content: counter(my-counter) ". ";
}

This code increments the my-counter counter every time an h1 element is encountered and displays the counter's value followed by a period and a space.

Here's how the HTML file would look.

<!DOCTYPE html>
<html>
  <head>
    <title>Parcel Sandbox</title>
    <meta charset="UTF-8" />
    <link rel="stylesheet" href="./src/styles.css" />
  </head>

  <body>
    <h1>Title for the first section</h1>
    <h1>Title for the second section</h1>
  </body>
</html>

Output 🖥️

Styling Numbered Lists

Now, let's move to the example of creating nested numbered lists using CSS counters.

CSS styles

ol {
  counter-reset: my-list;
  list-style-type: none;
}

li:before {
  counter-increment: my-list;
  content: counters(my-list, ".") ". ";
}

HTML Code

<!DOCTYPE html>
<html>
  <head>
    <title>Parcel Sandbox</title>
    <meta charset="UTF-8" />
    <link rel="stylesheet" href="./src/styles.css" />
  </head>

  <body>
    <h2>Contents of the book</h2>
    <ol>
      <li>Introduction</li>
      <li>How to get started
      <ol>
        <li>Process of thinking</li>
        <li>Creating points</li>
        <li>Adding structure
        <ol>
          <li>Breaking down into paragraphs</li>
          <li>Go through the notes</li>
        </ol>
        </li>
         <li>Rephrase and polish vocabulary</li>
      </ol>
      </li>
      <li>Revisiting the details</li>
      <li>Proof reading data</li>
    </ol>
   </body>
</html>

This code defines a counter my-list and initializes it to 0. It then sets the list-style-type property to none to remove the default numbering from the list. Finally, it uses the counter-increment and content properties to automatically number each list item.

Output 🖥️

Conclusion

Congratulations! You have learned a new skill that can save you time and effort when creating ordered lists and other numbered content. CSS counters are a powerful tool that allows you to automatically number elements in your HTML document. They are easy to use and can save you a lot of time and effort when creating ordered lists and other numbered content. With a little bit of CSS, you can create professional-looking numbered lists that are easy to read and understand.

If you found this article helpful, go ahead and give this post a like! Feel free to reach out to me on Twitter if you have any queries.

Peace ✌️

Setting up React-Native Development Environment

Supriya M — Sat, 22 Apr 2023 07:21:46 +0000

This article curates some of the issues that one can face while setting up react-native on their system for the first time.

I have been working with web development for quite some time. Having developed various web applications using ReactJS, I wanted to explore learning mobile application development. There are several ways of working with app development such as -

Android Development using Java or Kotlin
iOS Development using Swift or Objective-C
Cross-platform app development using Flutter or React-Native

However, the easiest way for me to get started was through React-Native (Since I am already familiar with ReactJS). This is how I started going through React-Native Documentation on how to set up the local environment to create my first application.

There are 2 ways in which I could install and build the app.

Using ExpoGo - It is a set of tools and services built around React Native that helps in getting started with the app development in a few minutes. In simple words, you can consider them to be equivalent to creating React applications on codesandbox.
Using CLI - If you are already familiar with mobile development, you may want to use React Native CLI. It requires Xcode or Android Studio to get started. If you already have one of these tools installed, you should be able to get up and running within a few minutes. If they are not installed, you should expect to spend about an hour installing and configuring them.

Although I am new to mobile development, I still went ahead with the traditional approach of installing using CLI. I followed the step-by-step approach mentioned on the documentation site. Since I was working on a Mac machine, I had an upper edge to configure the setup for both Android and iOS.

Configuration for iOS

I had NodeJS installed previously, I confirmed that the version was above Node 14.
I installed Watchman using Homebrew -> brew install watchman
I had to install the correct version of Ruby. The documentation's detailed explanation helped me understand that Ruby version 2.6.10 comes built-in by default on macOS 13. For our React-Native setup, we would need to use version 2.7.6 which can be installed using the Ruby version manager.
I went ahead with rbenv and installed rbenv 2.7.6 (This version is not maintained anymore, hence I upgraded to 2.7.8)
I had Xcode installed using the Apple AppStore. This takes a lot of time and memory on your Macbook. (~ 2 hours for me)
I made the mistake of continuing with the next steps of the setup when my Xcode was getting installed. This resulted in the failure of project creation with the following error message.

Another mistake that I realized was that I had installed cocoapods using rbenv, but they had to be installed using gem which is equivalent to NPM for node. This mistake cost me a lot of time. I tried uninstalling cocapods and re-installing using gem install cocapods but things did not work. I constantly saw the above error message.
I ended up removing Ruby from rbenv, deleted rbenv, and installed them from scratch. This time, I made sure that the installation of cocoapods is done correctly.
I was convinced by all the changes. I ran the command npx react-native@latest init AwesomeProject nevertheless, the same error message was still coming up.
The frustrated developer in me decided to take a break for the day and start off with a clean slate.
The next morning, I reset all my configurations and started following the documentation step-by-step. At the moment, Xcode was installed on my machine. However, it is only now that I realized that Xcode Command Line Tools were not yet installed.
Now, when I ran npx react-native@latest init AwesomeProject things worked like a charm ✨
My app was successfully created, and I was able cd AwesomeProject and view the project structure and files within them. I ran the following to test the build

  npm install
  npx react-native run-ios

With the execution of these commands, the app was ready in preview mode on the Xcode emulator. At this moment, I was quite happy and relieved that the setup was in working condition on at least one of the environments.

The next step was to check if everything ran well on the Android emulator.

Configuration for Android

I had NodeJS and Watchman installed previously (from the iOS setup)
I installed Java using homebrew

   brew tap homebrew/cask-versions
      brew install --cask zulu11

I downloaded Android Studio and followed the steps mentioned in the documentation meticulously.

- Next, I ran `npx react-native@latest init AwesomeProject` . The project was created with a few warnings.

    cd AwesomeProject
    npm install
    npx react-native run-android

I ran the above command to build the app on Android hoping everything would work well. But to my dismay, the build failed 🥺

As with any other developer, I looked up many threads on Google and StackOverflow. I tried to run all the potential solutions

$ react-native start --reset-cache
$ cd android
$ gradlew clean
$ ./gradlew installDebug

I tried the npx react-native run-android, but the issue was persistent. After reading through many articles, I found one GitHub gist that suggested selecting the specific version of Java8 or Java11.

$ brew install java11
$ java --version
# 11.0.7

By making this change, everything started to fall in place perfectly, and my app was bundled, built, and ready in preview mode on the Android emulator.

Finally, I was able to see the start app on both emulators!

At this moment I experienced the joy of fulfillment. The whole process of setting up took me 2 full days. There were a lot of instances where I could have given up and gone with the easier approach of setting up using ExpoGo. Nevertheless, I decided to take up each error as a challenge to understand the tight coupling between the operating system and its various dependencies.

This was one of the recent challenges that I faced as a developer, and I wanted to journal it as a form of this blog post. I hope you enjoyed reading about a small piece of my journey. If you did, please drop a like on this post 🙂

If you were struggling with a similar issue, and if this article helped you in some way, please drop a comment on which step were you facing the issue. If you are still facing any issues with your setup, feel free to reach out to me on Twitter.

Peace ✌

Pointer Events in JavaScript

Supriya M — Sat, 04 Mar 2023 12:43:18 +0000

We know that browsers work with the help of JavaScript, i.e. every browser has a JavaScript engine to execute the code to present the final web page. When writing code for the Web, there are a large number of Web APIs available. Today, we will understand how the pointer capture API works. Here is the list of all the APIs you may be able to use while developing a web application.

Introduction to Pointer Events

A decade ago, if you would have asked me to give an example of the pointer, I would have referred to the cursor pointer of a computer that is accessed through a mouse.

However, with the invention of touch-based devices and their support for the web, touch events were introduced as a part of web APIs. These touch events provided a similar behavior as that of the pointer event. Since then, many devices supported other types of pointing input devices, such as pen/stylus and touch surfaces, and extensions to the existing pointing device event models were needed.

According to the official documentation -

Pointer events are DOM events that are fired for a pointing device. They are designed to create a single DOM event model to handle pointing input devices such as a mouse, pen/stylus or touch (such as one or more fingers).

The pointer is a hardware-agnostic device that can target a specific set of screen coordinates. Thus, pointers can simplify creating web applications by providing a good user experience, regardless of the user's hardware.

Types of pointer events

Pointer events contain the usual properties of mouse events (client coordinates, target element, button states, etc.) in addition to new properties for other forms of input: pressure, contact geometry, tilt, etc.

Pointer event	Similar mouse event
`pointerdown`	`mousedown`
`pointerup`	`mouseup`
`pointermove`	`mousemove`
`pointerover`	`mouseover`
`pointerout`	`mouseout`
`pointerenter`	`mouseenter`
`pointerleave`	`mouseleave`
`pointercancel`	-
`gotpointercapture`	-
`lostpointercapture`	-

In fact, the PointerEvent interface inherits all of the MouseEvent properties, thus facilitating the migration of content from mouse events to pointer events.

You can refer to MDN Docs to learn in detail about the above-mentioned events. In this blog, we are going to focus on one of the special features of pointer events.

Pointer Capture Event

Pointer capture allows the events for a pointer to be retargeted to a particular element other than the normal hit test result of the pointer's location.

The idea is very simple but may seem quite odd at first, as nothing like that exists for any other event type. We will learn this concept with a simple example. When I learnt about pointer capture events using this example, I was amazed by the simplicity it provides to the end users! Thus, I wanted to share this with a wider audience😀.

I'm sure most of you would have watched youtube videos on your phone. While watching, if you wanted to seek a particular timestamp, all you need to do is simply drag the red dot on the timeline and move to the appropriate timestamp value. The next time you perform this activity, observe if you are always touching the red dot. Most of the time, you would have touched the red dot but moved away from this target element. That's exactly where "Pointer Capture Event" comes into the picture.

You can test the demo of pointer capture on https://webapis-playground.vercel.app/demo/pointer-capture

I built this feature as one of my early contributions to the open source software (OSS).

Let's understand how the code works!

For the above example, I have used React and Tailwind. I have kept the pointer event functionality in a separate JavaScript module since the application is mainly focusing on Web APIs.

JavaScript File: https://github.com/atapas/webapis-playground/blob/master/src/modules/apis/pointer-capture/index.ts

React File: https://github.com/atapas/webapis-playground/blob/master/src/modules/demos/pointer-capture/index.tsx

The main elements to focus the React file are:

 <div
          id="gray-timeline"
          className="tw-h-5 tw-w-full tw-bg-gray-400 tw-mb-5 tw-flex tw-items-center tw-relative tw-cursor-pointer"
          style={{ touchAction: isCapture ? 'none' : 'auto' }}
          onPointerUp={e => run.onPointerUp(e, isCapture)}
          onPointerDown={e => run.onPointerDown(e, isCapture)}
          onPointerMove={run.onPointerMove}
        >
          <div
            id="red-timeline"
            className="tw-relative tw-bg-red-600 tw-h-full tw-rounded-r-full tw-w-7"
          >
            <div
              id="red-dot"
              className="tw-absolute tw-bg-red-700 tw-h-7 tw-w-7 tw-rounded-full tw--top-1 tw-left-4"
            ></div>
          </div>

The main div container with the id="gray-timeline" has 3 events attached:

onPointerDown to start capturing the pointer event
onPointerMove to accurately provide the motion of the captured event (red dot) even though the touch pointer is not within the target element
onPointerUp to stop capturing the pointer event

By adding the pointer events on the parent container, the id="red-timeline" and id="red-dot" would work smoothly to capture and end the pointer event's behavior.

I have also added a react state isCapture. This would ensure that the pointer event is "captured" only when isCapture=true. You can set this value to false by toggling the switch to "Turn off".

Moving on, let's understand the behavior defined through these attached events.

let flag = false;

function onPointerDown(event: React.PointerEvent<Element>, isCapture: boolean) {
  const timeline = document.querySelector('#red-timeline') as HTMLElement;
  if (isCapture) {
    timeline.setPointerCapture(event.pointerId);
  }
  flag = true;
  onPointerMove(event);
}

I am using a global variable flag to identify if the pointer is under capture. In the onPointerDown function, we find the target element i.e. the red-timeline element which needs to be captured. Based on the isCapture state value, we start capturing the pointer within this element by invoking the setPointerCapture.

setPointerCapture takes one parameter which is the pointerId of the given pointer event.

function onPointerMove(event: React.PointerEvent<Element>) {
  const timeline = document.querySelector('#red-timeline') as HTMLElement;
  if (flag) {
    const rect = timeline.getBoundingClientRect();
    timeline.style.width = `${event.clientX - rect.left}px`;
    const childTag = document.querySelector('#dot') as HTMLElement;
    childTag.style.left = `${event.clientX - rect.left - 20}px`;
  }
}

Once the onPointerDown is fired and the pointer event is captured, as I start moving the pointer across the screen, the onPointerMove event is fired. In this function, we are capturing the latest value of the pointer and set the style attributes of the timeline element. It is because of this function you are able to see a smooth transition of the red timeline getting updated along with the movement of the red-dot.


function onPointerUp(event: React.PointerEvent<Element>, isCapture: boolean) {
  const timeline = document.querySelector('#red-timeline') as HTMLElement;
  if (isCapture) {
    timeline.releasePointerCapture(event.pointerId);
  }
  flag = false;
}

The onPointerUp event is fired when we stop moving the "red dot" and release the touch (or click). At this moment, we release the pointer capture event and fire onPointerUp function. Here, we invoke releasePointerCapture to stop capturing the event any further.

Link to the demo application

You can test the demo of pointer capture on https://webapis-playground.vercel.app/demo/pointer-capture

Check out the demo of other Web APIs at https://webapis-playground.vercel.app/

If you learnt something new today and found this article exciting, go ahead and give this post a like!

Feel free to reach out to me on [Twitter](https://twitter.com/supminn) if you have any queries.

Peace ✌️

Building FinSaver for Hack-R-Play 😎

Supriya M — Wed, 19 Oct 2022 14:54:12 +0000

Introduction

Being a developer, I love to create new projects! Sometimes, it's the concept of the application that motivates me to get started. Sometimes I work on applications to understand the core concepts of the libraries. Thus, I tend to have a huge to-do list of pending projects 🙈.

One of the ways I found to beat the procrastination and finish what I started was by participating in a hackathon. Hackathons help us stay accountable for building a full-fledged application in a short duration of time! Currently, I am participating in a hackathon called Hack-R-Play which is organized by ReacPlay and sponsored by Nhost.

What is Hack-R-Play

In the open-source community, October is officially known as the Hacktoberfest season. Hacktoberfest is Digital Ocean's annual event that encourages people to contribute to open source throughout October. They have successfully been conducting it for the past 9 years. This year, ReacPlay has decided to organize a hackathon as a part of the hacktoberfest celebration 🥳.

Hack-R-Play provides a platform that helps us hack, build, learn, and simultaneously contribute to open source. Here's an article that talks in detail about this hackathon.

The idea for my project

Technology has made life easier to such an extent that we believe to be heavily dependent on it. With the popularity of smartphones shooting up exponentially and the affordability of the internet connection, it has become a norm to have everything at our fingertips. Be it emails, meetings, notes, documents, media, etc...

With UPI coming into the picture, spending money has become even more seamless, and tracking your expenses from various instruments has become a tedious task. Keeping this as the motive, I decided to develop an application to track and maintain personal expenses.

FinSaver is a web application that helps you track all your income and expenses. It's developed using the mobile-first approach of responsive design to provide a smooth experience on all kinds of devices.

Features of FinSaver

Since the application deals with financial data, only registered users can use FinSaver. User authentication is possible through email and password.

Once the user is logged in, we persist this data to provide an SSO-like feature. Authenticated users get a private space to manage their expenses.
This user is led to the Daily Report view, where he/she could view their income and expenses for the given date.

Users have the option to view their daily, monthly, and yearly summaries using the respective navigation buttons.

On the Daily view, users have the option to add a new entry by clicking the + icon on the bottom right. Expense is selected by default which could be changed to Income as and when needed. There is an option available to add description details for income or expenses.

On the Daily view, users can select a particular date to backfill data. Similar options are available on Monthly and Yearly views too.

Upcoming features

Ability to view and download the PDF version for monthly and yearly logs
Provide categorization of income and expenses.
Graphical representation and analytics of expenses from different categories.

My learnings and experience

I have been working with ReactJS for about 2 years. When NextJS was launched, I was eager to learn about the benefits of creating apps with it. The "Learn" section of their documentation helped me get the crux of NextJS. However, I hadn't used them on any project until now. Since Hack-R-Play's guidelines mentioned using React-based libraries, I decided to practically put my understanding of NextJS into use in this project! One of the features of NextJS that I liked is the way they have integrated routing.
I found ReactPlay to be one of the warmest communities to accept and encourage me to get started with an open-source contribution. I have been engaged in interesting discussions while enhancing my learning. Kudos to Tapas and the team for creating this platform.
Another reason for me to eagerly participate in this hackathon was to get started with nhost. I must applaud their commendable documentation. It was butter smooth for me to get started and immediately feel confident about how I wanted to structure the backend for my application. The option of providing custom hooks for the NextJS application is the cherry on the cake moment for me 😃. Additionally, the integration with Hasura console made it very easy for me to work with GraphQL API.
Understanding user roles and permissions was something new that I learnt. I was able to customize authorization for a different set of users based on their roles.
Overall, I gained new experiences, built a fully functioning application, and had loads of fun while coding and debugging 😛.

My final thoughts

If you want to get started with open source, ReactPlay is a wonderful community to do so!

If you found this article exciting, go ahead and give this post a like!

Here's the link to the expense tracker application that I have built => FinSaver. I would love to know your feedback and suggestions. This is an open-sourced project as well! So, if you'd like to contribute, I would encourage you to read more about it over here.

Feel free to reach out to me on Twitter if you have any queries.

Peace ✌️

What are Progressive Web Applications? Get started with creating PWA

Supriya M — Sat, 25 Jun 2022 12:52:31 +0000

This article is special to me! I always wanted to create mobile applications, but I couldn't decide whether to get started with Android development or iOS development. A few years ago, I found out about Flutter which helps us create platform-independent applications. It is around the same time that I was learning web development and found out about Progressive Web Apps (PWA). PWA provides the capability to use a web application as a full-fledged mobile application.

This is going to be an elaborate article explaining how to create PWA efficiently. Let's get started!

Introduction to PWA

Progressive Web Apps (PWAs) are web apps that use new capabilities to provide a more integrated experience and can be installed as a mobile application. Since it's a web app, it can reach anyone, anywhere, on any device, all with a single codebase. Once installed, a PWA looks like any other app, such as:

It has an icon on the home screen, app launcher, launchpad, or start menu.
It appears when you search for apps on the device.
It opens in a standalone window, separated from a browser's user interface.
It has access to higher levels of integration with the OS, for example, URL handling or title bar customization.
It can work offline.

A Progressive Web App includes features from both worlds (web and native apps).

They are responsive and work with many different screen sizes.
They function just like normal Native Apps.
The updates are independent, you don't need to visit the play store for an update.
They're built with common web technologies.
They're fast and lightweight.
They work offline unlike other apps.
They are discoverable via a search engine.
They are easily installable.
Low maintenance cost.

Although Progressive Web Apps are applications that can be installed from the web browser, PWA can also be listed on app stores as an optional distribution channel. For the latter case, we must follow all store rules and requirements, but we will still keep some of the advantages of a PWA.

PWABuilder provides the capability of creating android/iOS build packages for a PWA. These packages could then be published on the app store.

Some good examples of top companies who have their products as PWAs include Twitter, Pinterest, Uber, Tiktok, Spotify, Flipkart, etc.

Get Started with PWA Development

The first characteristic of a progressive web app is that it must work on all devices and must enhance on devices and browsers that allow it. Therefore, you could develop a web app using traditional HTML5 and JavaScript that simulates the retrieval of data from a server API. Alternatively, SPA (Single Page Applications) could be created using Angular, React, Vue, etc.

Now, to convert this simple web application into a PWA, we would need to include the following files.

Manifest
Service Worker

I have created a simple weather app in React and converted it into a PWA by adding the above-mentioned files. You can view the code on this repository.

Manifest file

Each PWA should include a single manifest per application, typically hosted in the root folder, and linked on all HTML pages the PWA can be installed from. Its official extension is .webmanifest, so you could name your manifest something like app.webmanifest. While the recommended extension is .webmanifest, any filename will work as long as it's delivered with the application/manifest+json content type or another JSON-valid content type, such as text/json. As such, many PWAs, particularly older ones, use manifest.json instead.

This file contains information about how the PWA should appear and function. It allows us to determine the name, description, icon, colors, and other features of the PWA. With this manifest file, it is possible to run the web app in full-screen mode as a standalone application.

Here's an example of a manifest file:

{
"short_name": "MyPWA",
"name": "My Progressive Web App",
"description": "Creating a PWA that is compatible with all the devices",
"theme_color": "#eb5252",
"background_color": "#e840cf",
"display": "fullscreen",
"start_url": "index.html",
"scope": "/",
"orientation": "portrait",
"icons": [
    {
        "src": "images/AppIcon-48-48.png",
        "type": "image/png",
        "sizes": "48x48"
    },
    {
        "src": "images/AppIcon-96-96.png",
        "type": "image/png",
        "sizes": "96x96"
    },
    {
        "src": "images/AppIcon-192-192.png",
        "type": "image/png",
        "sizes": "192x192"
    }
   ],
  }

Let’s break down and understand what each field depicts within the manifest file:

short_name is a human-readable name for the application. In Chrome for Android, this is the name accompanying the icon on the home screen.
name is also a human-readable name for the application and defines how the application will be listed.
description provides a general description of the web application.
theme_color is the default theme color for the application. On Android, this is also used to color the status bar.
background_color defines the background color of the web application. In Chrome, it also defines the background color of the splash screen.
start_url is the starting URL of the application.
scope changes the navigation scope of the PWA, allowing you to define what is and isn't displayed within the installed app's window. For example, if you link to a page outside of the scope, it will be rendered in an in-app browser instead of within your PWA window.
display defines the default display mode describing how the OS should draw the PWA window. They can take either fullscreen, standalone, minimal-ui or browser as value.
orientation defines the default orientation for the web application: portrait or landscape.
icons define an array of icon objects with src, type, sizes, and optional purpose fields, describing what images should represent the PWA. In Chrome for Android, the icon will be used on the splash screen, on the home screen, and in the task switcher.

Linking your manifest
To make the browser aware of your web app manifest, you need to link it to your PWA using <link> HTML element and the rel attribute set to manifest on all of your PWA's HTML pages. This is similar to how you link a CSS stylesheet to a document.

<html lang="en">
  <title>This is my first PWA</title>
  <link rel="manifest" href="/app.webmanifest" />
</html>

Note: If your PWA includes multiple HTML pages, make sure to link its manifest to all of them.

Once the manifest file is linked to the document, you should be able to verify it on the 'Application' tab of the dev tools.

Service workers

This is one of the key technologies behind PWAs. They help support your app to work offline, and they perform advanced caching and run background tasks. Service workers can complete tasks even when your PWA is not running.
Some other functions associated with service workers include:

Sending push notification
Badging icons
Running background fetch tasks etc.

Before the service worker takes control of your page, it must be registered for your PWA. That means the first time a user comes to your PWA, network requests will go directly to your server because the service worker is not yet in control of your pages.

After checking if the browser supports the Service Worker API, your PWA can register a service worker. When loaded, the service worker sets up as a shop between your PWA and the network, intercepting requests and serving the corresponding responses.

if ("serviceWorker" in navigator) {
  navigator.serviceWorker
    .register("/sw.js")
    .then(() => {
      console.log("Service worker registered!");
    })
    .catch((error) => {
      console.warn("Error registering service worker: ");
      console.warn(error);
    });
}

The above code runs on the main thread and does the following:

Since the user's first visit to a website occurs without a registered service worker, it waits until the page is fully loaded before registering one. This avoids bandwidth contention if the service worker precaches anything. Though the service worker is well-supported, a quick check helps to avoid errors in browsers where it isn't supported.
When the page is fully loaded, and if a service worker is supported, register /sw.js.

Some key things to understand are:

Service workers are only available over HTTPS or localhost.
If a service worker's contents contain syntax errors, registration fails and the service worker is discarded.
Service workers operate within a scope. Here, the scope is the entire origin, as it was loaded from the root directory.
When registration begins, the service worker state is set to installing.

Once registration finishes, installation begins.

Installation

A service worker fires its install event after registration. install is only called once per service worker, and won't fire again until it's updated. A callback for the install event can be registered in the worker's scope with addEventListener.

// /sw.js
const CACHE_NAME = "MyCacheName_v1";

self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      // Add all the assets in the array to the 'MyCacheName_v1'
      // `Cache` instance for later use.
      return cache.addAll(["/css/style.css", "/js/index.js"]);
    })
  );
});

This creates a new Cache instance named MyCacheName_v1 and precaches assets.
After the cache is created, an array of asset URLs are precached using its asynchronous addAll method.

The other half of a caching strategy is the service worker's fetch event.

Fetching

self.addEventListener('fetch', async (event) => {
    // Open the cache
    event.respondWith(caches.open(CACHE_NAME).then((cache) => {
      // Respond with the file from the cache or from the network
      return cache.match(event.request).then((cachedResponse) => {
        return cachedResponse || fetch(event.request.url).then((fetchedResponse) => {
          // Add the network response to the cache for future visits.
          // Note: we need to make a copy of the response to save it in
          // the cache and use the original as the request response.
          cache.put(event.request, fetchedResponse.clone());

          // Return the network response
          return fetchedResponse;
        }).catch(() => caches.match("offline.html");
      });
    }));
});

When a file needs to be loaded, the above code checks if the file is in the service worker cache. If it is available, then the file is served from the cache. If not, it would fetch the file from the network, store the response in the cache, and return the network response.

If the user is offline or facing any network issues, then the file offline.html would be loaded as a fallback to the user. This file could either have a static template to inform the user that they are offline or it could have some dynamic content such as the dinosaur game on google.

There are various caching strategies available while making this fetch event call. They are:

Stale While Revalidate uses a cached response for a request if it's available and updates the cache in the background with a response from the network. Therefore, if the asset isn't cached, it will wait for the network response and use that. It's a fairly safe strategy, as it regularly updates cache entries that rely on it. The downside is that it always requests an asset from the network in the background.
Network First tries to get a response from the network first. If a response is received, it passes that response to the browser and saves it to a cache. If the network request fails, the last cached response will be used, enabling offline access to the asset.
Cache First checks the cache for a response first and uses it if available. If the request isn't in the cache, the network is used and any valid response is added to the cache before being passed to the browser.
Network Only forces the response to come from the network.
Cache Only forces the response to come from the cache.

Click here to learn more about them.

Apart from the 2 events that we discussed so far, service workers have another event called activate.

Activating

If registration and installation succeed, the service worker activates, and its state becomes 'activating'. When an updated service worker is installed and the waiting phase ends, it activates, and the old service worker is discarded. A common task to perform in an updated service worker's activate event is to prune old caches. Remove old caches by getting the keys for all open Cache instances with caches.keys and deleting caches that aren't in a defined allow list with caches.delete

// Activate the Service Worker
// remove all the previous versions and keep the latest data.
self.addEventListener("activate", (event) => {
  // Specify allowed cache keys
  const cacheAllowList = ["MyCacheName_v2"];

  // Get all the currently active `Cache` instances.
  event.waitUntil(
    caches.keys().then((keys) => {
      // Delete all caches that aren't in the allow list:
      return Promise.all(
        keys.map((key) => {
          if (!cacheAllowList.includes(key)) {
            return caches.delete(key);
          }
        })
      );
    })
  );
});

Old caches don't tidy themselves. We need to do that ourselves or risk exceeding storage quotas. Since 'MyCacheName_v1' from the first service worker is out of date, the cache allow list is updated to specify 'MyCacheName_v2', which deletes caches with a different name.

The activate event will finish after the old cache is removed. At this point, the new service worker will take control of the page, finally replacing the old one!

Well, that was a lot of learning 💪. Congratulations, you have successfully created your first PWA. If you observe, we have done a lot of manipulations around the service worker. This is when it's good to know about the workbox.

What is Workbox

At this point, service workers may seem tricky. There are lots of complex interactions that are hard to get right. Network requests, Caching strategies, Cache management, and Precaching, It's a lot to remember. This doesn't make service workers an ill-designed technology; it works as intended, and solves hard problems.

Good abstractions make complex APIs easier to use. That's where Workbox comes in. Workbox is a set of modules that simplify common service worker routing and caching. Each module available addresses a specific aspect of service worker development. Workbox aims to make using service workers as easy as possible while allowing the flexibility to accommodate complex application requirements where needed.

We shall discuss more on workbox in my upcoming blog. However, if you wish to get started, then this is the best place to refer.

Thank you for reading through this article. I hope it provided a good understanding of how to get started with converting your web apps into PWA. Please share your thoughts/queries in the comments section or on Twitter. If this blog is interesting to you, I would appreciate it if you could give this post a like (with your favorite emoji 😁).

Peace ✌

Resources

Introduction to web performance

Supriya M — Fri, 17 Jun 2022 17:14:29 +0000

If you are a web developer, I would assume that you have a good understanding of HTML, CSS, and JS; and you have created a few projects using these technologies. The next step is to get started with the basics of web performance.
It is an important aspect a web developer must keep in mind while developing their web apps. At the end of the day, the consumer must have a good user experience and that is what ultimately matters.

In this era, everything has moved digital and the web has become more powerful than ever.

What is web performance

Web performance is all about making websites fast, including the ways of making slow processes seem fast. It involves loading a site quickly, allowing the user to start interacting with it faster, and offer reassuring feedback if something is taking time to load (e.g. a loading spinner)? Are scrolling and animations smooth?

Web performance includes both objective measurements like time to load, frames per second, and time to interactive, and subjective experiences of how long it felt like it took the content to load.

Lighthouse

Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, SEO, and more.

There are various metrics that contribute to calculating the lighthouse score. Some of the top considerations are as follows:

First Contentful Paint
Largest Contentful Paint
Time to Interactive
Total Blocking Time
Cumulative Layout Shift
First Input Delay

Let's understand them one by one.

First Contentful Paint (FCP)

FCP measures how long it takes the browser to render the first piece of DOM content after a user navigates to your page. Your FCP score is a comparison of your page's FCP time and FCP times for real websites, based on data from the HTTP Archive.
LCP measures when a user perceives that the largest content of a page is visible. The metric value for LCP represents the time duration between the user initiating the page load and the page rendering its primary content.

Once Lighthouse is done gathering the performance metrics (mostly reported in milliseconds), it converts each raw metric value into a metric score from 0 to 100 by looking where the metric value falls on its Lighthouse scoring distribution. To provide a good user experience, sites should strive to have a First Contentful Paint of 1.8 seconds or less.

Largest Contentful Paint (LCP)

LCP metric reports the render time of the largest image or text block visible within the viewport, relative to when the page first started loading. To provide a good user experience, sites should strive to have the Largest Contentful Paint of 2.5 seconds or less.

<img> elements, <svg> tag, <video> elements, background images loaded via url() function are the type of elements considered for LCP.

While calculating LCP, it takes into account the size of the element that's visible to the user within the viewport. If any of the above-mentioned elements extend outside the viewport, those portions would not contribute to the element's size. For all elements, any margin, padding, or border applied via CSS is not considered.

Time to Interactive (TTI)

The TTI metric measures the time from when the page starts loading to when its main sub-resources have loaded and it is capable of reliably responding to user input quickly.

Techniques like server-side rendering (SSR) can lead to scenarios where a page looks interactive (that is, links and buttons are visible on the screen), but it's not actually interactive because the main thread is blocked or because the JavaScript code controlling those elements hasn't loaded.

Total Blocking Time (TBT)

TBT mertic measures the total amount of time between FCP and TTI where the main thread was blocked for long enough to prevent input responsiveness.

As we discussed above, when users try to interact with a page that looks interactive but actually isn't, it's likely that the user will notice the delay and perceive the page as sluggish or janky.

Thus, try to minimize the difference between FCP and TTI for good user interactivity on your web pages.

TBT is a great companion metric for TTI because it helps quantify the severity of how non-interactive a page is prior it to becoming reliably interactive.

Cumulative Layout Shift (CLS)

CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifespan of a page. To provide a good user experience, sites should strive to have a CLS score of 0.1 or less.

A layout shift occurs any time a visible element changes its position from one rendered frame to the next. The culprit might be an image or video with unknown dimensions, a font that renders larger or smaller than its fallback, or a third-party ad or widget that dynamically resizes itself.

Note that layout shifts only occur when existing elements change their start position. If a new element is added to the DOM or an existing element changes size, it doesn't count as a layout shift—as long as the change doesn't cause other visible elements to change their start position.

First Input Delay (FID)

FID measures the time from when a user first interacts with a page (i.e. when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.
To provide a good user experience, sites should strive to have a First Input Delay of 100 milliseconds or less.

The main aspect of Web 2.0 is the ability of a user to interact with the web page. Thus, FID is an important metric in web performance.

These were some of the important metrics to consider while working with web performance. I created this blog as documentation of my learnings. Here's the tweet about how I improved the lighthouse score of my portfolio website.

My Tweet

This is what happens when you get to have a productive session @neogcamp!
Thank you @PKodmad for helping us understanding @____lighthouse
Worked on improving my portfolio site😁#webPerf #newLearnings #webDev #neogcamp #coding pic.twitter.com/ALbTQYnnYt
— Supriya Minnasandram 👩‍💻 (@supminn) August 21, 2021

And this is the latest lighthouse report generated today!

Thank you for reading through this article. Let me know which topic should I explore and write about in the next article. You could share your thoughts in the comments section or DM me on Twitter. If this blog is interesting to you, I would appreciate it if you could give this post a like (with your favorite emoji 😁).

Peace ✌

Resources

Polyfill for Promisify

Supriya M — Sat, 04 Jun 2022 12:45:35 +0000

In this article, we will learn how to write our implementation of util.promisify(). Before we could get started, there are two things which you must be aware of.

What a callback hell is and how we could come out of it using promise. - Read more
Understanding the implementation of promises in JavaScript. - Read more

Introduction

Promisification helps in dealing with callback-based APIs while keeping code consistent with promises. It converts a function that accepts a callback into a function that returns a promise.

Such transformations are often required in real life, as many functions and libraries are callback-based. Thus, promises are more convenient, so it makes sense to promisify them.

Let's dive into the code and understand this implementation.

//function defintion
const positiveSum = (num1, num2, callback) => {

  if (num1<0 || num2<0) {
    return callback(new Error("Negative numbers are not accepted"), null);
  }
  return callback(null, num1 + num2);
}

//function implementation
positiveSum(2, 3, (err, result) => {
  if (err){
    console.error(err);
  } else {
    console.log(result); 
  }
})

//output:
// 5

We define a function positiveSum that accepts two positive numbers and a callback function. This callback function takes two parameters, error and result.
If either of the two numbers is negative, a new error object is created and passed as the first argument to the callback function. Otherwise, the callback function is returned with the summation of these two numbers that is passed as the second argument within the callback.

We can convert positiveSum to return a promise using util.promisify() as follows:

const util = require('util');

const calculateSum = util.promisify(positiveSum);

calculateSum(2,3).then((res) => {
  console.log(res); // 5
}).catch((err) => {
  console.error(err);
})

Creating our version of promisify

If we observe the above code snippet, promisify accepts a callback as an argument.

Step1 - Creating myPromisify that accepts a callback

const calculateSum = myPromisify(positiveSum);

const myPromisify = (callback) => {
    // implementation logic
}

We also observe that calculateSum is taking two arguments, thus our implementation must return a function that takes two arguments.

Step 2 - Returning a function which could have multiple args

const myPromisify = (callback) => {
    return function(...args){
        // implmentation logic
    }
}

In the above code, you can see that we are spreading arguments because we do not know how many arguments are present within the original function. args will be an array containing all the arguments.

When you call calculate(2, 3) you’re actually calling (...args) => {}. In the implementation above it returns a promise. That’s why you’re able to use calculate(1, 1).then().catch().

Step 3 - Adding a promise to this returning function

const myPromisify = (callback) => {
  return (...args) => {
    return new Promise((resolve, reject) => {

    })
  }
}

Now, we would need to define when to call resolve and reject based on the callback that we pass to positiveSum.

Step 4 - Implementing outcomes of a promise

const myPromisify = (fncallback) => {
  return (...args) => {
    return new Promise((resolve, reject) => {
      function myCallback(err, result) {
       if (err) {
         reject(err)
       }
       else {
         resolve(result);
        }
      }
   })
  }
}

Currently, args[] consists of the arguments passed by calculateSum(2, 3) and not the callback function. So we need to add myCallback(err, result) to the args[] so that positiveSum will call it accordingly as we are tracking the result in myCallback.

Step 5 - Adding myCallback to args[]

const myPromisify = (callback) => {
   return (...args) => {
     return new Promise((resolve, reject) => {
       function myCallback(err, result) {
         if (err) {
           reject(err)
         }
         else {
          resolve(result);
         }
        }
        args.push(myCallback)
        callback.apply(this,args);
      })
  }
}

callback.apply(this, args) will call the original function under the same context with the arguments positiveSum(2,3,myCallback). Then our promisify function should be able to resolve/reject accordingly.

Customize further

The above implementation will work when the original function expects a callback with two arguments, (err, result). That’s what we encounter most often. Then our custom callback is in the correct format and promisify works great for such a case.

But what if the original function expects a callback with more arguments like callback(err, result1, result2, ...)?

In order to make it compatible with that, we need to modify our myPromisify function that will be an advanced version.

const myPromisify = (fn) => {
   return (...args) => {
     return new Promise((resolve, reject) => {
       function customCallback(err, ...results) {
         if (err) {
           return reject(err)
         }
         return resolve(results.length === 1 ? results[0] : results) 
        }
        args.push(customCallback)
        fn.call(this, ...args)
      })
   }
}

Example: A function to calculate the sum and product of 2 numbers

const positiveSumAndProduct = (num1, num2, callback) => {

 if (num1<0 || num2<0) {
    return callback(new Error("Negative numbers are not accepted"), null);
  }

  const sum = num1 + num2;
  const product = num1 * num2;
  return callback(null, sum, product);
}
const mathPromise = myPromisify(positiveSumAndProduct)
mathPromise(2, 3).then(res => console.log(res)) 

//output
// [5, 6]

Hurray! we have successfully implemented our version of util.promisify. Polyfills are one of the questions asked during interviews. I hope this article was helpful

Reach out to me on Twitter if you have any queries. Happy learning! 💻

Peace ✌

Combining multiple reducers in React.

Supriya M — Fri, 18 Mar 2022 15:46:12 +0000

In this article, we shall discuss combining multiple reducers to create a main reducer. We would then use the main reducer as an argument to useReducer() hook using react's functional components.
Before we could deep dive into this topic, I assume that you are familiar with how useReducer hook works and have a brief understanding of combineReducers(reducers) in Redux. Here's the documentation link if you would want to go through them. useReducer in React | combineReducers in Redux.

The state management functionality of Redux and useReducer are similar. When the user triggers an action, this call is dispatched to the reducer. The required state modifications are performed by the reducer, and the latest values are present in the view. Redux makes use of a store in addition to how useReducer works.

While building a smaller project, useContext + useReducer is preferred over Redux for state management.

As Dan Abramov says "I would like to amend this: don't use Redux until you have problems with vanilla React."

Why do we need multiple reducers?

While creating a react application, it's completely a programmer's decision to either have a single reducer or to break it down into smaller reducers. I went ahead with this approach for the following reasons:

Taking the example of an eCommerce application, we could have one reducer to manage the user's cart/wishlist, another to contain product details, another to handle the user's address, and so on.
Dividing reducers based on a given functionality is helpful while writing test cases for each of these features.
Having smaller reducers increases the readability of code.
Smaller reducers would mean lesser lines of code for a single function, thus keeping it in line with the clean coding practices.
We could create smaller reducers and maintain a separate folder structure in this approach.

Implementation with an example application

Let us understand how we could create multiple reducers with an example. We would be using the implementation of an eCommerce application. In this application, we have the following functionalities:

Set the list of products on page load
Sort the products based on price
Add a product to the wishlist
Remove a product from the wishlist

I have purposely restricted myself with these functionalities and not introduced the cart functionality. We shall discuss this in the last part of the article.

Link to CodeSandBox

We have a single reducer which is named dataReducer.js.

// dataReducer.js

import { ActionTypes } from "./actions";
import { toast } from "react-toastify";

export const initialState = {
  products: [],
  sortBy: "",
  wishlist: [],
};

export const reducer = (state, action) => {
  switch (action.type) {
    case ActionTypes.SET_PRODUCTS: {
      return {
        ...state,
        products: action.payload,
      };
    }
    case ActionTypes.SORT_BY_PRICE: {
      return {
        ...state,
        sortBy: action.payload.value,
      };
    }
    case ActionTypes.ADD_TO_WISHLIST: {
      let updatedList = [...state.wishlist];
      const productInWishlist = updatedList.find(
        (product) => product.id === action.payload.id
      );
      if (productInWishlist) {
        return state;
      }
      updatedList = updatedList.concat(action.payload);
      toast.success("Book added to wishlist");
      return {
        ...state,
        wishlist: updatedList,
      };
    }
    case ActionTypes.REMOVE_FROM_WISHLIST: {
      let updatedList = [...state.wishlist];
      const productInWishlist = updatedList.find(
        (product) => product.id === action.payload.id
      );
      if (!productInWishlist) {
        return state;
      }
      updatedList = updatedList.filter(
        (product) => product.id !== action.payload.id
      );
      toast.success("Book removed from wishlist");
      return {
        ...state,
        wishlist: updatedList,
      };
    }
    default:
      return state;
  }
};

SET_PRODUCTS sets the products data which is present within data/productsData.js.
SORT_BY_PRICE sets the value to either LOW_TO_HIGH or 'HIGH_TO_LOW`
ADD_TO_WISHLIST adds a product to the wishlist and shows a success toast message.
REMOVE_FROM_WISHLIST removes a product from the wishlist and shows an appropriate toast message.

Decide on how to divide the reducer

From this example, we could easily divide the above-mentioned reducer into 2 - one to handle product-related manipulations and the other to handle the wishlist functionalities.

We are going to do just that 🌞

Let us create a new file within the reducers file named productReducer.js. This file would contain the initial state for products as well as the reducer that contains the product manipulations.

Link to CodeSandBox

`js
import { ActionTypes } from "./actions";

export const productState = {
products: [],
sortBy: "",
// could have other properties related to products.
};

export const productsReducer = (state = productState, action) => {
switch (action.type) {
case ActionTypes.SET_PRODUCTS: {
return {
...state,
products: action.payload,
};
}
case ActionTypes.SORT_BY_PRICE: {
return {
...state,
sortBy: action.payload.value,
};
}
default:
return state;
}
};
`

Similarly, we create another reducer file named wishlistReducer.js.

`js
import { ActionTypes } from "./actions";
import { toast } from "react-toastify";

export const wishlistState = [];

export const wishlistReducer = (state = wishlistState, action) => {
switch (action.type) {
case ActionTypes.ADD_TO_WISHLIST: {
let updatedList = [...state];
const productInWishlist = updatedList.find(
(product) => product.id === action.payload.id
);
if (productInWishlist) {
return [...state];
}
updatedList = updatedList.concat(action.payload);
toast.success("Book added to wishlist");
return [...updatedList];
}
case ActionTypes.REMOVE_FROM_WISHLIST: {
let updatedList = [...state];
const productInWishlist = updatedList.find(
(product) => product.id === action.payload.id
);
if (!productInWishlist) {
return [...state];
}
updatedList = updatedList.filter(
(product) => product.id !== action.payload.id
);
toast.success("Book removed from wishlist");
return [...updatedList];
}
default:
return state;
}
};
`

We would now modify dataReducer.js as follows:

`js
import { productsReducer, productState } from "./productReducer";
import { wishlistReducer, wishlistState } from "./wishlistReducer";

// add all the initialStates to create a single state.
export const initialState = {
...productState,
wishlist: wishlistState,
};

// combine all the reducers to this updated state
export const reducer = (state, action) => {
state = {
...state,
...productsReducer(state.products, action),
wishlist: wishlistReducer(state.wishlist, action),
};

switch (action.type) {
// switch case to check some common state manipulations - if any
default:
return state;
}
};
`

By modifying the dataReducer.js as mentioned above, we are good to go! 💃 Yes, we need not make any kind of changes to the other parts of the code. All the hooks and state management would work exactly the same.

Understanding the working

Let's break down and see what happens within dataReducer.js and understand how this magic works.🪄

In the first example, our initial state had 3 properties and looked like ⬇️

js export const initialState = { products: [], sortBy: "", wishlist: [], };

We divided them into 2 states as productState and wishlistState

`js
export const productState = {
products: [],
sortBy: "",
};

export const wishlistState = [];
`

Note: Observe how I have used an object for productState and an array in the case of wishlistState. We could modify the individual states as per our needs while dividing the reducer functionalities.

Now, within dataReducer.js, we brought back the same intialState as follows:

js export const initialState = { ...productState, wishlist: wishlistState, };

We are destructuring productState to get the properties products and sortBy into the same state object as that of wishlist.
In the same way, we modify the state within reducer to obtain the latest modified value from productReducer and wishlistReducer respectively.

js state = { ...productsReducer(state.products, action), wishlist: wishlistReducer(state.wishlist, action), };

We could then add a switch case to this reducer if there are any further state modifications and return the latest state value to the view.

I hope this article helped in understanding how we could break down a single reducer into smaller ones based on individual functionalities and yet maintain a single state value. If this sounds interesting, you could extend this code and implement the cart functionality with the same approach.

Hint: We could have cartState and cartReducer which can be included within initialState and reducer respectively.

Tag me on Twitter and let me know if you were able to add this feature.

If this article was helpful, please give this post a like (with your favorite emoji 😁). Let me know your thoughts in the comments.

Reach out to me on Twitter if you have any queries. Happy learning! 💻

Peace ✌

Add this key feature to your eCommerce application in 3 simple steps

Supriya M — Sun, 26 Dec 2021 04:05:43 +0000

While getting into the world of web development, we would have definitely come across the implementation of an eCommerce application. There are a lot of eCommerce web applications available to take inspiration from and implement the set of features such as product listing, filter categories, product details, cart, and wishlist.

We could take it one step further and add user authentication to this application such that few of the features such as wishlist and personal details could be exclusively accessible to only registered users.

I did the same while creating my version of an eCommerce application - SupMart. This application has data curated from various web applications specific to the theme of jumping rope.

I have developed this project using the following tech stack:

React with useContext + useReducer
Routing using react-router v6
Backend API structure with Express and Node.
Mongoose as an ORM to access and maintain data on MongoDB.
User authentication using JWT (JSON Web Token).

I took inspiration from Myntra in terms of the flow and structure of the application. I made sure that the wishlist, address management, and order summary pages are considered private routes. This means, only users who are registered to SupMart would be able to use these features to store persistent data.

After covering a handful of features along with the landing page, I was missing out on one huge implementation. When we talk about an eCommerce application that lets us add products into the cart, continue to add/manage address details, and finally present the order summary page, we surely would need a way to complete this transaction. We need a payment gateway integration to be implemented.

Why is this feature important?

Within any given eCommerce application, the complete workflow of placing an order is as follows:

Search for the desired product from the product listing page
View the details about this product on the product detail page
Add the product into the cart
Proceed to checkout and fill in the address information
View and verify the details about the order on the summary page
Complete the payment using the given payment gateway.
An acknowledgment is provided to the user regarding the order and payment status.

Including the payment gateway implementation is like completing the whole application; the end-to-end journey is achieved, otherwise it's similar to baking a beautiful cake but not adding the icing on top of it. A cake wouldn't look complete without the icing or cream at the top layer.

List of payment gateways integration

As we have understood that payment gateways are a crucial part of any given eCommerce application, there are plenty of payment gateway options available currently in the market.
Paypal, Razorpay, Stripe, Paytm, Google pay, Pay U, etc. When I searched about payment integration tutorials using react, most of the tutorials used Stripe. Thus, I decided to go with the same. My thought here was - If I was unable to learn the implementation using the official documentation, I could always use these tutorials as an alternative. The ultimate goal was to get this feature on my eCommerce application. Thanks to Stripe for providing the most beautiful documentation that is beginner-friendly. Following is the implementation approach that I have used - React(FE) and Express(BE).

Here, I would like you to take a pause, go ahead and create an account with Stripe. By this, you would gain access to the public key and secret key details.

Building the checkout feature on React

Step 1: Install stripe-js

npm install @stripe/stripe-js
or
yarn add @stripe/stripe-js

Further, you could make use of the useStripe, useElement hooks from @stripe/react-stripe-js. Although, we will restrain from this usage.

Step 2: Make a call to the API using Stripe's public key.

import { loadStripe } from "@stripe/stripe-js";

const stripePromise = loadStripe(`[public-key-details]`);

const redirectToStripePayment = async () => {
  try {
    setShowLoader(true);
    const response = await axios.post(`[server-api-url]`);
    if (response.data.success) {
      let stripe = await stripePromise;
      await stripe.redirectToCheckout({
        sessionId: response.data.id,
      });
    }
  } catch (err) {
    console.error(err);
  } finally {
    setShowLoader(false);
  }
};

The loadStripe function asynchronously loads the Stripe.js script and initializes a Stripe object. Pass the returned Promise to Elements.
Once this promise is fulfilled, we redirect our application from the order-summary page to the Stripe payment gateway with a predefined UI template.

Setting up Stripe redirection on server

Step 3: The API called by the react application has been developed using Express (web framework for Node.js) as follows.

const stripe = require("stripe")(`[secret-key-details]`);

const stripeTransaction = async (req, res) => {
  const { cart, user } = req;

  // fetching the cart details of the user.
  let cartItems = await getCartItems(cart);

  // creating a new session for stripe transaction
  const session = await stripe.checkout.sessions.create({
    payment_method_types: ["card"],
    line_items: cartItems,
    mode: "payment",
    success_url: "https://[app_url]/payment-transaction?status=success",
    cancel_url: "https://[app_url]/payment-transaction?status=failure",
    customer_email: user.email,
  });
  res.json({ success: true, id: session.id, url: session.url });
};

stripeTransaction function is invoked when the API call is made from redirectToStripePayment. Using the secret-key, stipe creates a new session object. Once the transaction is completed, it redirects to success_url or cancel_url based on the result.

Tadaa, there you go! You have successfully set up the payment gateway integration on your eCommerce app. Now, this application is wholesome ❤️

You can check out this functionality on the eCommerce app that I have developed - SupMart

If this article was helpful, please give this post a like. Let me know your thoughts in the comments.

Reach out to me on Twitter if you have any queries. Happy learning! 💻

Peace ✌

DEV Community: Supriya M

Decoding StyleX: Meta's Cutting-Edge Styling System

What is StyleX?

How and Why did Meta create StyleX?

Key Features of StyleX:

Let's see how it works 🧑‍💻

Adding styles using StyleX

Adding styles to pseudo-classes

Working with media-queries

Let's see how "last style applied always wins"

Overriding styles from parent

How does atomic classes work (internals)

Global Variables and Themes

That's a wrap 🎉

References

Module Federation using ViteJS - Step into the Micro-frontend architecture

What is Module Federation?

Host and Remote Applications

Remote Component - Header.tsx

Host Application with Videos.tsx Component

Consuming Remote in a Webpack Application

Host Component - Blogs.tsx (Webpack Application)

Further options for extending the use of Module Federation

Conclusion

References

Introduction to React Server Components!

What are React Server Components (RCS)?

Why use React Server Components?

How to use React Server Components

Things to note!

What can React Server Components NOT do?

Conclusion

References

Simplify your lists using CSS Counters

An Introduction to CSS Counters

Creating a Counter

Using the Counter

Output 🖥️

Styling Numbered Lists

Output 🖥️

Conclusion

Setting up React-Native Development Environment

Configuration for iOS

Configuration for Android

- Next, I ran npx react-native@latest init AwesomeProject . The project was created with a few warnings.

Pointer Events in JavaScript

Introduction to Pointer Events

Types of pointer events

Pointer Capture Event

Let's understand how the code works!

Link to the demo application

Building FinSaver for Hack-R-Play 😎

Introduction

What is Hack-R-Play

The idea for my project

Features of FinSaver

Upcoming features

My learnings and experience

My final thoughts

What are Progressive Web Applications? Get started with creating PWA

Introduction to PWA

Get Started with PWA Development

Manifest file

Service workers

Installation

Fetching

Activating

What is Workbox

Resources

Introduction to web performance

What is web performance

Lighthouse

First Contentful Paint (FCP)

Largest Contentful Paint (LCP)

Time to Interactive (TTI)

Total Blocking Time (TBT)

Cumulative Layout Shift (CLS)

First Input Delay (FID)

Resources

Polyfill for Promisify

- Next, I ran `npx react-native@latest init AwesomeProject` . The project was created with a few warnings.