DEV Community: ELMay

The Long Way Home: How We Left the Server, Built a Client Empire, and Came Back Again

ELMay — Mon, 24 Nov 2025 17:48:13 +0000

In 2010, the web was simple. PHP, Rails, or a bit of jQuery on top of some Twig templates. The server rendered the page, you clicked a link, the browser fetched a new one. That was it.

It was predictable. Honest. And slow.

Then we saw the future — and it was running in the browser.

What if the client handled everything? No refreshes, no full reloads, just pure JavaScript bliss.

We sprinted into that future with React, Redux, Angular, and a thousand frameworks that promised to make the web feel alive.

And then, somewhere along the way, we started missing the simplicity we left behind.

Step 1: From Templates to Trees

Server templates were simple — and static. If you wanted interactivity, you reached for jQuery or hand-rolled AJAX calls. Here’s how a basic product list with a “like” button might have looked:

<ul id="products">
  {% for item in products %}
    <li>
      {{ item.name }} <button class="like" data-id="{{ item.id }}">❤️</button>
    </li>
  {% endfor %}
</ul>

<script>
  $(".like").on("click", function () {
    const id = $(this).data("id");
    $.ajax({
      url: `/api/like/${id}`,
      method: "POST",
      success: () => {
        $(this).text("💙"); // update DOM manually
      },
      error: () => alert("Error liking item")
    });
  });
</script>

It worked — but every bit of behavior meant mixing DOM access, server endpoints, and manual event wiring. You were writing an orchestra by hand.

React collapsed that chaos into components and state:

import { useState } from "react";
import { useMutation } from "@tanstack/react-query";

export function ProductList({ products }) {
  const likeMutation = useMutation({
    mutationFn: async (id: number) => {
      const res = await fetch(`/api/like/${id}`, { method: "POST" });
      if (!res.ok) throw new Error("Failed");
      return id;
    },
  });

  const [liked, setLiked] = useState<number[]>([]);

  const handleLike = async (id: number) => {
    await likeMutation.mutateAsync(id);
    setLiked((prev) => [...prev, id]);
  };

  return (
    <ul>
      {products.map((p) => (
        <li key={p.id}>
          <button onClick={() => handleLike(p.id)}>
            {liked.includes(p.id) ? "💙" : "🤍"} {p.name}
          </button>
        </li>
      ))}
    </ul>
  );
}

With React and React Query, network logic, UI state, and DOM updates live together in one declarative system. Instead of imperatively wiring up selectors and callbacks, we declare what should happen.

From Direct DOM Manipulation → Virtual DOM

Classic jQuery code mutates the DOM directly:

// imperative: find, mutate, rebind
$("#counter").text(Number($("#counter").text()) + 1);
$("#like").toggleClass("active", liked);

React introduced the Virtual DOM and reconciliation:

You describe the UI for a given state as a tree.
React diffs (reconciles) the previous tree with the next one.
Only the minimal DOM mutations are applied.
Updates are batched and event handling is normalized across browsers.

This flips the model:

jQuery: How do I change the DOM to match new state?
React: Given state, what should the UI look like? (React figures out the changes.)

A tiny contrast:

// jQuery – update two places that depend on the same state
price = price + 1;
$("#price").text(price);
$("#summary .price").text(price);

// React – render once from state, VDOM calculates the minimal DOM edits
function Summary({ price }) {
  return (
    <>
      <span id="price">{price}</span>
      <div id="summary">
        <span className="price">{price}</span>
      </div>
    </>
  );
}

This shift from manual DOM diffs to declarative trees is why components scale: fewer incidental ties to selectors, fewer missed updates, and a single source of truth for rendering.

We didn’t just move rendering from the server to the client — we moved responsibility. Now the browser was in charge of logic, state, data fetching, and behavior.

We didn’t realize it yet, but we’d traded static predictability for dynamic complexity.

Step 2: The Rise of State Empires

Before Redux, Facebook introduced Flux — an architectural pattern described in their 2014 documentation. It formalized a unidirectional data flow: actions → dispatcher → stores → view. Redux was heavily inspired by Flux, taking its single-direction flow and reducing it to a pure function model. Flux introduced the idea that predictable state changes are the foundation for scalable UI logic.

Once rendering became dynamic, we needed to synchronize everything: UI, data, user actions, caches. We invented a whole new ecosystem to keep things in order. Redux, MobX, Context, Recoil, Zustand — all born from the same problem: our components were talking too much.

The Verbose Era — Classic Redux for one API call

To fetch a list and show loading/errors, you often wrote actions, reducer cases, and a thunk:

// actions.ts
export const PRODUCTS_REQUEST = "PRODUCTS_REQUEST" as const;
export const PRODUCTS_SUCCESS = "PRODUCTS_SUCCESS" as const;
export const PRODUCTS_FAILURE = "PRODUCTS_FAILURE" as const;

export const productsRequest = () => ({ type: PRODUCTS_REQUEST });
export const productsSuccess = (data: Product[]) => ({
  type: PRODUCTS_SUCCESS,
  payload: data,
});
export const productsFailure = (err: string) => ({
  type: PRODUCTS_FAILURE,
  error: err,
});

// thunks.ts
export const fetchProducts = () => async (dispatch: AppDispatch) => {
  dispatch(productsRequest());
  try {
    const res = await fetch("/api/products");
    const data = await res.json();
    dispatch(productsSuccess(data));
  } catch (e) {
    dispatch(productsFailure(String(e)));
  }
};

// reducer.ts
type State = { loading: boolean; data: Product[]; error?: string };

const initial: State = { loading: false, data: [] };

export function productsReducer(
  state = initial,
  action: AnyAction
): State {
  switch (action.type) {
    case PRODUCTS_REQUEST:
      return { ...state, loading: true, error: undefined };
    case PRODUCTS_SUCCESS:
      return { loading: false, data: action.payload };
    case PRODUCTS_FAILURE:
      return { loading: false, data: [], error: action.error };
    default:
      return state;
  }
}

// component.tsx
const Products = () => {
  const dispatch = useDispatch();
  const { data, loading, error } = useSelector(
    (s: RootState) => s.products
  );

  useEffect(() => {
    dispatch(fetchProducts());
  }, [dispatch]);

  if (loading) return <Spinner />;
  if (error) return <Error msg={error} />;

  return <List items={data} />;
};

That’s ~50–70 lines for a single GET.

The Upgrade — Redux Toolkit & RTK Query

RTK reduced ceremony, but still required API slices, store wiring, and tag invalidation:

// api.ts
import { createApi, fetchBaseQuery } from "@reduxjs/toolkit/query/react";

export const api = createApi({
  reducerPath: "api",
  baseQuery: fetchBaseQuery({ baseUrl: "/api" }),
  tagTypes: ["Products"],
  endpoints: (builder) => ({
    getProducts: builder.query<Product[], void>({
      query: () => "/products",
      providesTags: ["Products"],
    }),
    like: builder.mutation<void, number>({
      query: (id) => ({ url: `/like/${id}`, method: "POST" }),
      invalidatesTags: ["Products"],
    }),
  }),
});

export const { useGetProductsQuery, useLikeMutation } = api;

// store.ts
export const store = configureStore({
  reducer: { [api.reducerPath]: api.reducer },
  middleware: (gDM) => gDM().concat(api.middleware),
});

// component.tsx
function Products() {
  const { data = [], isLoading, error } = useGetProductsQuery();
  const [like] = useLikeMutation();

  if (isLoading) return <Spinner />;
  if (error) return <Error />;

  return data.map((p) => (
    <button key={p.id} onClick={() => like(p.id)}>
      {p.name}
    </button>
  ));
}

Better… but you still manage cache keys and invalidation explicitly.

The Pivot — React Query (Server State, not App State)

Many teams realized most Redux state was actually server cache. React Query built the missing mental model: treat async data as cache with lifecycle.

import {
  useQuery,
  useMutation,
  useQueryClient,
} from "@tanstack/react-query";

function Products() {
  const queryclient = useQueryClient();

  const products = useQuery({
    queryKey: ["products"],
    queryFn: () => fetch("/api/products").then((r) => r.json()),
  });

  const like = useMutation({
    mutationFn: (id: number) =>
      fetch(`/api/like/${id}`, { method: "POST" }),
    onSuccess: () =>
      queryclient.invalidateQueries({ queryKey: ["products"] }),
  });

  if (products.isLoading) return <Spinner />;

  if (products.isError) return <Error />;

  return products.data.map((p: Product) => (
    <button key={p.id} onClick={() => like.mutate(p.id)}>
      {p.name}
    </button>
  ));
}

Why the shift happened

Most Redux stores were 60–90% async data and request status.
We were hand-rolling caches, retries, deduping, and invalidation.
React Query reframed this as server state with built-in policies (staleTime, cacheTime, refetchOnWindowFocus, retries).

Rule of thumb

If it comes from the server and can be refetched: it’s cache → React Query.
If it’s purely UI or business state (wizard step, modal open, form draft): it’s app state → React state / context / small store.

And users? They finally got fast first paint without waiting on a JS state machine just to read a list.

Step 3: The Return of the Server

Eventually, we realized something: shipping megabytes of JavaScript just to render HTML felt backwards. The pendulum swung again.

React 16: modern SSR shows up

React had server rendering long before v16, but React 16 (2017) made it practical at scale: a new fiber architecture, better error handling, and renderToNodeStream for streaming HTML from the server. That turned SSR from a once-per-request snapshot into something that could progressively paint while the server kept working.

React 18: Suspense + streaming

React 18 took the next step: Suspense on the server and better streaming. Instead of blocking on slow data, the server can send a shell early and stream in the rest as it resolves. The client hydrates what arrives, when it arrives.

// Next.js (App Router) – streaming a slow section behind Suspense
export default function Page() {
  return (
    <main>
      <Header />
      <Suspense fallback={<SkeletonProducts />}>
        {/* server component tree that may suspend */}
        <Products />
      </Suspense>
      <CartWidget /> {/* client component */}
    </main>
  );
}

This model clarified responsibilities:

The server can fetch, render, and stream HTML + RSC payloads as data resolves.
The client hydrates interactive islands and handles local state/events.

Why React Server Components (RSCs)?

Once streaming and Suspense were in place, the next logical step was to let components run on the server by default and ship zero JS for them when they don’t need interactivity. That’s RSCs: server-first components that can render data, compose with client components at boundaries, and avoid sending unnecessary code to the browser.

// Server Component
export default async function ProductList() {
  const products = await db.query("SELECT * FROM products");
  return (
    <ul>
      {products.map((p) => (
        <li key={p.id}>
          <ProductCard product={p} />
        </li>
      ))}
    </ul>
  );
}

// Client Component (island)
"use client";

export function ProductCard({ product }) {
  const [liked, setLiked] = useState(false);

  return (
    <button onClick={() => setLiked((v) => !v)}>
      {liked ? "💙" : "🤍"} {product.name}
    </button>
  );
}

The line between client and server is explicit again — a boundary you can design around. The server fetches and streams; the client hydrates and interacts. We stopped asking where to render, and started asking what belongs where.

Step 4: Boundaries Are the New Abstractions

In the early web, the boundary was the HTTP request. In client-heavy apps, it was the component tree. Today, with Server Components, it’s both — a negotiation between network and interactivity.

Each layer takes ownership:

The server renders data-rich UI and serializes context.
The client handles state, input, and event-driven behavior.

They meet at the hydration boundary — the modern contract between performance and experience.

// Next.js app directory example
export default function Page() {
  return (
    <main>
      <Products /> {/* server */}
      <CartWidget /> {/* client */}
    </main>
  );
}

It’s not SSR vs CSR anymore. It’s hybrid by design.

Step 5: The Rise of Islands

Islands: a name for what we were feeling

By 2019–2020, the community started putting a name to a pattern many teams were converging on. Etsy’s frontend architect Katie Sylor-Miller coined the term component islands (2019). In 2020, Jason Miller (creator of Preact) popularized and documented it: render the whole page on the server, then hydrate only the dynamic parts as small, self-contained widgets. In other words: SSR for the canvas, CSR for the hotspots. This is the same idea people describe as partial / selective hydration.

Paraphrasing Miller: “Render HTML on the server and insert slots for dynamic regions that hydrate into small, isolated widgets on the client.”

Islands architecture

Frameworks like Astro, Qwik, and the new Next.js app router push this even further — rendering mostly on the server, but activating “islands” of interactivity in the client.

The server paints the world. The client wakes it up.

The irony? We’ve reinvented the simplicity of PHP templates — only this time, the boundaries are explicit and enforced by design.

Each island is self-contained. Deleting one doesn’t break the others. Adding one doesn’t rehydrate the whole ocean.

We finally learned that composability and isolation are the same thing seen from opposite ends.

Step 6: The Big Lesson

Every architectural shift starts as a rebellion and ends as a reconciliation.

We fled the server because we wanted power. We returned because we needed balance.

The point isn’t to choose between server and client — it’s to respect their boundaries.

The server is great at knowing. The client is great at feeling.

When both do their jobs, users stop noticing where the code runs — and start noticing that it just works.

After a decade of frameworks, state managers, and hydration loops, we’ve come full circle.

We didn’t just rediscover SSR.

We rediscovered discipline.

The Barrel Trap: How I Learned to Stop Re‑Exporting and Love Explicit Imports

ELMay — Sat, 15 Nov 2025 11:00:37 +0000

I was happily building out a small UI library. Everything was neat, clean, and centralized — I had this beautiful index.ts that re‑exported all my components. It felt elegant:

// src/index.ts
export * from “./Button”;
export * from “./Input”;
export * from “./Form”;

Then, one day, a user sent me a message:

“Hey, importing just Button seems to pull in the entire library. My bundle exploded.”

I laughed it off at first. Surely tree‑shaking would take care of that.

But when I checked the build size myself, my laughter turned into that slow developer squint of dread. I’d fallen into the barrel trap.

Step 0: Just Export Everything

It starts innocently. You think you’re making life easier:

import { Button, Input } from “@important-lib”;

It’s clean! Users love it. The DX feels fantastic.

Until one day, you try to optimize something — and everything slows down. TypeScript starts crawling. Your IDE fans spin up. You import one thing, and half your repo joins the party.

What happened?

Step 1: Find a Repro

Every performance bug starts with denial. I thought, this can’t be the barrel’s fault. So I tried to measure it.

I created two test files:

// app/barrel-import.ts
import { Button } from “@important-lib”;

// app/direct-import.ts
import { Button } from “@important-lib/button”;

Then bundled both with Vite:

npx vite build

And finally, compared sizes:

ls -lh dist/assets/*.js dist/*.js dist/chunks/*.js

Barrel version: 210 KB.
Direct version: 47 KB.

The barrel was importing everything — Input, Form, Modal, Table, you‑name‑it.
My IDE lag wasn’t a coincidence; it was TypeScript resolving every symbol I ever exported.

That was my scroll jitter moment.

Step 2: Narrow the Repro

The problem was clear but broad. Was it Rollup’s fault? TypeScript? My export style?
To isolate it, I commented out just one line at a time in index.ts.

// export * from “./Input”;
// export * from “./Form”;
export * from “./Button”;

Each deletion shrank the bundle size.

At some point, I realized that even with no side effects, just the re‑export itself forces TypeScript and bundlers to crawl dependency graphs to merge type declarations and resolve names.

It’s like your barrel whispers: “I don’t know what’s inside these modules, but please go find out, every single time.”

So yeah, my problem wasn’t React Router — it was me.

Step 3: Remove Everything Else
At this point, I decided to take my own medicine.
I started deleting code — not randomly, but with a rule:

After each change, I must still reproduce the bloat.

One by one, I removed:

components

re‑exports

export * wildcards

lazy imports

Every time, I checked the bundle. Eventually, I ended up with one clean entry point that re‑exported only three components. The bundle dropped to 60 KB.

The bug — or more precisely, the hidden cost — was gone.

It wasn’t the toolchain’s fault. It was my pattern’s.

Step 4: Find the Root Cause

Here’s what I learned.

Barrels are fine in apps because the app owns its graph. It’s one build. You know what’s included. You don’t care about tree‑shaking that much.

Barrels are a mess in libraries because they:

confuse tree‑shaking (export * = black box)
slow type analysis
hide dependency coupling
flatten your API in ways that make versioning risky

The library becomes one giant namespace where every import knows about every other import. Even if you only ship one component, your users pay for all of them in type time or bundle size.

Step 5: Build a Better Export Map

Here’s how I fixed it with explicit exports:

{
  “name”: “@important-lib”,
  “type”: “module”,
  “exports”: {
    “.”: {
      “types”: “./dist/index.d.ts”,
      “import”: “./dist/index.js”
    },
    “./button”: {
      “types”: “./dist/button.d.ts”,
      “import”: “./dist/button.js”
    },
    “./input”: {
      “types”: “./dist/input.d.ts”,
      “import”: “./dist/input.js”
    }
  }
}

Now users can do:

import { Button } from “@important-lib/button”;

and only get what they actually use.

Tree‑shaking started working again. Type checking became instant. The IDE stopped gasping for air.

Step 6: Try It Yourself (Vite Edition)

If you want to benchmark your own library, here’s your repro template with Vite:

Create a minimal consumer app.

npm create vite@latest barrel-repro -- --template react-ts
cd barrel-repro
npm i

Add two entry files.

// app/barrel-import.ts
import { Button } from “@important-lib”;

// app/direct-import.ts
import { Button } from “@important-lib/button”;

Tell Vite to build both entries.
Create vite.config.ts:

import { defineConfig } from “vite”;
import react from “@vitejs/plugin-react”;
import { resolve } from “path”;

export default defineConfig({
  plugins: [react()],
  build: {
    rollupOptions: {
      input: {
        barrel: resolve(__dirname, “app/barrel-import.ts”),
        direct: resolve(__dirname, “app/direct-import.ts”),
      },
      output: {
        // keep names stable for easier diffing
        entryFileNames: “[name].js”,
        chunkFileNames: “chunks/[name]-[hash].js”,
        assetFileNames: “assets/[name]-[hash][extname]”,
      },
    },
  },
});

Build and compare sizes.


npx vite build
ls -lh dist/*.js dist/chunks/*.js

If your barrel.js pulls in many more chunks (or is much larger) than direct.js, you’ve got your reproducible proof.

Now start deleting exports until you can’t make it any smaller.

🎉 Bonus: Name Your Chunk in Vite to Spy on Bloat
Sometimes the bundle analyzer is overkill. You just want to force a suspicious dependency into a named chunk so it’s obvious when it shows up. Vite lets you do this via Rollup’s manualChunks.

Add this inside vite.config.ts → build.rollupOptions.output:

output: {
  entryFileNames: “[name].js”,
  chunkFileNames: “chunks/[name]-[hash].js”,
  assetFileNames: “assets/[name]-[hash][extname]”,
  manualChunks(id) {
    // Anything coming from @important-lib becomes its own chunk
    if (id.includes(”@important-lib”)) return “important-lib”;

    // Optionally split all node_modules into vendor
    if (id.includes(”node_modules”)) return “vendor”;
  },
}

Now, when you build:

npx vite build

You’ll see a clear chunks/important-lib-*.js. Import from the barrel and see if it drags important-lib in; switch to subpath imports and verify that the chunk disappears (or gets much smaller). It’s a dead-simple, visual lie detector for barrels.

Step 7: The Bigger Lesson

Every barrel starts as a convenience and ends as an obligation.
It’s not that barrels are evil — it’s that they hide the edges of your system.

Once you lose edges, you lose insight.

The cure is the same as debugging anything complex: isolate, measure, remove, repeat.

That’s how you fix any bug — even the ones you wrote on purpose.

React Fundamentals part 3: JSX

ELMay — Sun, 11 Feb 2024 10:43:33 +0000

Writing our code with React.createElement() and reactDOM.render()is a little bit verbose; not that readable.

The good thing the react team thought about that too and create a HTML-like syntactic suger on top of the raw React Api's called JSX

JSX rewrites your JavaScript files

JSX is just a tool that converts files like this:

const element =
  <div id="container">
    Hello, world!
  </div>

into files like this:

const element =
  React.createElement(
    'div',
    {id:'container'},
    "Hello, world!"
  )

Why use JSX?

To use JSX with reasonable performance, you'd need a build process, which would entail (at a minimum) understanding and installing node.js and create-react-app or babel. While this is usually acceptable, there are times when you'd rather avoid the overhead.

Learning all of this just to avoid typing createElement() a few times doesn't make much sense if you're just getting started. However, there will come a point when your apps will be large enough that tooling will be a worthwhile investment. And once you've arrived at this point, JSX is a fantastic tool to have:

Large element definitions are simplified.
It provides visual cues and assists editors with syntax highlighting.
It assists React in producing more useful error and warning messages

Because JSX is not actually JavaScript, you have to convert it using something called a code compiler. [Babel]

Pro tip: If you'd like to see how JSX gets compiled to JavaScript, check out the online babel REPL here.

Because JSX is not actually JavaScript, it must be converted using a code compiler. One such tool is Babel.

If you want to see how JSX is compiled to JavaScript, use the online babel REPL.

So let's convert our code to JSX. First of all, like react and reactDOM, we will add babel script from unpkg

 ...
   <body>
    <div id="root"></div>
    <script src="https://unpkg.com/react@17.0.0/umd/react.development.js"></script>
    <script src="https://unpkg.com/react-dom@17.0.0/umd/react-dom.development.js"></script>
    <script src="https://unpkg.com/@babel/standalone@7.12.4/babel.js"></script>
    <script type="module">

    const element = React.createElement('div', {
      className: 'container',
      children: 'Hello World',
    })

    ReactDOM.render(element, document.getElementById('root'));
    </script>
  </body>
...

Then let's try to change our React.createElement() to JSX

...
<body>
  <div id="root"></div>
  <script src="https://unpkg.com/react@17.0.0/umd/react.development.js"></script>
  <script src="https://unpkg.com/react-dom@17.0.0/umd/react-dom.development.js"></script>
  <script src="https://unpkg.com/@babel/standalone@7.12.4/babel.js"></script>
  <script type="text/babel">
    // 🔥 "type="text/bable" to indicate that this code need to be compiled by babel

    // const element = React.createElement('div', { className = 'container' }); 

                                          👇

    const element = <div className="container"></div>
    ReactDOM.render(element, document.getElementById('root'))
  </script>
</body>
...

You may have noticed that I changed the type of our JavaScript from module to text/babel and that's to indicate to the browser not to evaluate the script . However, babel will control the compiling for that script;

Easy right? How about children?

...
<body>
  <div id="root"></div>
  <script src="https://unpkg.com/react@17.0.0/umd/react.development.js"></script>
  <script src="https://unpkg.com/react-dom@17.0.0/umd/react-dom.development.js"></script>
  <script src="https://unpkg.com/@babel/standalone@7.12.4/babel.js"></script>
  <script type="text/babel">
  // 🔥  "type="text/bable" to indicate that this code need to be compiled by babel

    // const element = React.createElement('div', { className = 'container' }, [
    //  React.createElement('div', { className = 'container' }, "I'm the first child"),
    //  React.createElement('div', { className = 'container' }, "I'm the first child"),
    // ]); 
                                    👇 

    const element = (
      <div className="container">
        <div className="firstChild">I'm the first child</div>
        <div className="secondChild">I'm the second child</div>
      </div>
      );
    ReactDOM.render(element, document.getElementById('root'));
  </script>
</body>
...

JSX appears to be HTML, but it is transformed into plain JavaScript objects under the hood by babel.

You can't return two objects from a function unless they're wrapped in an array. This explains why you can't return two JSX tags without first wrapping them in another tag or fragment.

References and articles:

Writing Markup with JSX – React

react.dev

JavaScript in JSX with Curly Braces – React

react.dev

Introducing JSX – React

legacy.reactjs.org

JSX In Depth – React

legacy.reactjs.org

Introducing the New JSX Transform – React Blog

legacy.reactjs.org

2024 React Cheatsheet | SheCodes

SheCodes teaches coding skills to women.

cheatsheets.shecodes.io

React Fundamentals part 2: Basic view on React core API's

ELMay — Fri, 09 Feb 2024 16:45:00 +0000

In this section we will try to understand raw React API, how we implement them ,what do they do and how are they different from just generating DOM Nodes with Vanilla JavaScript.

In the previous section we saw how to create DOM elements, how we append them to the DOM tree so we can see our element.

...
  <body>
    <div id="root"></div>
    <script type="module">
    const rootElement = document.getElementById('root')

      // We always need to append the root element to the document
      document.body.append(rootElement);
    </script>
  </body>
...

React abstracts away the imperative browser API from you to give you a much more declarative API to work with.

Learn more about the difference between those two concepts here: Imperative vs Declarative Programming

With that in mind, you need two JavaScript files to write React applications for the web:

React: responsible for creating React elements (kinda like document.createElement())
ReactDOM: responsible for rendering React elements to the DOM (kinda like rootElement.append())

Let's convert our file to use React! using just raw React APIs here.

In modern applications you'll get React and React DOM files from a "package registry" like npm (react and react-dom).

But we will use https://unpkg.com/. It's CDN (global content delivery network) that will allow us ready-to-use script files in regular script tags so you don't have to bother installing them.

 ...
   <body>
    <div id="root"></div>
    <script src="https://unpkg.com/react@17.0.0/umd/react.development.js"></script>
    <script src="https://unpkg.com/react-dom@17.0.0/umd/react-dom.development.js"></script>
    <script type="module">
     const rootElement = document.getElementById('root')

      // We always need to append the root element to the document
      document.body.append(rootElement);
    </script>
  </body>
...

That's it. We have React and ReactDOM as global variable that we can use in our code

React.createElement()

Syntax:

React Top-Level API – React

legacy.reactjs.org

React.createElement() takes three arguments. They are:

type: The type argument can be either a HTML element tag name string (such as 'div' or 'span'), a React component type (a class or a function), or a React fragment type.
props: n object containing properties ('props' in React terms) that get passed to the component. Since we're just getting started with React, we won't use these just yet — but be aware that the second options serves this purpose.
children: the last argument is the children of that component. This can be a quoted string in which case the content will be interpreted as text. However, we can also pass in a reference to another component, allowing us to nest elements and components within each other

The third and subsqeuent arguments to React.createElement() are always added to the props as children — regardless of the type.

So if you create an element with a custom type and children, you can access those children on its props.

In fact, these two createElement() calls are equivalent:

If we want one child for our element we can provide it within the props like the example below

 // Children as prop
 const element = React.createElement('div', {
      className: 'container',
      children: 'Hello World',
    })
 // children as createElement THird argument   
 const element = React.createElement('div', {className: 'container'},'Hello World',)

But if we want to add multiple children, then we can only use the third argument

const title = React.createElement('h1', {}, 'My First React Code');
const paragraph = React.createElement('p', {}, 'Writing some more HTML. Cool stuff!');
const container = React.createElement('div', {}, [title, paragraph]);

Children's children

We can nest children as much as we want. We also don't need to store our elements in variables before using them, we can declare them inline as well (though the downside of this is less readable code):

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

const list =
  React.createElement('div', {},
    React.createElement('h1', {}, 'My favorite fruit'),
    React.createElement('ul', {},
      [
        React.createElement('li', {}, 'orange'),
        React.createElement('li', {}, 'apple'),
        React.createElement('li', {}, 'Banana')
      ]
    )
  );

ReactDOM.render()

One important thing to know about React is that it supports multiple platforms (for example, native, web, VR). Each of these platforms has its own code necessary for interacting with that platform, and then there's shared code between the platforms.

Syntax:

ReactDOM – React

legacy.reactjs.org

ReactDOM.render() takes two arguments:

element: The element that needs to be rendered in the DOM.
containerElement: Where to render in the DOM.

React implements a browser-independent DOM system for performance and cross-browser compatibility and renders it using ReactDOM().

The React Element objects that React.createElement() returns are just plain old JavaScript objects that describe the DOM nodes that you’d like ReactDOM.render() to create. They’re **_not*_* DOM nodes, and _not*_* added to the document. They’re just objects.**

ReactDOM()will create a DOM node and append or render our react app into a specific element that's going to behave as our app root

Let's see how our code will be using these two script files

 ...
   <body>
    <div id="root"></div>
    <script src="https://unpkg.com/react@17.0.0/umd/react.development.js"></script>
    <script src="https://unpkg.com/react-dom@17.0.0/umd/react-dom.development.js"></script>
    <script type="module">

    const element = React.createElement('div', {
      className: 'container',
      children: 'Hello World',
    })

    ReactDOM.render(element, document.getElementById('root'));
    </script>
  </body>
...

References and articles:

Top-Level API | React

zhenyong.github.io

🏁 What's a design system anyway ? ?

ELMay — Tue, 06 Feb 2024 17:24:07 +0000

The scale and speed at which UI screens must be created has increased as UI design has improved over time. Not only are there millions of apps and billions of websites (with more being launched every year), but each app and website may have hundreds or thousands of pages (or screens). With such rapid growth comes a pressing need for businesses to streamline their design processes. As a result, many design teams rely on sophisticated design systems to manage large-scale projects.

What is a Design System?

Definitions of what a design system is:

“The complete set of design standards, documentation, and principles along with the toolkit (UI patterns and code components) to achieve those standards”

— Uxpin.com

“Simply put, a design system is a collection of reusable components to tie whole products together”

— Freecodecamp.org

“Everything that makes up your product” — “From typography, layouts and grids, colors, icons, components and coding conventions, to voice and tone, style-guide and documentation, a design system is bringing all of these together in a way that allows your entire team to learn, build and grow”

— css-tricks.com

We can conclude by defining the design system*by a complete set of standards intended to manage design at scale ****_* using reusable components and patterns.**

Contents of a Design System

Despite the fact that not all design systems are the same (most are customised to a certain brand or product), they all contain similar content. The design system consists of the brand's shared values and purpose, design principles, brand identity and language, style-guides, components and patterns, coding conventions, best practices, and rules that guide it, all with the goal of facilitating teamwork.

Before diving deep in the content of the design system we should first understand the Atomic design concept ****

What is Atomic Design?

Atomic Design is a methodology developed by Brad Frost. The modular structure of this methodology breaks down building blocks of design such as buttons, search bars and navigation into a hierarchy of components based on chemistry principles:

Atoms are the most fundamental UI elements, such as icons and buttons, that can't be broken down any further.
Molecules are a collection of atoms that come together to form a more complicated component, such as a search bar. In this example, the search bar component will have the input field, search button, and icon.
Organisms, like a top navigation bar, are even more complicated components that can incorporate both molecules and atoms. The navigational atoms "home" and "login," as well as the molecular component of the search bar and the brand insignia, may be included in the bar.

What Is A Style Guide?

Style guides include specific implementation guidelines, visual references, and design principles for developing interfaces and other design deliverers. Most style guides are focused on branding or editorial style.

Medium Logo Usage Guidelines | by Medium | Medium.design

The Medium logo, wordmark, and symbol are important expressions of our brand identity. They have each been carefully designed and constructed to achieve visual harmony, should never be altered…

medium.design

ant.design

design.gs.com

Acceptable logo usage, color palette, font trademarks, and print media are frequently specified in branding style guides.

Writing style, grammar, punctuation, Voice and Tone, and other content-editing criteria are all specified in editorial style guidelines. Many websites and magazines have style guides, which content teams are expected to adhere to.

However, style guides also provide content guidance, such as visual and interaction design standards.

These guidelines are occasionally incorporated into the component library to provide context-specific guidance.
The simplest list of style guide content can be like this

Purpose — Individual parts of the company's goals, ethics, perspective,
Product Branding Guidelines – A company's internal product and service branding guidelines.
Visual Elements — Where components' visual styling is specified.
Fonts — Fonts and information on how to use them.
Product Editorial Guidelines — Grammar, punctuation, and other content-editing rules
Language – The ability to communicate clearly in one or more languages..

What Is A Component Library?

Many people associate design systems with component libraries (also referred to as design libraries): these large libraries contain predefined, reusable user interface elements and serve as a one-stop shop for designers and developers to learn about and build various UI components. It takes a significant amount of time and effort to build these libraries.

In general, they include some graphical examples of components.

A component library must include

Component name: a specific and unique UI component name, to avoid miscommunication between designers and developers
Description: a clear explanation for what this element is and how it is typically used, occasionally accompanied by do’s and don’ts for context and clarification
Attributes: variables or adjustments that can be made to customize or adapt the component for specific needs (i.e., color, size, shape, copy)
State: recommended defaults and the subsequent changes in appearance
Code snippets: the actual code excerpt for the element (some design systems go as far as sharing multiple examples and offering a “sandbox” environment to try out different component customizations)
Front-end & backend frameworks to implement the library (if applicable), to avoid painful and unnecessary debugging

design.gs.com

ant.design

What Is A Pattern Library?

The terms 'component library' and 'pattern library' are sometimes used interchangeably, although there is a difference between the two types of libraries. Individual UI elements are specified in component libraries, whereas pattern libraries contain sets of UI-element groups or layouts. When compared to component libraries, pattern libraries are typically perceived to be less robust, yet they can be as detailed or as high-level as desired. Content structures, layouts, and/or templates are usually included. The patterns, like the components, are meant to be reused and adapted.

design.gs.com

How to Approach Design-System Adoption

With my numerous affiliation with startups, at the start we certainly will be a small team

The most non costly way is to adopt an existing design system.

To say the truth and it's extremely subjective I use Ant design design system, in all my small projects, MVP or just to create something for fun, as i loved it and i will always use it.

We need to always remember the objective of our choice, resources and Time limit.

Projects grow and mature, and you start having the urge to optimize your branding, hiring designers, thus adapting the design system to your designers need. creating a specific package of reusable custom components tweeked from the adopted design system

Finally you start to expand, and have multiple project that use the same components, patterns custom brand philosophies and design principals and you find yourself in need to create your own design system

So there are generally three approaches to using a design system:

adopting an existing design system
adapting an existing design system
creating your own proprietary or custom design system

Each has advantages and disadvantages, but in general, the more customized your design-system solution, the more time and money it will take to implement. As a result, using an existing design system is the least expensive and takes the least amount of time to implement. (It will still take longer than if you just keep designing as usual because you will have to replace or update some UI elements and agree on a standard.)

If the organization has specific needs that cannot be met by open-source design systems, the investment in a custom design system will be worthwhile. As customizations and adjustments to the design system increase, the cost savings you may have gained by using the existing design system will diminish, and you may be better off creating your own design system anyway in the long run. Before embarking on design system endeavors and weighing the tradeoffs, make sure you understand what your organization requires.

Finally, establishing a full-fledged design system for a proof of concept or an initial prototype that is expected to alter is likely to be time and money consuming. After all, the benefit is design replicability, which is in the future. Though it may be tempting to establish these right away, note that a design system isn't intended to be a portfolio of work, but rather a functional toolkit or resource that allows designers and developers to work more efficiently. Nevertheless, if you are unsure about the usefulness of a design system, think about the duration you will use to evaluate your design work. When a company anticipate years of future, iterative design work, design systems are ideal.

Why Use a Design System?

When properly implemented, design systems can provide a design team with numerous benefits:

Projects in design (and development) can be easily developed and replicated at a scale. The major value of design systems is their ability to quickly duplicate concepts using pre-made UI components and elements. Teams can reuse the same components over and over, reducing the need to reinvent the wheel and the risk of unintentional inconsistency.
It frees up design resources to focus on bigger, more complex problems. Since the most basic UI elements have already been created and are reusable, design resources can concentrate on tackling more difficult problems rather than fine-tuning the aesthetic look (like information prioritization, workflow optimization, and journey management). While this benefit may seem modest when only a few screens are created, when dozens of teams and thousands of screens are involved, it becomes considerable.
It creates a unified language within and between cross-functional teams.\ A single language eliminates wasted design or development time caused by miscommunications, especially when design responsibilities shift or teams grow geographically dispersed.
Visual consistency is achieved across products, channels, and departments. The absence of an organization-wide design system can result in uneven visual appearance and experiences that appear fragmented or unrelated to the brand, especially when teams work in silos, where each product or channel functions independently of the others. Design systems connect disparate experiences by providing a common source of components, patterns, and styles that make them visually harmonious and appear to be part of the same ecosystem. Any big visual rebranding or redesigns can also be managed at scale using the design system.
It can serve as an educational tool and reference for junior-level designers and content contributors. \ Individual contributors who are new to UI design or content development can be onboarded with explicit use instructions and style guides, which also act as a reminder to the rest of the contributors.

Why Not Use a Design System?

There are some potential hurdles and limitations which may prevent a design team from using a design system:

Creating and maintaining a design system is a time-consuming task that necessitates the presence of a dedicated team. Unfortunately, design systems are not a one-size-fits-all answer. They are continually improving at their best, as teams gather feedback from those who utilize them.
Teaching others how to use the design system takes time. Even if it was derived from an existing system, any design system need instructions for use; otherwise, it risks being applied inconsistently or improperly across screens or across teams.
There's a widespread assumption that projects are one-off, static creations that don't require reusable components. This notion, whether accurate or not, may indicate a lack of a coherent strategy across projects and a wasted opportunity to improve efficiency.

Conclusion

The graphics Styles and their applications are the center of this style guide. Colors, fonts, graphics, illustrations, and so on are examples of graphic style. The pattern library, on the other hand, will provide functional components as well as how they are used. The visual styling of components is defined by the style guide.
The visual and interactive aspects of components are defined by the components library. how a component should behave when clicked or hovered over, or how a form should behave when an incorrect input is entered.
The behavior of components is also explained in the pattern library. But in a comprehensible fashion, because a pattern is only a collection of 1 to n components.
Everything in the pattern library, brand value, shared ways of working, mindset, and common belief is contained in the design system. It includes everything you'll need to get started on your design and development project. It can include a code snippet or a link to the code snippet for developers.
Design systems are made up of a variety of components, patterns, styles, and rules that can help you operationalize and optimize your design efforts. People, on the other hand, are in charge of planning, managing, and implementing them. The breadth and replicability of your projects, as well as the money and time available, are the most critical factors to consider while creating a design system. If established and managed wrong, design systems can become unmanageable collections of components and code; yet, when handled properly, they can educate team members, speed work, and empower designers to tackle difficult UX problems.

React Fundamentals part 1 : The Basic javascript "Hello world"

ELMay — Tue, 06 Feb 2024 16:51:36 +0000

Going back to basics allows us to review knowledge and, or we can put it this way, connect the dots on ambiguous aspects.

Before tackling React, maybe we should review how to make a basic web page using Vanilla JavaScript.

Minimal web page

Basically, the most minimal thing that we can call a web page is just one HTML File that says "Hello world".

Like this one

The browser parses this HTML code and creates the DOM (Document Object Model). The browser, then, exposes the DOM to JavaScript. At that point, your web page will become interactive where you can do the basic events that we will talk about in another Section.

To read more about the Document Object Model (DOM):

developer.mozilla.org

JavaScript Vs DOM Vs BOM, relationship explained | Rajakvk's BlogJavaScript Vs DOM Vs BOM, relationship explained – Rajakvk’s Blog

To understand these terms clearly, we need to know how JavaScript implemented. Indeed, a complete JavaScript implementation is made up of three distinct parts The Core (based on ECMAScript spec) Th…

vkanakaraj.wordpress.com

Now, if we want to add some JavaScript we can just use the script tag

ES6 modules

In order to ensure that the ES6 features to works, the <script> tag in your HTML file will need to have the attribute type="module". Surprisingly, this actually works as-is in most modern browsers.

DOM Manipulation

The first question ever that I asked myself was how can JavaScript interact with the DOM?

How can I really create, modify or delete DOM element using JavaScript? These questions lead to my two first JavaScript commands I wrote:

The DOM represents a document with a logical tree. Each branch of the tree ends in a node, and each node contains objects. DOM methods allow programmatic access to the tree. With them, you can change the document's structure, style, or content.

Manipulating an Element is easy we can add styling or getting and adding content. Let's try to play with some stuff

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
    /* just some indicative styling */
    <style>
      #root {
        background-color: aqua;
      }
    </style>
  </head>
  <body>
    <script type="module">
      const root = document.createElement('div');

      // Adding htmlElement attributes to our root element
      // https://developer.mozilla.org/en-US/docs/Web/API/Element/setAttribute
      root.setAttribute('id', 'root');

      // https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent
      root.textContent = 'Hello world';

      // We always need to append the root element to the document
      document.body.append(root);
    </script>
  </body>
</html>

As you can see, I added the id selector and the class selector to the root element. I added some styling and even added our "hello world" text.

Since we are always able to use HTML tags to create the div element with its attributes, I just wanted to show how JavaScript can leverage all of that in code.

People were creating HTML on the server and then layering JavaScript on top of it for interactivity. However, as the requirements for that interactivity grew more difficult, this approach resulted in applications that were difficult to maintain and had performance issues.

As a result, instead of defining the DOM in hand-written HTML, modern JavaScript frameworks were developed to address some of the issues like our beloved React.

References and articles:

javascript.info

🏁 Build tool choice for MVP projects

ELMay — Wed, 31 Jan 2024 11:40:44 +0000

Creating React app really doesn't need any fancy builder as you can do it by your self with just a simple CDN, thus that approach can work for small exercises or just playing with code , in real world we use building tools that facilitate the task of configuring the project bundling the app and managing 3'rd tiers libraries.

The most common choice is :

https://create-react-app.dev

It was a very good build tool: it has a lot of integrations that is mature and solid for common business logic . but in modern days i remarked a swift shift to:

https://vitejs.dev

Like create-react-app it's a build tool created by Evan You the creator of Vue.js.

It's by far faster than create react up as it uses Rollup under the hood against the MegaZord webpack used by Create-react-app.

https://www.youtube.com/watch?v=DkGV5F4XnfQ

For all my personal small projects i use Vite as it's blazing fast. but for more complex projects i will choose a framework like next.js. For now let's stick with vite and JavaScript. and i will talk about my favorite stack in the **** react ecosystem section

You can read more about Vite comparison :

https://theodorusclarence.com/blog/vite-cra

Quick guide;

Installation

Vite has various template to chose from as it's not specific to React.

vanilla
vanilla-ts
vue
vue-ts
react
react-ts
preact
preact-ts
lit-element
lit-element-ts
svelte
svelte-ts

As in the fundamentals section we will use only JavaScript we will build our app by just running this command.

With NPM:

$ npm init vite@latest

With Yarn:

$ yarn create vite

You can also directly specify the project name and the template you want to use via additional command line options. For example, to scaffold a Vite + React project, run:

# npm 6.x
npm init vite@latest name-of-the-project --template react

# npm 7+, extra double-dash is needed:
npm init vite@latest name-of-the-project -- --template react

# yarn
yarn create vite name-of-the-project--template react

Then just go to your newly created project and install the dependencies and then run the project.

 cd name-of-the-project
 // npm 
 npm install
 npm run dev
 // yarn 
yarn
yarn dev

I did choose react-grimoire as the name of the project but you can name what ever you please

And here you go a react project ready to use . simple right ??

Conditional React props with TypeScript

ELMay — Thu, 03 Feb 2022 19:26:13 +0000

A prop which should only be set when another prop has a specific value.

Relationships between React component props can make you feel the pinch. This article will be your road-map to conditional props pattern employed using Typescript. I will propose different situations and demonstrate the answers to these questions:

How can we create a dependent relationship between several props using TypeScript?

What can we do to have it generate TypeScript errors when a relationship is broken?

Conflicting properties

Working on a design system, I had to create an avatar component. To pass props to the avatar component, different conditions were present:

If i pass the icon prop i can't pass the src prop
If i pass the src prop i can't pass the icon prop

Here an example for the simple avatar component without the conditions

type AvatarProps = {
  icon?: JSX.Element;
  src?: string;
  children:React.ReactNode;
};

export const Avatar = (props: AvatarProps): JSX.Element => {
  const { icon, src } = props;
  return (
    <div>
      {icon && icon}
      {JSON.stringify(src)}
      {children}
    </div>
  );
};

If we import the component while passing both props, the component will not raise any errors.

Therefore, we have to provide an indication for the developer to tell them that passing the two in the same time is forbidden by just throwing a typescript error.

To achieve that , we can create union type using two types that reflect the two scenarios our component supports:

interface CommonProps {
  children?: React.ReactNode

  // ...other props that always exist
}

type ConditionalProps =
  | {
      icon?: JSX.Element;
      src?: never;
    }
  | {
      icon?: never;
      src?: string;
    };

type Props = CommonProps & ConditionalProps  

export const Avatar = (props: Props): JSX.Element => {
  const { icon, src } = props;
  return (
    <div>
      {icon && icon}
      {JSON.stringify(src)}
      {children}
    </div>
  );
};

For those of you who are already familiar with TypeScript, that should be sufficient information

However, in just a few lines of code, there is a lot going on. Let's break it down into chunks if you're wondering about what it all means and how it all works.

interface CommonProps {
  children: React.ReactNode

  // ...other props that always exist
}

CommonProps is your typical props definition in TypeScript. It’s for all of the “Common” props that figure in all scenarios and that aren’t dependent on other props. In addition to children, there might be shadow, size, shape, etc.

type ConditionalProps =
// If i pass the icon prop i can't pass the src prop
  | {
      icon?: JSX.Element;
      src?: never;
    }
// If i pass the src prop i can't pass the icon prop
  | {
      src?: string;
      icon?: never;
    };

ConditionalProps is where the magic happens. It’s what’s called a ”discriminated union.” It’s union of object definitions.

Let’s break it down further and we’ll come back to see how the discriminated union works for us.

{
 icon?: JSX.Element;
 src?: never;
}

The first part of the discriminated union is when the icon prop is defined, In this case, we want the src prop to be invalid. It shouldn’t be able to be set.

{   
 icon?: never;
 src?: string;
};

The second part is when the icon prop is unspecified (undefined). Then we can pass the src props with no problems

type ConditionalProps =
  | {
      icon?: JSX.Element;
      src?: never;
    }
  | {
      icon?: never;
      src?: string;
    };

So now back to the entire discriminated union. It’s saying that the configuration for the icon and src props can either be the first case or the second case.

It's worth noting that we've used the keyword never in this example. The best explanation of this keyword can be found in the TypeScript documentation:

“TypeScript will use a never type to represent a state which shouldn’t exist.”

To reiterate, we defined two types for two scenarios and combined them using the union operator.

type Props = CommonProps & ConditionalProps

Props becomes the intersection of CommonProps and ConditionalProps.

Props is the combination of the two types. So it’ll have all the properties from CommonProps as well as this dependent relationship we created with ConditionalProps.

Now finally, in the Avatar component, both the icon and src props will be of there type respectively JSX.Element | undefined and string | undefined So their types come out straightforward as if you hadn’t created the dependent relationship.

Now if we try to provide both props, we will see a TypeScript error:

Conditional prop variation

I needed to create a component with different variants, for each variant we have a set of props .

We want those props to be provided only when a matching variant is selected.

in our case we have 3 variants "text" | "number" | "element"

If the we chose to set the variant to text , we need to have a message prop of type string, and we can't set componentName prop
If the we chose to set the variant to number , we need to have a message props of type number, and we can't set componentName prop
If we do pass the variant as element , here we can use finally componentName also the message prop will become of type JSX.Element

Lets take a look at this example

interface CommonProps {
  children?: React.ReactNode;
  // ...other props that always exist
}
type ConditionalProps =
  | {
      componentName?: string;
      message?: JSX.Element;
      variant?: "element";
    }
  | {
      componentName?: never;
      message?: string;
      variant?: "text";
    }
  | {
      componentName?: never;
      message?: number;
      variant?: "number";
    };

type Props = CommonProps & ConditionalProps;

export const VariantComponent = (props: Props): JSX.Element => {
  const { message, componentName, variant = "element", children } = props;
  return (
    <div>
      {message && message}
      {variant === "element" && componentName}
      {children}
    </div>
  );
};

/* 
 * If the we chose to set the variant to text,
 * we need to have a message props of type string,
 * We can't set componentName prop
 */

{
 componentName?: never;
 message?: string;
 variant?: "text";
}

/*
 * If the we chose to set the variant to number,
 * we need to have a message props of type number,
 * and we can't set componentName prop
 */
{
 componentName?: never;
 message?: number;
 variant?: "number";
}

/*
 * If we do pass the variant as element, 
 * here we can use finally componentName
 * also the message prop will become of type JSX.Element
 */
{
 componentName: string;
 message?: JSX.Element;
 variant?: "element";
}

Once we set the variant prop , TypeScript narrows down component’s type to their respective desired properties and tells you what you need to provide

Conditional props for collection with generic type

For our next use case, let’s try defining conditional props for a Select component. Our component needs to be flexible enough to accept an array of strings or objects for its options property.

If the component receives an array of objects, we want the developer to specify which fields of those objects we should use as a label and value.\

Conditional types for collection property

type SelectProps<T> =
  | {
      options: Array<string>;
      labelProp?: never;
      valueProp?: never;
    }
  | {
      options: Array<T>;
      labelProp: keyof T;
      valueProp: keyof T;
    };

export const Select = <T extends unknown>(props: SelectProps<T>) => {
  return <div>{JSON.stringify(props)}</div>;
};

To match the object that the user provide to the select. we can use generics in TypeScript.

{
 options: Array<T>;
 labelProp: keyof T;
 valueProp: keyof T;
}

In our second type, we change the options prop from Array<Object> to Array<T> for our generic object. The client has to provide an array of items of the generic object type.

We're using the keyof keyword to tell TypeScript that we're expecting labelProp and valueProp to be generic object fields.

Now when you try to provide valueProp or labelProp, you’ll see a nice autocomplete suggestion based on the fields of the options items.

However, there is a minor change that we must make in order to avoid certain issues. We want to make sure that the generic object we've been given is a custom object rather than a primitive, such as a string:

type SelectProps<T> = T extends string
  ? {
      options: Array<string>;
      labelProp?: never;
      valueProp?: never;
    }
  : {
      options: Array<T>;
      labelProp: keyof T;
      valueProp: keyof T;
    };

export const Select = <T extends unknown>(props: SelectProps<T>) => {
  return <div>{JSON.stringify(props)}</div>;
};

Here we changed the union type by ternary operator to check if our generic type is a string, and based on that, we set our component’s type to the appropriate option.

DEV Community: ELMay

The Long Way Home: How We Left the Server, Built a Client Empire, and Came Back Again

Step 1: From Templates to Trees

From Direct DOM Manipulation → Virtual DOM

Step 2: The Rise of State Empires

The Verbose Era — Classic Redux for one API call

The Upgrade — Redux Toolkit & RTK Query

The Pivot — React Query (Server State, not App State)

Why the shift happened

Rule of thumb

Step 3: The Return of the Server

React 16: modern SSR shows up

React 18: Suspense + streaming

Why React Server Components (RSCs)?

Step 4: Boundaries Are the New Abstractions

Step 5: The Rise of Islands

Islands: a name for what we were feeling

Islands architecture

Step 6: The Big Lesson

The Barrel Trap: How I Learned to Stop Re‑Exporting and Love Explicit Imports

Step 0: Just Export Everything

Step 1: Find a Repro

Step 2: Narrow the Repro

Step 4: Find the Root Cause

Step 5: Build a Better Export Map

Step 6: Try It Yourself (Vite Edition)

Step 7: The Bigger Lesson

React Fundamentals part 3: JSX

JSX rewrites your JavaScript files

Why use JSX?

References and articles:

React Fundamentals part 2: Basic view on React core API's

React.createElement()

Children's children

ReactDOM.render()

References and articles:

🏁 What's a design system anyway ? ?

What is a Design System?

Contents of a Design System

What is Atomic Design?

What Is A Style Guide?

What Is A Component Library?

What Is A Pattern Library?

How to Approach Design-System Adoption

Why Use a Design System?

Why Not Use a Design System?

Conclusion

React Fundamentals part 1 : The Basic javascript "Hello world"

Minimal web page

DOM Manipulation

References and articles:

🏁 Build tool choice for MVP projects

Quick guide;

Installation

Conditional React props with TypeScript

Conflicting properties

Conditional prop variation

Conditional props for collection with generic type

Conditional types for collection property

Here’s a link to the code sandbox for this tutorial.