DEV Community: Ibrahim Shamma

What’s Keeping SWEs Up at Night in the Age of Agentic Engineering

Ibrahim Shamma — Sat, 12 Sep 2026 17:24:37 +0000

We as devs are tired from models, ai, job market and ofc Linkedin crap.

I believe that transformation the industry went through is glorified, at the end of the day, agents produce code, which still needs design, frequent security vulnerabilities updates, and strategic thinking.
Agents will pick up what is used in the internet and keep using it for everywhere, but yet you will still rely on installing packages, in which each package is an entire project by itself that needs maintenance or maybe you want to switch your code from one package that was not maintained or another, or even you want the agent to kick start your own implementation of that package, that by itself a lot of things you need to decide that each has its pros and cons.

Yet alone, a lot of codebases are built upon shallow domain and skills which results massive issues, in terms of some features are not really deliverable at some point due to poor design, or even some issues would require massive code or db changes that needs good planning.

In the before ai era, most of the projects, does not even contain README, nor ci and not going to go through more details, and without proper guardrails it would be impossible for an agent to have a proper success criteria, and would keep consuming tokens and dancing throughout the codebase looking for things to change, that's why agents work best, when you know exactly what you need to do in the codebase, but you leave it mutate tens of files just it would be much faster than you.

Even when it comes to QAs, still imagine that swarm of agents are changing the code aggressively, how would they validate that changes are working as expected yet the existing features are still working as expected, here comes documented UI and integration tests that goes through the entire app with its services, and without these automated checks, it is impossible to trust these massive code changes, even if you wanted to reduce the changes per PR, you will amount of PR bottleneck anyways, QAs can level up, learn how to automate things tests, and setup the infra for these tests to assure that dancing agents are not going to production without proper checks.

On another completely separate topic, I believe engineers should not really be concerned if this is a bubble or not.
Regardless of what is the economic outcome, whether some of companies went bankrupt, we will still have open sourced LLMs, and people will start running locally or per company servers their own LLMs, much like how UBER does now with customer support that relies on Chinese open models.
We are seeing a lot of momentum towards the open models, and host them the way they were hosting their systems already, which if you think of it, it is only the cloud providers and chip makers are winning here, labs won't get to AGI, or AGI is just for everyone, and models would be treated like just a "super cool open source project" that you still need to host it by yourself to do anything serious with it.
Big cloud players like AWS started already selling managed inference layers https://aws.amazon.com/sagemaker/ai/deploy which is a trend we will see more of.

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.

DEV Community: Ibrahim Shamma

What’s Keeping SWEs Up at Night in the Age of Agentic Engineering

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!

state => `Mutate` + Rerender

ref => `Mutate` # only