DEV Community: Ibrahim Shamma

Rspack with Module federation V2 is the future

Ibrahim Shamma — Sat, 28 Dec 2024 19:04:09 +0000

The module federation team cared deeply about the DevX in their latest release.
The purpose of this blog is to go through setting up the project, and explain a little on each decision being taken here.

Github Repo:

Wanna see the full code, check this app out:
https://github.com/IbrahimShamma99/microfrontend-rspack-module-federation-v2

Tech Stack

pnpm

This package manager recently became my favorite, for many reasons, including how to handles non flattened node_modules which helps in resolving security vulnerabilities effectively.
Another thing amazing about pnpm which how it simply you create monorepos, without the need to read much of docs like other solutions.

For more info about this amazing package manager I highly recommend this article published by refine.dev

React

Very obvious choice, though I will add vue into the mix soon.

Typescript

Consumer apps in MF V2 generates types out of remotes and being stored by default into @mf-types directory, we are using TS to demonstrate that.

Rspack

In previous blogs we were using webpack, but ever since rspack hit the V1 mark I have been migrating every app I work with into rspack, why? same webpack configuration but with faster and out of the box support for code splitting and module federation, what could you ask for more?

some members webpack core team are the ones building rspack which they have the experience and architecture knowledge transfered into the new bunder rspack should not be looked at as a V1 package, instead it is a continuation to what webpack is.

Setup project

Initialize dir:

First we are going to create the directory and setup package.json.

mkdir ./out-project-name
cd ./out-project-name

pnpm init

Add ESM Config:

We want to make sure our package is ESM based, not CommonJS, so we do the following modification to package.json

npm pkg set type="module"

For more info check this out

Setup Engine and Package manager:

Simply run the following two commands

npm pkg set engines.node=">=22.10.0"
npm pkg set packageManager="pnpm@9.15.1"

Add pnpm worksapce

Run this touch command:

touch pnpm-workspace.yaml

it will create pnpm-workspace.yaml config file which we will add to it the following yaml config:

packages:
  - "apps/*"
  - "packages/*"

In respect to each will mean:

apps: Consumed and Consumer apps which run on specific port.
packages: shared slices of code between different apps, it could be UI libraries or communication with backends etc.

Create apps

mkdir apps
cd ./apps

# lets create two react typescript app one named header and other named main
pnpm create rsbuild@latest

cd ../

Install module federation:

Command:

pnpm add @module-federation/enhanced --workspace-root
pnpm add @module-federation/rsbuild-plugin --save-dev --workspace-root

We are adding --workspace-root flag stating that this package is a global package that can be shared between apps, this is helpful for having single place to manage global dependency versioning

Setup Consumed app

going into apps/header/rsbuild.config.ts
we would find rsbuild configuration

rsbuild is the build tool for rspack.

Let's add the following code:

// src/Header.tsx

export default function Header() {
  return (
    <div>
      <h1>Main Header</h1>
    </div>
  );
}

// apps/header/rsbuild.config.ts
import { defineConfig } from "@rsbuild/core";
import { pluginReact } from "@rsbuild/plugin-react";
import { pluginModuleFederation } from "@module-federation/rsbuild-plugin";

export default defineConfig({
  server: {
    port: 3001,
  },
  plugins: [
    pluginReact(),

    pluginModuleFederation({
      name: "header",
      exposes: {
        "./header": "./src/Header.tsx",
      },
      shared: ["react", "react-dom"],
    }),
  ],
});

Explanation:

It is much like the configuration we explained before here

Configuration is pretty much similar to previous MF versions.

Setup Consumer app:

// src/FallbackHeader.tsx
export function FallbackHeader() {
  return (
    <div>
      <h1>Fallback Header</h1>
    </div>
  );
}

// src/App.tsx

import { FallbackHeader } from "./FallbackHeader";
import { Suspense } from "react";
import Header from "header/header";

const App = () => {
  return (
    <div className="content">
      <Suspense fallback={<FallbackHeader />}>
        <Header />
      </Suspense>
      <h1>Main App</h1>
    </div>
  );
};

export default App;

Want to learn more about why we adding a fallback Header with the suspense? please checkout part 5 & 6 of this series:
Part 5
Part 6

running the app:

One of the true powers of pnpm is the filter flag
which let root package.json exposes internal monorepo scripts

ROOT/package.json
{
"scripts": {
    "header": "pnpm --filter ./apps/header",
    "main": "pnpm --filter ./apps/main"
  },
}

and going into root app and run the following commands each on separate terminal:

pnpm header dev
pnpm main dev

And your app is running!

If losing the small battles would win you in the long run then why not?

Ibrahim Shamma — Fri, 06 Sep 2024 18:15:31 +0000

Imagine you're a developer, happily writing code, delivering on your tasks, and receiving that paycheck at the end of the month. Everything seems fine—you're valuable to the company, your work matters, and your technical skills are respected. However, unless you're a solo developer, you're part of a larger hierarchy, often near the bottom of the decision-making chain. This isn't necessarily a bad thing, but it becomes an issue when your goals become misaligned with those higher up. Even if you're technically right in your approach, without understanding the bigger picture, you can lose your place in the company’s value system.

There is an Engineer, who worked for a company that specialized in file conversions. At some point, the company decided to introduce AI into their processes. This engineer pushed back hard, arguing that AI made no sense for their specific use case. He was technically correct—after all, converting lossless image types like PNG into JPEG is a straightforward process. It involves clear, established steps: Color Space Conversion, Subsampling, Discrete Cosine Transform, Quantization, Entropy Coding, and finally, File Structuring. These are algorithmic steps that AI doesn’t really improve. Despite this, the engineer was eventually fired.

Looking back, he might have realized what he missed: the bigger picture. What would the CEO say to investors? If the company didn’t embrace AI, it could easily be seen as outdated, falling behind competitors. This perception wouldn’t just hurt the company—it would affect the entire team, including that very same engineer. Being technically right wasn’t enough; understanding the business and strategic implications was equally important.

So, what should you do in situations like this? It’s simple: be politically aware. Instead of fighting management, listen to their vision. Understand what they’re trying to achieve, then find a way to bridge the gap between existing technology and new trends. This way, you avoid breaking the software with needless hype, but also ensure you’re not left behind by innovation. It’s a balancing act—keeping both your technical integrity and management’s excitement aligned.

By doing this, you avoid hitting your head against the wall, and management won’t be upset. In fact, they’ll have something fresh and exciting to present to stakeholders, all while you keep the company grounded in solid, functional tech.

But let's say you have already fought them and been stubborn already, what shall you do? Accept your short coming and make the higher up aware about your mistake, they would have much more respect for you for your acknowledgement and self awareness, and at the end of the day that ultimately would make you grow personally and also in career wise.

Manage telescopic constructors with builder pattern using Typescript

Ibrahim Shamma — Sat, 30 Mar 2024 23:01:13 +0000

This is a beginning of a series that targets code design in Typescript, your insights are invaluable.
The following blog is influenced by refactoring guru

The Problem

You have a schema bloated with optional attributes, how do mange constructing it?

// Schema
class House {
  public windows?: number;
  public doors?: number;
  public rooms?: number;
  public garage?: boolean;
  public walls?: boolean;
  public swimmingPool?: boolean;
  public garden?: boolean;
  public fence?: boolean;

  constructor(data: {
    windows?: number;
    doors?: number;
    rooms?: number;
    garage?: boolean;
    walls?: boolean;
    swimmingPool?: boolean;
    garden?: boolean;
    fence?: boolean;
  }) {
    this.windows = data.windows;
    this.doors = data.doors;
    this.rooms = data.rooms;
    this.garage = data.garage;
    this.walls = data.walls;
    this.swimmingPool = data.swimmingPool;
    this.garden = data.garden;
    this.fence = data.fence;
  }

  addWindows = (windows: number) => {
    this.windows = this.windows ? windows + this.windows : windows;
  };}

// Constructing Schema
const house = new House({
  doors: 4,
  windows: 4,
  rooms: 4,
  garage: true,
  walls: true,
  garden: true,
  fence: true,
});

As you can see from the above example, each time you create instance of the class you will need to specify every needed attribute, which can be tedious, also error prone.

The Solution

Builder Pattern

This pattern achieves the ability to construct objections by using steps, the pattern allows you to produce different types and representations of an object using the same construction code.

Steps:

1. Create an interface for our class

abstract class House {
  public abstract windows: number;
  public abstract doors: number;
  public abstract rooms: number;
  public abstract garage: boolean;
  public abstract walls: boolean;
  public abstract swimmingPool: boolean;
  public abstract garden: boolean;
  public abstract fence: boolean;
}

class HouseA extends House {
  public windows!: number;
  public doors!: number;
  public rooms!: number;
  public garage!: boolean;
  public walls!: boolean;
  public swimmingPool!: boolean;
  public garden!: boolean;
  public fence!: boolean;

  addWindows = (windows: number) => (this.windows += windows);
}

class HouseB implements House {
  constructor(
    public windows: number,
    public doors: number,
    public rooms: number,
    public garage: boolean,
    public walls: boolean,
    public swimmingPool: boolean,
    public garden: boolean,
    public fence: boolean
  ) {}

  addWindows = (windows: number) => (this.windows += this.rooms * windows);
}

Remember Dependency inversion principal that High-level classes shouldn’t depend on low-level classes. Both should depend on abstractions. Abstractions shouldn’t depend on details. Details should depend on abstractions.

2. Create Builder interface and concrete implementation

abstract class HouseBuilder {
  protected house!: House;
  public abstract buildWalls: () => void;
  public abstract buildDoors: () => void;
  public abstract buildWindows: () => void;
  public abstract buildGarage: () => void;
  public abstract buildRooms: () => void;
  public abstract buildSwimmingPool: () => void;
  public abstract buildGarden: () => void;
  public abstract buildFence: () => void;
  public abstract reset: () => void;
  public abstract getResults: () => House;
}

class ConcreteHouseBuilderA extends HouseBuilder {
  house!: HouseA;

  reset = () => {
    this.house = new HouseA();
  };

  buildDoors = () => {
    this.house.doors = 2;
  };

  buildWindows = () => {
    this.house.windows = 2;
  };
  // You can continue the rest of the building methods
}

What did we do here?

Created interface for HouseBuilder in case we need to create different concrete implementations for each House concrete class
We initialized inside the concrete the instance of HouseA meanwhile the interface was reliant on House this will help us in creating more concrete builders
The main intent of builder class is to construct HouseA via steps

3. Create Director class

This is optional method, which wraps the builder implementation, this can help if we need to run builder steps in specific order, building walls before windows, etc.

Code:

type HouseType = "simple" | "luxury" | "modern";

class Director {
  constructor(private builder: HouseBuilder) {}
  changeBuilder = (builder: HouseBuilder) => (this.builder = builder);
  reset = () => {
    this.builder.reset();
  };

  buildBasicHouse = () => {
    this.builder.buildDoors();
    this.builder.buildWindows();
    this.builder.buildRooms();
  };

  make = (type: HouseType) => {
    this.builder.reset();
    switch (type) {
      case "simple":
        this.builder.buildGarage();
        break;
      case "luxury":
        this.builder.buildGarage();
        this.builder.buildGarden();
        this.builder.buildFence();
        break;
      case "modern":
        this.builder.buildGarage();
        this.builder.buildGarden();
        this.builder.buildSwimmingPool();
        this.builder.buildFence();
        break;
      default:
        break;
    }
  };
}

Note that Director is reliant on Builder interface

Now implementation time:

const concreteHouseA = new ConcreteHouseBuilderA();
const director = new Director(concreteHouseA);
director.make("modern");
console.log(concrete1.getResults());

Conclusion

To sum up, using the Builder Pattern provides a simplified way to deal with the complexity of creating objects that have telescopic constructors. This design makes the construction process easier to interpret, more flexible, and easier to maintain by breaking it up into discrete parts. Code that is modular and readily extensible is encouraged by the use of interfaces and concrete implementations, which follow the Dependency Inversion Principle. Moreover, the optional Director class adds another level of structure by allowing building stages to be executed one after the other and making it easier to create various object configurations. Adopting such design principles increases overall project scalability, developer productivity, and code quality. We hope to learn more about code design techniques in this course, utilizing TypeScript's features to create beautiful and effective solutions. Watch this space for more insights and practical examples to elevate your coding proficiency.

From senior engineer to a mentor for software engineers

Ibrahim Shamma — Sun, 11 Feb 2024 22:36:03 +0000

One of the awesome things about tech is that it introduces many people to you, once you get enough experience and you are finally not the student of the game but rather senior engineer after years of experience, mentoring can be a good option into transitioning from seniority in writing code and delivering into seasoned tech lead who help people to deliver value

Find a mentee, they can be your friends on tech, or simply look at mid level engineers, these are the most in need for mentorship, mid level engineers are in a unique spot in their careers, they know a lot of the basics, they can finish tickets, they can create something, but they are not experts at their thing, and it might be they are not aware of their options or they don’t have a clear goal.

Know your mentee goal

Basically ask the question, where do you see yourself in 3 years?

Based on the feedback from the first goal, you can proceed but sometimes engineers do not know what they want or they do have a clear plan, if so, those are the most of need to mentorship, so relax if you don’t get the answer you were looking for, it means they will get most out of your mentorship, it is also an opportunity for your to revise your decisions and directions, a win win scenario for sure.

Back to when the mentee does not have a goal, then you need to throw around what goals are there given that they are in software engineering you most likely will end up in one of the following scenarios

Do they want to switch out of tech? if so are you looking to become a product manager? engineering manager?
Do they want to become QA Engineers?
Do they want to get comfortable with code?
Do they want to become a tech lead or a senior engineer? (For fun, check You are not the Tech Lead)

Setting up a Growth Plan

The goal behind the plan which short-term action items will drive toward their long-term goals.

This is a very important step, what differentiate great mentors is that their plan is purely based on the step 1 meaning, if you are planning to become a product engineer, you should focus on building the product mindset, without too much focus on technical details.

A helping template you can use is here

Template:

Step 0: Gather inputs such as existing feedback & guidelines on promotion.

Step 1: Assess your current and desired states.

Step 2: Prioritize 3-5 skills/competencies to focus on.

Step 3: Set a SMART (Specific, Measurable, Achievable, Relevant, and Time-bound) goal for each focus area.

Step 4: Identify dependencies and support. What or who might be key to achieving your goals? Write down any resources, tools, or individuals you might need:

Credit to Omar Halabieh for the template.

Scheduled 1:1

After setting up the Growth Plan, you’ll want to meet 1:1

The 3 things I have top of mind are:

Challenges: What is difficult right now or recently?
Reflections: Anything they wish went better recently?
Relationships: How are things going with their manager or the people they are working with?

Credit to JORDAN CUTLER for the template

You can even go even further and treat is as if it is a retro session

I leave the mentee to express their feelings, their ideas and current situation behind the questions, and then we drive a healthy conversation that leaves the mentee with a lot of ideas to process, related to what they should have done better in regard the situation. They’re great for priming your mentee to share what’s going on and how you can help.

Remember here you must listen a lot to be heard later, for the next point

Ruthlessly give them a DOs & DON’Ts but with a the why behind it

I said you need to be ruthless, because there should be no hard feelings when getting a feedback as a mentee, if you are not able to accept DON’T you won’t be able to progress forward Like:

DON’T read part of the problem and start coding
DON’T write code based on non written or assumptions, related to business

and more of a redirection DOs like:

Listen carefully when you get some requirements and ask clarifying questions

Again you only can do that when you listen carefully and give them their space to express in step 3

How can you give the why behind the advices?

The magical way is to share similar stories and once shared you need to get mentee’s judgement on the situation and then give them your solution to the situation, this way you would leave them in a thought process into how to related to your experience while they are in a different situation.

Note that your solution mostly will not tailor made to their situations, (check solution building methodolgy)

Sometimes you might not have a story related to the mentee situation, and that’s the beauty of mentorship is to expose you to different situations and leave you thinking about it.

As a Software Engineer in a startup, plan your leave to the corporate world

Ibrahim Shamma — Fri, 26 Jan 2024 09:42:26 +0000

Before why we should leave the startups we need to address the following:

Why we end up in Startups in the first place?

You finished your college or boot-camp or whatever, you found out about some startup that is using hot tech, state of the art solution, or it is just the only opportunity you got.
Either way, there is nothing wrong, startups make a good starting point to your career, they have less restrictions on what build and how, you can experiment technologies, build an app by your self and what it comes with it from learning, technologies, but spoiler alert, most of those projects you were excited about failed, the startups is a place to experiment and get exposed to technologies, this is one of the many reasons the number of startups created per year in a nation is considered a key KPI for growth.

According to history, most startups fail, with up to 75% rate of failure, if we focus on what will mostly happen is that whatever you are working on will not be relevant in couple of years, and that project you were working as a solo engineer like Madonna on solo performances will fade, and you will start thinking how sustainable your employer is, and how sure you can be paying the bill the next month, you will start losing the excitement and honeymoon mode you are in while building something.

Here are the notes to consider before start your next move

With the current bad economy we are more limited

Here comes two solutions, go to another new hot startup and repeat the cycle? or find a stable Job in some Giant Corporate where you are performing a stage full of people, product, testers, engineers, support and many more, your responsibilities and influence will be shortened, but trust me it is for your own and your employer good.

Take off the Ankle Weights, and move faster

You know when athletes wear weights on their ankles, they become slower, it is great for training but at some point you got to take them off when your muscles become stronger, to relate into all of this personally speaking, spent 6 years in successful and non successful startups, before moving away into corporate, because I was doing too much in the startup world, when getting into a specific role of engineering in a corporate people around me were amazed of how diverse my engineering skill, from frontends, backends, data engineering, databases and many stuff I could not recall, all of this made my corporate Job from responsibility perspective look so easy, and that made me have time for a lot of ideas I never had time to experiment with, and with good paying and stable corporate job you are not worried about the next bill anymore.

Getting to the next level in sinking ship might be your least of a priority

Most great engineers were so great by focusing in their craft and not having to worry about how to feed a family.

It is not about only coding

Tech is much more than technical knowledge, one aspect you are not aware of when being in startups is the politics.

Corporates are slow and that's a feature

You may have other plans delayed for so long, contribute to open source library, or start your own, or even personal non tech stuff like traveling and marriage etc, with the slow nature of startups you can have a better time capacity management for such events

Embrace the Rough Seas: Why Every Sailor Needs to Weather the Storm

If you did not get the chance to build small products and prototyping and especially in small teams, you should aim into achieving this before going into bigger teams, where they don't have the authority to ship broken product done a night before into prod

Blind Spots and Boundaries: Navigating the Terrain of Limited Perspective

You might be incorrect and actually the startup you are working on is near an acquisition, or going public, then your stay is most likely going to be worth it, in terms of compensation.

Conclusion

Always aim into what is in favor the long run, your family is more important than your CEO, your kids need you more than the project you are working on solely, and it is at the end of the day a business that is not yours, relax.

React Reducers

Ibrahim Shamma — Tue, 24 Oct 2023 19:23:23 +0000

When it comes to reducers, you may often think that it is
related to the great Redux library, but it is originally comes from the React library itself.

We all have seen components that does one or two clicks, and they do many state changes, handling many state changes with useState can sometimes be tedious, we want to introduce another approach in handling multi-state changes inside your component.

I am not advising into stopping the usage of useState or the state management solutions, use this solution when the state is only the component's concern and we have many state changes ahead, for this case, you can consolidate all the state update logic outside your component in a single function, called a reducer.

A reducer is a way To reduce this complexity and keep all your logic in one easy-to-access place, you can move that state logic into a single function outside your component.

How to call it

import { useReducer } from "react";

const Componet = () => {

  const [state, dispatch] = useReducer<DispatcherType>(reducer, {
    tasks: [],
  });
....
}

As you can see in the DispatcherType is function type that takes the currentState and the dispatched action as arguments, and returns the newState.

Dispatch:

The dispatch function by convention has type prop that infers the event name, it is advised that the event name is in snake_case and with with past tense

As can be seen here example:

dispatch({
  // specific to component
  type: 'what_happened',
  // other fields go here
});

payload contains the event data that host the state changes, as recommended

creating a Project

TLDR Here is the running code example:

steps

We need to create a simple react app with the following steps:

npx create-react-app my-app --template typescript
cd ./my-app

Once the app is created, we need to create component called task-list that will encapsulate the UI/Logic/Types and everything related to our simple app

mkdir ./src/components
mkdir ./src/components/task-list

touch ./src/components/task-list/lib.ts
touch ./src/components/task-list/types.ts
touch ./src/components/task-list/index.tsx

We have in the component 3 distinct files:

types.ts: this will host the types of the component logic and state, this is great for newcomers to your code to understand what is actions in the ui and what is state being stored
lib.ts: this is where your presentational logic is stored
index.ts: Typical UI elements

This component setup is meant for simplicity, if you want a better setup for your working team, introduce to them FSD which in later posts I will dive into

Now let's fill the code:

// types.ts

export type Task = {
  id: string;
  name: string;
};

export type State = {
  tasks: Task[];
};

export type TaskAdded = {
  type: "task_added";
  payload: {
    task: string;
  };
};

export type TaskRemoved = {
  type: "task_removed";
  payload: {
    id: string;
  };
};

export type Action = TaskRemoved | TaskAdded;

export type Dispatch = (state: State, action: Action) => State;

// lib.ts
import { Action, State } from "./types";
import { v4 } from "uuid";

export const reducer = (state: State, action: Action) => {
  console.log("state", state);
  console.log("action", action);

  switch (action.type) {
    case "task_added":
      return {
        tasks: [
          ...state.tasks,
          {
            id: v4(),
            name: action.payload.task,
          },
        ],
      };
    case "task_removed":
      return {
        tasks: state.tasks.filter((a) => a.id !== action.payload.id),
      };
    default:
      throw Error("Event Not Implemented");
  }
};

// index.tsx

import { useState, useReducer } from "react";
import { reducer } from "./lib";
import { Dispatch } from "./types";

export const TaskList = () => {
  const [state, dispatch] = useReducer<Dispatch>(reducer, {
    tasks: [],
  });
  const { tasks } = state;
  const [currentInput, setCurrentInput] = useState<string>("");

  return (
    <div>
      <form>
        <input
          onChage={(e: any) => setCurrentInput(e.target.value)}
          placeholder="task"
          type="text"></input>
        <button
          type="button"
          onClick={() => {
            dispatch({
              type: "task_added",
              payload: {
                task: currentInput,
              },
            });
            setCurrentInput("");
          }}>
          submit
        </button>
      </form>
      {tasks.map((task, index) => (
        <div key={index}>
          <div>task {task.name}</div>
          <button
            type="button"
            onClick={() => {
              dispatch({
                type: "task_removed",
                payload: {
                  id: task.id,
                },
              });
            }}>
            delete
          </button>
        </div>
      ))}
    </div>
  );
};

You may need a Ref not a State.

Ibrahim Shamma — Thu, 19 Oct 2023 18:14:49 +0000

When you build React Apps, you may come to a conclusion that all mutations can be done with useState in functional components, but you would see that a lot of enterprise, or other seniors that would use more different ingredients, that would increase the complexity, you may wonder that all of that complexity is unneeded and things can be way simpler, just by using useState, this article will show you one aspect why we may need to complicate things a little.

Based on React docs a ref is used when you want a component to “remember” some information, but you don’t want that information to trigger new renders, you can use a ref.

With that being said, we need to play around the APIs

Use case

Let's say that we have a UI component that would take a state then it makes an API call to get a value, but instead of using this value for presentation, we need to use this value for another API.

We have two options when it comes to storing the first API value:

using the useState: this would not make sense, since useState would do mutate + rerender, and we don't want a rerender.
using the useRef, this is making sense because we only want to store a value that would be used later in an API call

to make it short:

state => `Mutate` + Rerender

ref => `Mutate` # only

Is it worth it to take it into consideration?

In the micro-level, you won't feel the difference, but when application grows and with any action you're taking that into consideration, you will have the UX and performance you would like to accomplish to your users.

Another Aspect

In using ref, you are mutating the value directly as if it is a normal var value, unlike the useState where you need to mutate indirectly by passing the value or its callback into the setState funciton, but why?

State needs to be updated indirectly because it is not just an update to a value, it does:

Checks the effects that dependent on the value itself
Rerender job
Mutate the Value itself

But in Refs, when you change the ref.current property, React does not re-render your component. React is not aware of when you change it because a ref is a plain JavaScript object.

Code:

Suspense your federated component with caution

Ibrahim Shamma — Sat, 14 Oct 2023 21:10:39 +0000

When you see examples of federated components, you will mostly see it wrapped by React.Suspense, which basically returns a fallback component until your component is loaded, but suspense does not handle if your federated component throws an error or your micro-site is down, in that case you need to read this article where we explain to handle the situation when we unable to load the component.

When we want to Suspense our federated component we need to take care of the followings:

Your Federated component may be slow to respond

You better have a spinner inside the fallback component for example:

<Suspense fallback={<Spinner />}>
    <FederatedComponent />
</React.Suspense>

but the above code can cause an obvious issue, I may have multiple federated component in one page, so:

You may consider not showing multiple spinners in your page

In this case you need to do the following:

// DO NOT DO THIS
<>
    <Suspense fallback={<Spinner />}>
        <FederatedComponent1 />
    </React.Suspense>

    <Suspense fallback={<Spinner />}>
        <FederatedComponent2 />
    </React.Suspense>
</>


// DO THIS
<Suspense fallback={<Spinner />}>
    <>
        <FederatedComponent1 />
        <FederatedComponent2 />
    </>
</React.Suspense>

Again checkout the federated wrapper shown in this article, to make sure if your federated sites are not showing for whatever reason, you load a local fallback component.

Since we are lazy loading components, these components should have nothing to do with SEO

The crawlers will not wait to scrape the site with the lazily loaded component, so you need your SEO content to be part of your FCP

Side Note: making the intellisense recognize your federated component

In the previous blogs we used the definition react-app-env.d.ts for declaring modules like:

declare module "app1/FederatedComponent1";
declare module "app1/FederatedComponent2";

We can do it in a better fashion where we leverage the types and all ts cool features by going into the host tsconfig
and in the compilerOptions we add in the following in the paths properity:

{
"compilerOptions": {

        "paths": {
            "app1/*": ["path/to/app1/federated-components-dir/*"]
}

}
}

or just add each federated component one by one:

{
"compilerOptions": {
        "paths": {
           "app1/FederatedComponent1": ["path/to/app1/federated-component-1"],
            "app1/FederatedComponent2": ["path/to/app1/federated-component-2"]
}

}
}

in this way the ts server can detect and parse the component from the microfronent, thanks to monorepos!

Always have plan B when your federated component fails

Ibrahim Shamma — Tue, 03 Oct 2023 22:54:05 +0000

You are now used to the following code:

import React from "react";

const App1 = React.lazy(() => import("app1/App"));

function App() {
  return (
    <>
      <App1 />
      <div className="App">host</div>
    </>
  );
}

export default App;

But what if the host could not load the app1?
what if app1 site is down?

In these cases you will have the house of cards falls all over the place, meaning if single microfrontend fails in a page the entire page will throw an error.

We can agree that this is not the best solution, but what can we do in this case?

When you federate a component, you need to have a fallback component

Maybe you're thinking of suspense? but suspense is designed for components that will eventually be loaded rather than components that fails, what we need specifically is an ErrorBoundary

Checkout the code here:

// app1-wrapper.tsx

import { Suspense, Component } from 'react';


const App1 = React.lazy(() => import("app1/App"));

class App1Wrapper extends Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  render() {
    if (this.state.hasError) {
      return <div>Our plan B for app1</div>
    }

    return <App1/>
  }
}

export default App1Wrapper;

NOTE: the error boundary currently only supported on class based components

Now you import your wrapper safely inside your Host app.tsx

import React from "react";
import App1 from './app1-wrapper'

function App() {
  return (
    <>
      <App1 />
      <div className="App">host</div>
    </>
  );
}

export default App;

And that's it!

Your homework

Add a spinner that the host fails back into when waiting the component from the app1, (Use Suspense)

A/B Testing through React federated modules

Ibrahim Shamma — Sat, 30 Sep 2023 15:51:28 +0000

There are a lot of areas to start on your journey towards implementing Module Federation.

One of them is A/B Testing.

What is A/B Testing?

A/B testing is a user experience research methodology.
A/B tests consist of a randomized experiment that usually involves two variants, although the concept can be also extended to multiple variants of the same variable.

Still Curious what is module federation? Check me out!

Repo

To check out the github repo click here

Architecture

apps
├── app1
├── app2
├── host

app1,app2 are the federated different variants
host is our main site where our a/b tests will happen

In case you are wondering how to setup the environment, you better check out part 1 of this series here

Now the fun part, code

We go to the host, and create src/variant.tsx with the following code:

import React from "react";

const variants = [
  React.lazy(() => import("app1/App")),
  React.lazy(() => import("app2/App")),
];

const Variant = ({ text }: { text: string }) => {
  const Component = variants[Math.floor(Math.random() * variants.length)];

  return <Component text={text} />;
};

export default Variant;

NOTE: Don't forget to add type definition for the two lazy loaded modules, simply inside the host/src/react-app-env.d.ts

declare module "app1/App";
declare module "app2/App";

Now, the code above it is all about dynamically import the federated modules from the different apps. And then choose one of them to show up here.

Note that both components needs to have the same props since both will be interacted with from the same interface.

Now you only need to import this variant.tsx into your app normally:

import Variant from "./variant";

function App() {
  return (
    <>
      <Variant text="+ loaded from Host" />
    </>
  );
}

export default App;

Always Try to isolate your main app components from the underlying importing logic that consists of dynamic, lazy loading, and suspension which we will go through later in this series.

Your Homework

If you noticed, we are importing two JS bundles and only using one, if we had for example 5 A/B tests we would be importing 4 bundles that will not be using, how can you optimize this?

A simplified prospective in sharing Redux Store between Federated React Apps

Ibrahim Shamma — Wed, 13 Sep 2023 21:27:43 +0000

You have already created multiple federated react apps, and you still wondering, how can I share not just components in the runtime, but the entire store between the apps.

There are two notes here to consider:

Module Federation is meant to share any JS/TS module not just UI component.
The key into sharing the store is by exposing the reducers from our app into the host.

Work in action!!

Firstly clone the repo, or click here to navigate through the code without installing

git clone https://github.com/IbrahimShamma99/gentle-intro-module-federation-react 
cd ./gentle-intro-module-federation-react

Now let's examine the Repo, we have two react apps built with webpack, app1 and host

app1: will contain the store that will be exposed
host: it will consume the store from app1

So now how can we share the store?

Remote set up

While we are preparing the store in order to be consumed, we are here preparing a normal store that will consumed normally inside the remote (remote and app1 are the same I will use both interchangeably), and we will expose the reduces and that's it!

Exposing the Store in action!

first let's set up a store and reducer inside the remote
Firstly we are setting up a layout slice that will handle storing and toggling theme.

// apps/app1/src/reducer.ts

import { createSlice } from "@reduxjs/toolkit";

type Theme = "light" | "dark";

export interface LayoutState {
  theme: Theme;
}

const initialState: LayoutState = {
  theme: "light",
};

const layoutSlice = createSlice({
  name: "layout",
  initialState,
  reducers: {
    toggleTheme: (state, action) => {
      state.theme = action.payload as Theme;
    },
  },
});

export const { toggleTheme } = layoutSlice.actions;

export { layoutSlice };

export default layoutSlice;

And Now besides the reducer, we will create the store, although we will not share the store between apps, since redux only combines reducers not stores, but the store is crucial for the mutating the reducer inside the remote

NOTE: You can expose the reducers and be able to access the store, but preferably don't use actions outside of the remote

To create the remote store by simply:

import { configureStore } from "@reduxjs/toolkit";
import { useDispatch } from "react-redux";
import { combineReducers } from "redux";
import { layoutSlice } from "./reducer";

const Store = configureStore({
  reducer: combineReducers({
    layout: layoutSlice.reducer,
  }),
});

export { Store };
export type RootState = ReturnType<typeof Store.getState>;
export type AppDispatch = typeof Store.dispatch;
export const useAppDispatch = () => useDispatch<AppDispatch>();

now in module federation remote app configuration we need to do the following

// apps/app1/configs/federationConfig.js
const dependencies = require("../package.json").dependencies;

module.exports = {
  name: "app1",
  filename: "remoteEntry.js",
//This is what is important, exposing our reducer
  exposes: {
    "./layout-slice": "./src/reducer",
  },
  shared: {
    ...dependencies,
    react: {
      singleton: true,
      requiredVersion: dependencies["react"],
    },
    "react-dom": {
      singleton: true,
      requiredVersion: dependencies["react-dom"],
    },
  },
};

Now we have finished setting up and exposing the remote store, now we go into the host part

Host set up

Now we need to do one unconventional thing in the redux world, instead of importing all of our reducers like what we do normally synchronously, we will dynamically build the store, and we will have two approaches

When loading the page wait until the Store is imported then continue upon rendering.
Load Redux microfrontend framework Click Here

we will use the first approach since the latter needs a blog by its own.

we need to set up the host store now:

//apps/host/src/store.tsx

import { configureStore } from "@reduxjs/toolkit";
import { combineReducers } from "redux";

/*
NOTE: 
Here you take the interface of each slice and pass them into the `useStoreSelector` Hook in this way your `intellisense` will be aware of the federated types.
*/
const federatedSlices = {
  layout: await import("app1/layout-slice").then(
    (module) => module.default.reducer
  ),
};

const initStore = async () => {
  const Store = configureStore({
    reducer: combineReducers({
      ...federatedSlices,
    }),
  });
  return Store;
};

export default initStore;

As you can see in the code the store is initialized asynchronously, so the dom will be waiting our initStore promise to be fulfilled:

//apps/host/src/bootstrap.tsx

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App";
import { Provider } from "react-redux";
import initStore from "./store";

const root = ReactDOM.createRoot(
  document.getElementById("root") as HTMLElement
);

initStore().then((Store) => {
  root.render(
    <Provider store={Store}>
      <App />
    </Provider>
  );
});

NOTE make sure that the host already connected into the remote via config, if you could not make a lot of sense here, better to look up the following article.

Cheers!

Intoroduction into Module Federation, the React Parts

Ibrahim Shamma — Mon, 04 Sep 2023 19:08:26 +0000

In Webpack V5, the maintainers introduced module-federation. And that's our talking point, we will dive with the parts that concerns the react developers.

Our agenda

The Idea behind module federation
Key elements of the plugin
Env Setup
Share Components
Share Store
Task

The Idea behind module federation

Let's say that we have a two teams working in e-commerce app specifically the search results page where the related items being rendered, let's call them A & B with the respected responsibilities.

A: They are the UI people, they are responsible of UI components like the itemCard.

B: are responsible of getting the search results, and mapping the results into the itemsCard.

Our question is, what are our possibilities to manage these teams?

Now I need you to think of an solution before going below.

Possible Solution 1:

creating an npm package for the UI Kit where team B can download and consume.

obviously this solution has one big drawback that when Team A makes a new version, Team B has to upgrade the package manually to utilize the new version.

Not the optimal solution for our case where we need a full autonomy for each team.

Possible Solution 2:

Let's make a monorepo, where we have an app for team B and lazy loads the lib made by team A, this solution looks valid, and I had used it in my previous projects, but it has one drawback, if UI team modified the UI kit, we need to rebuild the application in order to get the newer version, since the lib is imported into the code, during build time it will be included in the site itself, okay to solve this issue.

let me introduce `module-federation`.

Where we can have multiple independent sites/apps/builds and we can share code between them during runtime, this is huge because now Team A can push changes and create new build, and when a new user comes in they will make the site on runtime get the UI components where team A hosted them, without team B interference.

Key things you can achieve with module federation.

Ability to split UI by domain, and let responsible team to take full ownership.
A/B code Testing out of the box: where you can have two or more services and choose which to use.
Run multiple frameworks in the same web app at once without headache, since module federation.

Plugin key elements

name: This is the name of the application. Never have conflicting names, always make sure every federated app has a unique
name.
filename: This is the filename to use for the remote entry file. The remote entry file is a manifest of all of the exposed modules
and the shared libraries.
remotes These are the remotes this application will consume.
exposes These are files this application will expose as remotes to other applications.
shared These are libraries the application will share with other applications.

Env Setup

We will use lerna, it is the monorepo tool of choice for most of react teams, there is also Nx, lerna uses Nx behind the scenes but lerna is simple, Nx has its own learning curve, if you would like to learn about Nx I have a dedicated series for it here

In case you have never worked with monorepos check this out

Let's go to our repo here

If you would to learn more about the set up by taking a step on step setup Please go here

Share Components

Let's explore our repo,

if you look at apps dir, we have two react apps, host that will contain our main app, and app1 which it will expose components into be used in in our host.

Let's export our App.tsx for the host, simply we need do the followings:

//apps/app1/configs/federationConfig.js

const dependencies = require("../package.json").dependencies;

module.exports = {
  name: "app1",
  filename: "remoteEntry.js",
  exposes: {
    "./App": "./src/App"
  },
  shared: {
    ...dependencies,
    react: {
      singleton: true,
      requiredVersion: dependencies["react"],
    },
    "react-dom": {
      singleton: true,
      requiredVersion: dependencies["react-dom"],
    },
  },
};

Let's explain what we are doing in our case:

Shared: First we need a single instance of react, react-dom, so we put the singleton property true. Since React, and many other libraries, have internal singletons for storing state. These are used by hooks and other elements of the React architecture. If you have two different copies running on the same page, you will get warnings and errors.
name: This is a name of the build, must be unique.
filename: The name of the js file that will word as an entry point for the remotes, simply the name of the file that will let the host access app1 build.
exposes: The tsx or ts modules that we need to share them.

Now let's set up the host federation config:

//apps/host/configs/federationConfig.js

const dependencies = require("../package.json").dependencies;

module.exports = {
  name: "host",
  filename: "remoteEntry.js",
  remotes: {
    app1: "app1@http://localhost:3001/remoteEntry.js",
  },
  shared: {
    ...dependencies,
    react: {
      singleton: true,
      requiredVersion: dependencies["react"],
    },
    "react-dom": {
      singleton: true,
      requiredVersion: dependencies["react-dom"],
    },
  },
};

We have two differences between the two configs, first in host we are not exposing, we are just consuming, in order to consume modules you need to connect into the remoteEntry of the remote in our case our remote called app1, the fun part is we can add as many remotes and as many exposed modules as we want.

Now we need to go to the host App.tsx to consume the federated module:

import React from "react";
const App1 = React.lazy(() => import("app1/App"));

function App() {

  return (
    <>
      <App1 />
      <div className="App">host</div>
      <div>{data}</div>
    </>
  );
}

export default App;

As you can see in the React.lazy we are lazily or asynchronously importing and rendering the component, we as a host we don't know or own the component, it is up to the service app1 team to handle it.

And for typed definitions we need to declare the federated module, since it is not found on local dirs.
To learn more I recommend the following source

//react-app-env.d.ts

/// <reference types="react-scripts" />

declare module "app1/App";

Share Store

Let's say we have a dedicated redux store for app1 and we would like to consume the store in host.
We will not share the store itself, instead we will share the reducers and actions into the host.

First from the app1 side we create a reducer.

//apps/app1/src/reducer.ts

import { createSlice } from "@reduxjs/toolkit";

type Theme = "light" | "dark";

export interface LayoutState {
  theme: Theme;
}

const initialState: LayoutState = {
  theme: "light",
};

const layoutSlice = createSlice({
  name: "layout",
  initialState,
  reducers: {
    toggleTheme: (state, action) => {
      state.theme = action.payload as Theme;
    },
  },
});

export const { toggleTheme } = layoutSlice.actions;

export { layoutSlice };

export default layoutSlice;

Finally from the app1 side, we go to the federationConfig.js inside the app1 and the add the following module:

  exposes: {
    "./App": "./src/App",
    "./layout-slice": "./src/reducer",
    }

Now we need to consume it in the host's store:

// apps/host/src/store.ts

const federatedSlices = {
  layout: await import("app1/layout-slice").then(
    (module) => module.default.reducer
  ),
};

const initStore = async () => {
  const Store = configureStore({
    reducer: combineReducers({
      ...federatedSlices,
    }),
  });
  return Store;
};

We are initializing the store asynchronously, we need to initialize the store before rendering, inside the bootstrap.tsx.

initStore().then((Store) => {
  root.render(
    <Provider store={Store}>
      <App />
    </Provider>
  );
});

But our implementation has its own problems, first we are waiting the app1, to share with us the store in order to render the dom, this can go sideways in many cases,
first if app1 is down or for whatever reason did not share with us the reducer, the store will not be initialized hence the host will be down.

Special Task for the warriors

You need to figure out a way where if your app1 is down, your host has some sorts of fallback approach and not being down for such an issue in the store.

Looking forward to learn about your solutions!

DEV Community: Ibrahim Shamma

Rspack with Module federation V2 is the future

Github Repo:

Tech Stack

pnpm

React

Typescript

Rspack

Setup project

Initialize dir:

Add ESM Config:

Setup Engine and Package manager:

Add pnpm worksapce

Create apps

Install module federation:

Setup Consumed app

Explanation:

Setup Consumer app:

running the app:

If losing the small battles would win you in the long run then why not?

Manage telescopic constructors with builder pattern using Typescript

The Problem

The Solution

Builder Pattern

Steps:

1. Create an interface for our class

2. Create Builder interface and concrete implementation

What did we do here?

3. Create Director class

Conclusion

From senior engineer to a mentor for software engineers

As a Software Engineer in a startup, plan your leave to the corporate world

Why we end up in Startups in the first place?

With the current bad economy we are more limited

Take off the Ankle Weights, and move faster

Getting to the next level in sinking ship might be your least of a priority

It is not about only coding

Corporates are slow and that's a feature

Embrace the Rough Seas: Why Every Sailor Needs to Weather the Storm

Blind Spots and Boundaries: Navigating the Terrain of Limited Perspective

Conclusion

React Reducers

How to call it

Dispatch:

creating a Project

steps

You may need a Ref not a State.

Use case

to make it short:

state => Mutate + Rerender

ref => Mutate # only

Is it worth it to take it into consideration?

Another Aspect

Code:

Suspense your federated component with caution

Your Federated component may be slow to respond

You may consider not showing multiple spinners in your page

Since we are lazy loading components, these components should have nothing to do with SEO

Side Note: making the intellisense recognize your federated component

Always have plan B when your federated component fails

When you federate a component, you need to have a fallback component

Your homework

A/B Testing through React federated modules

What is A/B Testing?

Repo

Architecture

Now the fun part, code

Your Homework

A simplified prospective in sharing Redux Store between Federated React Apps

Work in action!!

Remote set up

Exposing the Store in action!

Host set up

Cheers!

Intoroduction into Module Federation, the React Parts

Our agenda

The Idea behind module federation

Possible Solution 1:

Possible Solution 2:

let me introduce module-federation.

state => `Mutate` + Rerender

ref => `Mutate` # only

let me introduce `module-federation`.