String to Number Conversions

The Unary Plus Operator (+)

The fastest and most concise way to convert a string to a number:

+"42"           // 42
+"3.14"         // 3.14
+"-10"          // -10
+"0xFF"         // 255 (hex notation works!)

Watch out for edge cases:

+"123abc"       // NaN
+""             // 0 (empty string becomes 0)
+" "            // 0 (whitespace becomes 0)

The Double Bitwise NOT (~~)

Great for converting to integers, as it truncates decimals:

~~"42"          // 42
~~"3.14"        // 3 (truncates decimal)
~~"-10"         // -10

Important difference:

+"123abc"       // NaN
~~"123abc"      // 0 (returns 0 instead of NaN)

Number() Constructor

More explicit and readable:

Number("42")         // 42
Number("3.14")       // 3.14
Number("")           // 0
Number("abc")        // NaN

parseInt() and parseFloat()

The classic methods, especially useful for strings with mixed content:

parseInt("42")       // 42
parseInt("42px")     // 42 (stops at first non-digit)
parseInt("3.14")     // 3 (always returns integer)
parseFloat("3.14")   // 3.14
parseFloat("3.14px") // 3.14

Pro tip: Always specify the radix with parseInt:

parseInt("10", 10)   // 10 (decimal)
parseInt("10", 2)    // 2 (binary)
parseInt("FF", 16)   // 255 (hexadecimal)

Arithmetic Tricks

Multiplication and subtraction force type conversion:

"42" * 1             // 42
"3.14" * 1           // 3.14
"42" - 0             // 42
"100" - 20           // 80

Number to String Conversions

String Concatenation

The simplest approach:

42 + ""              // "42"
3.14 + ""            // "3.14"
(1 + 2) + ""         // "3"

Template Literals

Modern and readable:

`${42}`              // "42"
`${3.14}`            // "3.14"
`Value: ${100}`      // "Value: 100"

String() Constructor

Explicit conversion:

String(42)           // "42"
String(3.14)         // "3.14"
String(null)         // "null"
String(undefined)    // "undefined"

toString() Method

Offers base conversion options:

(42).toString()      // "42"
(255).toString(16)   // "ff" (hexadecimal)
(8).toString(2)      // "1000" (binary)
(255).toString(8)    // "377" (octal)

Formatting Methods

For precise decimal control:

(3.14159).toFixed(2)     // "3.14"
(42).toFixed(2)          // "42.00"
(1234).toExponential()   // "1.234e+3"
(123.456).toPrecision(4) // "123.5"

Boolean Conversions

To Boolean: The Double NOT (!!)

The standard way to convert any value to boolean:

!!"hello"            // true
!!1                  // true
!!0                  // false
!!""                 // false
!!null               // false
!!undefined          // false

Important: Arrays and objects are always truthy:

!![]                 // true (empty array is truthy!)
!!{}                 // true (empty object is truthy!)
!!" "                // true (non-empty string)

Boolean() Constructor

More explicit alternative:

Boolean("hello")     // true
Boolean(0)           // false
Boolean([])          // true

From Boolean to Other Types

Converting booleans to numbers:

true + 0             // 1
false + 0            // 0
+true                // 1
+false               // 0
Number(true)         // 1
Number(false)        // 0

Converting booleans to strings:

true + ""            // "true"
false + ""           // "false"
String(true)         // "true"
`${false}`           // "false"

Array and String Conversions

Array to String

Using join():

[1, 2, 3].join()         // "1,2,3"
[1, 2, 3].join("")       // "123"
[1, 2, 3].join("-")      // "1-2-3"
["a", "b", "c"].join(" ")// "a b c"

Quick conversion:

[1, 2, 3].toString()     // "1,2,3"
[1, 2, 3] + ""           // "1,2,3"
`${[1, 2, 3]}`           // "1,2,3"

String to Array

Multiple approaches:

// Split method
"hello".split("")            // ['h', 'e', 'l', 'l', 'o']
"a,b,c".split(",")           // ['a', 'b', 'c']
"one two three".split(" ")   // ['one', 'two', 'three']

// Spread operator (ES6+)
[..."hello"]                 // ['h', 'e', 'l', 'l', 'o']
[..."abc"]                   // ['a', 'b', 'c']

// Array.from()
Array.from("hello")          // ['h', 'e', 'l', 'l', 'o']

Object Conversions

Object to Array

const obj = {a: 1, b: 2, c: 3};

Object.keys(obj)             // ['a', 'b', 'c']
Object.values(obj)           // [1, 2, 3]
Object.entries(obj)          // [['a', 1], ['b', 2], ['c', 3]]

Array to Object

// From entries
Object.fromEntries([['a', 1], ['b', 2]])
// Result: {a: 1, b: 2}

// Using reduce
['a', 'b', 'c'].reduce((acc, val, i) => ({...acc, [val]: i}), {})
// Result: {a: 0, b: 1, c: 2}

// From keys with default value
Object.fromEntries(['a', 'b', 'c'].map(k => [k, 0]))
// Result: {a: 0, b: 0, c: 0}

JSON Conversions

const obj = {name: "Alice", age: 25};

// Object to JSON string
JSON.stringify(obj)
// '{"name":"Alice","age":25}'

JSON.stringify(obj, null, 2)
// Formatted with 2-space indentation

// JSON string to Object
JSON.parse('{"name":"Alice","age":25}')
// {name: 'Alice', age: 25}

Special Cases and Gotchas

Null and Undefined Handling

Default values with nullish coalescing:

null ?? "default"        // "default"
undefined ?? "default"   // "default"
0 ?? "default"           // 0 (not null/undefined)
"" ?? "default"          // "" (not null/undefined)

Default values with logical OR:

null || "default"        // "default"
0 || "default"           // "default" (0 is falsy)
"" || "default"          // "default" (empty string is falsy)
false || "default"       // "default"

Weird Coercions You Should Know

These might surprise you:

[] + []                  // "" (empty string!)
[] + {}                  // "[object Object]"
{} + []                  // 0 (in some contexts)
[] == false              // true
"0" == 0                 // true (loose equality coerces)
"0" === 0                // false (strict equality doesn't)
null == undefined        // true
null === undefined       // false

Math Operations

Addition vs other operators:

"5" + 3                  // "53" (concatenation)
"5" - 3                  // 2 (conversion)
"5" * "2"                // 10 (both convert)
"10" / "2"               // 5 (both convert)

Date Conversions

const date = new Date("2024-01-15");

// Date to timestamp
+date                    // 1705276800000
date.getTime()           // 1705276800000

// Date to string
date.toISOString()       // "2024-01-15T00:00:00.000Z"
date.toLocaleDateString()// "1/15/2024"

// Timestamp to date
new Date(1705276800000)  // Mon Jan 15 2024

Number Base Conversions

// Decimal to other bases
(255).toString(16)       // "ff" (hex)
(255).toString(2)        // "11111111" (binary)
(255).toString(8)        // "377" (octal)

// Other bases to decimal
parseInt("ff", 16)       // 255
parseInt("11111111", 2)  // 255
parseInt("377", 8)       // 255

// Formatting
(255).toString(16).toUpperCase()  // "FF"
(10).toString(2).padStart(8, "0") // "00001010"

Best Practices

1. Be Explicit When It Matters

For production code, explicit conversions are often clearer:

// Good
Number(userInput)
String(value)
Boolean(condition)

// Clever but less clear
+userInput
value + ""
!!condition

2. Use Strict Equality

Always use === instead of == to avoid unexpected coercion:

// Avoid
if (value == 0) { }      // Could match "", [], false

// Prefer
if (value === 0) { }     // Only matches 0

3. Handle NaN Properly

// Wrong way
value === NaN            // Always false (NaN !== NaN)

// Right way
Number.isNaN(value)      // true only for NaN
isNaN(value)             // true if value converts to NaN

4. Validate Before Converting

// Safe conversion function
const toNumber = (str) => {
  const num = +str;
  return isNaN(num) ? 0 : num;
};

toNumber("42")           // 42
toNumber("abc")          // 0 (safe fallback)

5. Choose the Right Method

For integers from strings: Use parseInt() with radix

parseInt("42", 10)       // Always specify base

For floats from strings: Use parseFloat() or Number()

parseFloat("3.14")
Number("3.14")

For formatting numbers: Use toFixed(), toPrecision()

(3.14159).toFixed(2)     // "3.14"

For boolean checks: Use Boolean() or !!

if (Boolean(value)) { }
if (!!value) { }

Practical Examples

CSV String to Number Array

"1,2,3,4,5".split(",").map(Number)
// [1, 2, 3, 4, 5]

RGB to Hex Color

const rgbToHex = (r, g, b) => 
  "#" + [r, g, b].map(x => x.toString(16).padStart(2, "0")).join("");

rgbToHex(255, 0, 128)    // "#ff0080"

Hex to RGB Color

const hexToRgb = hex => 
  hex.match(/[A-Fa-f0-9]{2}/g).map(x => parseInt(x, 16));

hexToRgb("#ff0080")      // [255, 0, 128]

Query Parameters to Object

const params = "?name=Alice&age=25";
Object.fromEntries(new URLSearchParams(params))
// {name: 'Alice', age: '25'}

Safe Integer Conversion

const toInt = (value, defaultValue = 0) => {
  const num = parseInt(value, 10);
  return isNaN(num) ? defaultValue : num;
};

toInt("42")              // 42
toInt("abc")             // 0
toInt("abc", -1)         // -1

Conclusion

JavaScript's type conversion system is flexible and powerful, but it requires understanding to use effectively. Remember these key points:

• Use explicit conversions (Number(), String(), Boolean()) for clarity

• Be aware of falsy values: false, 0, "", null, undefined, NaN

• Empty arrays and objects are truthy

• Use === instead of == to avoid unexpected coercion

• Validate and handle edge cases like NaN, null, and undefined

• Choose the right method for the job: parseInt() for integers, parseFloat() for decimals

• Test your conversions thoroughly, especially with user input

Master these conversions, and you'll write more robust, predictable JavaScript code!

What React Query Really Is

React Query is data-fetching agnostic. It's purely a caching and state management library that doesn't care how you fetch your data. Whether you use fetch(), axios, XMLHttpRequest, or even a custom GraphQL client, React Query treats them all the same.

Think of React Query as a sophisticated data orchestrator. You're responsible for choosing a data fetcher, then React Query handles storing it, synchronizing it across components, and only refetching after the specified stale time.

Understanding the Architecture

React Query's architecture separates concerns beautifully:

Your Responsibility (The Data Fetcher):

• Choose your HTTP client (fetch, axios, etc.)

• Define API endpoints and request structure

• Handle request formatting (REST, GraphQL, etc.)

• Configure authentication and headers

React Query's Responsibility (The Cache Manager):

• Store fetched data in memory

• Track cache freshness and staleness

• Coordinate when to refetch

• Manage loading and error states across your app

This separation means you have complete flexibility in how you retrieve data, while React Query handles the complex orchestration of keeping that data fresh and accessible.

You Can Use ANY Fetching Method

Here's the beauty of React Query's agnostic approach—all of these work equally well:

// Option 1: Native fetch()
const { data } = useQuery({
  queryKey: ['user', userId],
  queryFn: () => fetch(`/api/users/${userId}`).then(res => res.json())
});

// Option 2: Axios
const { data } = useQuery({
  queryKey: ['user', userId],
  queryFn: () => axios.get(`/api/users/${userId}`).then(res => res.data)
});

// Option 3: GraphQL client
const { data } = useQuery({
  queryKey: ['user', userId],
  queryFn: () => graphqlClient.request(GET_USER_QUERY, { userId })
});

// Option 4: Your custom API wrapper
const { data } = useQuery({
  queryKey: ['user', userId],
  queryFn: () => myCustomApi.users.getById(userId)
});

Notice the pattern? React Query only cares that your queryFn returns a Promise. Everything else is up to you.

What React Query DOES Handle

React Query excels at server state management and data synchronization:

✅ Caches results - Stores data in memory with configurable cache times, eliminating redundant requests

✅ Manages loading/error states - Provides isLoading, isError, error, isFetching without manual useState calls

✅ Handles refetching/invalidation - Automatically refetches stale data and invalidates caches when mutations occur

✅ Prevents duplicate requests - Deduplicates simultaneous requests for the same data across your entire app

✅ Background updates - Refetches data in the background when windows refocus, or network reconnects

✅ Pagination/infinite scroll helpers - Built-in utilities for complex data loading patterns

✅ Optimistic updates - Update UI immediately before the server confirms changes

✅ Global state synchronization - Automatically updates all components using the same query when data changes

✅ Request retry logic - Configurable retry attempts for failed requests

✅ Garbage collection - Removes unused cache entries to prevent memory leaks

What React Query DOESN'T Do

Understanding the boundaries is just as important:

❌ Make HTTP requests - You provide the fetching function

❌ Know about REST/GraphQL - It's protocol-agnostic

❌ Handle network layer - No built-in retry logic, interceptors, or request transformation (though you can add these yourself)

Our Real-World Implementation

In our production codebase, we chose the native fetch() API to make GraphQL requests. React Query manages the entire data lifecycle:

const useProject = (projectId) => {
  return useQuery({
    queryKey: ['project', projectId],
    queryFn: async () => {
      const response = await fetch('/graphql', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          query: `
            query GetProject($id: ID!) {
              project(id: $id) {
                id
                name
                description
                updatedAt
              }
            }
          `,
          variables: { id: projectId }
        })
      });

      const { data, errors } = await response.json();
      if (errors) throw new Error(errors[0].message);
      return data.project;
    },
    staleTime: 5 * 60 * 000, // React Query manages staleness
    cacheTime: 10 * 60 * 1000, // React Query manages cache
  });
};

We handle the GraphQL request formatting and network call. React Query handles caching that response, tracking when it becomes stale, managing loading states across components, and automatically refetching when needed.

Understanding staleTime vs cacheTime (gcTime)

Two of React Query's most important but confusing configurations are staleTime and cacheTime (renamed to gcTime in v5). They control different aspects of the data lifecycle:

staleTime - When data becomes "stale"

This determines how long data is considered "fresh." Fresh data won't trigger a refetch.

useQuery({
  queryKey: ['user', userId],
  queryFn: fetchUser,
  staleTime: 5 * 60 * 1000, // 5 minutes
});

• Default: 0 (immediately stale)

• When staleTime expires, data becomes "stale" but remains in cache

• Stale data triggers background refetches on window focus, component mount, or manual refetch

• Fresh data (within staleTime) won't refetch even if you revisit the component

cacheTime/gcTime - When cache gets garbage collected

This determines how long unused data stays in memory after all components are unmounted.

useQuery({
  queryKey: ['user', userId],
  queryFn: fetchUser,
  staleTime: 5 * 60 * 1000,     // Fresh for 5 minutes
  cacheTime: 10 * 60 * 1000,    // Cached for 10 minutes (v4)
  // gcTime: 10 * 60 * 1000,    // In v5, use gcTime instead
});

• Default: 5 minutes

• Starts counting down when the last component using this query unmounts

• When gcTime expires, data is removed from memory completely

• Next fetch will be a fresh request, not served from cache

How They Work Together:

Time:     0s -------- 5min -------- 10min -------- 15min
          |           |             |              |
Mount --> [--FRESH---][---STALE----]              |
          |           |             |              |
Unmount -------->     |             |              |
                      |  [--CACHED--][--DELETED--]

Real-world example:

// User profile - changes infrequently
useQuery({
  queryKey: ['profile'],
  queryFn: fetchProfile,
  staleTime: 10 * 60 * 1000,  // Don't refetch for 10 minutes
  gcTime: 30 * 60 * 1000,     // Keep in cache for 30 minutes
});

// Real-time stock prices - always fresh
useQuery({
  queryKey: ['stock', symbol],
  queryFn: fetchStock,
  staleTime: 0,               // Always stale, always refetch
  gcTime: 1 * 60 * 1000,      // Clear from cache after 1 minute
});

// Static reference data - rarely changes
useQuery({
  queryKey: ['countries'],
  queryFn: fetch

The Bottom Line

React Query isn't a data-fetching library—it's a server state management and synchronization library. This distinction matters because it means you maintain full control over your data layer while delegating the complex state orchestration to a battle-tested solution.

Why "State Management" Matters

Traditional state management libraries like Redux or Zustand are designed for client state—data that lives entirely in your application (UI state, form inputs, user preferences). Server state is fundamentally different:

Server State Characteristics:

• Asynchronously fetched from remote sources

• Can become outdated or "stale"

• Shared across multiple components and users

• Requires loading and error states

• Needs periodic refreshing

• Benefits of caching to reduce network requests

React Query specializes in server state. It solves problems that client state managers weren't designed for:

// Without React Query - manual state management
const [data, setData] = useState(null);
const [isLoading, setIsLoading] = useState(false);
const [error, setError] = useState(null);
const [lastFetch, setLastFetch] = useState(null);

useEffect(() => {
  const fetchData = async () => {
    setIsLoading(true);
    try {
      const result = await fetch('/api/data');
      setData(await result.json());
      setLastFetch(Date.now());
    } catch (err) {
      setError(err);
    } finally {
      setIsLoading(false);
    }
  };

  // Need to track staleness manually
  const isStale = !lastFetch || Date.now() - lastFetch > 60000;
  if (isStale) fetchData();
}, [lastFetch]);

// With React Query - automatic server state management
const { data, isLoading, error } = useQuery({
  queryKey: ['data'],
  queryFn: () => fetch('/api/data').then(res => res.json()),
  staleTime: 60000
});

React Query automatically handles what you'd need dozens of lines to manage manually: caching, staleness tracking, background refetching, request deduplication, and state synchronization across components.

Using React Query as Global State Management

One of React Query's most powerful features is automatic global state synchronization. When you fetch data with the same queryKey in multiple components, they all share the same cached data and update together:

// UserProfile.jsx
function UserProfile() {
  const { data: user } = useQuery({
    queryKey: ['user', 'current'],
    queryFn: fetchCurrentUser,
  });

  return <div>{user.name}</div>;
}

// UserAvatar.jsx (different component, same data!)
function UserAvatar() {
  const { data: user } = useQuery({
    queryKey: ['user', 'current'],
    queryFn: fetchCurrentUser,
  });

  return <img src={user.avatar} />;
}

// Settings.jsx (updates everywhere automatically)
function Settings() {
  const queryClient = useQueryClient();

  const mutation = useMutation({
    mutationFn: updateUserName,
    onSuccess: (updatedUser) => {
      // This updates BOTH UserProfile and UserAvatar instantly
      queryClient.setQueryData(['user', 'current'], updatedUser);
    }
  });

  return <button onClick={() => mutation.mutate({ name: 'New Name' })}>
    Update Name
  </button>;
}

What just happened?

1. Multiple components use the same queryKey: ['user', 'current']

2. React Query fetches once and shares the result

3. When we update the cache with setQueryData, all components re-render with new data

4. No props drilling, no context providers, no manual subscriptions

This replaces traditional global state patterns:

// Traditional approach - lots of boilerplate
const UserContext = createContext();

function UserProvider({ children }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(false);

  useEffect(() => {
    fetchUser().then(setUser);
  }, []);

  return (
    <UserContext.Provider value={{ user, setUser, loading }}>
      {children}
    </UserContext.Provider>
  );
}

// React Query approach - automatic
// Just use the same queryKey wherever you need the data!

The queryKey acts as a global identifier. Any component using that key gets the same data, loading states, and updates—automatically.

If you're like me, coming from the Redux world, you'll soon find yourself missing the Redux DevTools. Being able to see your entire store at any moment, with time-travel debugging and a clear action log, is incredibly powerful. But as I learned more about MST, I started to appreciate its different approach.

MST feels lighter than Redux—no boilerplate for actions and reducers, and stores are scoped to specific data types rather than one giant global store. Compared to plain MobX, MST's structured model definitions are more elegant, with built-in type checking and snapshot-based time travel.

The trade-off? Debugging requires a different mindset. I tried several browser extensions, but they're either deprecated or don't work well with MST. There's no magic DevTools button. Instead, you'll need to instrument your code with MST's built-in debugging tools.

The good news? Once you learn these patterns, MST debugging becomes just as powerful—and in some ways, more flexible—than Redux DevTools.

1. The Three Built-in Debugging Tools

MST provides three powerful listeners that form the foundation of debugging:

onAction - Track What Happened

import { onAction } from 'mobx-state-tree';

onAction(rootStore, call => {
  console.log('Action called:', {
    name: call.name,      // toggleTodo
    path: call.path,      // /todos/0
    args: call.args       // []
  });
});

This tells you what action was called, where it was called, and what arguments were passed.

onPatch - Track What Changed

import { onPatch } from 'mobx-state-tree';

onPatch(rootStore, patch => {
  console.log('State changed:', {
    op: patch.op,         // "replace", "add", or "remove"
    path: patch.path,     // "/todos/0/completed"
    value: patch.value    // true
  });
});

This shows you the exact property that changed and its new value. This is usually the most useful for debugging.

onSnapshot - Track Full State

import { onSnapshot } from 'mobx-state-tree';

onSnapshot(rootStore, snapshot => {
  console.log('Current state:', snapshot);
});

This gives you the entire state tree after each change. Use sparingly as it can be verbose.

2. Setting Up a Debugging Environment

Here's a practical setup for development:

// store/debugger.js
import { onAction, onPatch } from 'mobx-state-tree';

export function setupDebugger(store) {
  if (process.env.NODE_ENV !== 'development') return;

  // Track actions with grouping for readability
  onAction(store, call => {
    console.group(`🎬 ${call.name}`);
    console.log('Path:', call.path);
    console.log('Args:', call.args);
    console.groupEnd();
  });

  // Track patches with colored output
  onPatch(store, patch => {
    const emoji = {
      replace: '✏️',
      add: '➕',
      remove: '➖'
    }[patch.op];

    console.log(`${emoji} ${patch.path}`, patch.value);
  });

  // Make store accessible in console
  window.store = store;
  console.log('💡 Store available as window.store');
}

// store/index.js
import { setupDebugger } from './debugger';

export function createRootStore() {
  const store = RootStore.create({ /* ... */ });
  setupDebugger(store);
  return store;
}

Now every action and state change is logged automatically!

3. Debugging Component Re-renders

One common issue: "Why is my component re-rendering?"

Use React DevTools Profiler

First, use React DevTools to see what is re-rendering:

1. Install React DevTools extension

2. Open DevTools → Profiler tab

3. Click record → interact with app → stop

4. See which components rendered and why

Add trace() to See Observables

Use MobX's trace() to see what observables a component is tracking:

import { observer } from 'mobx-react-lite';
import { trace } from 'mobx';

const TodoList = observer(() => {
  const { todoStore } = useStores();

  // Add this temporarily
  trace();

  return (
    <ul>
      {todoStore.todos.map(todo => (
        <TodoItem key={todo.id} todo={todo} />
      ))}
    </ul>
  );
});

When this component re-renders, you'll see in the console which observable triggered it.

Common Re-render Issues

Problem 1: Missing observer wrapper

// ❌ Won't update when todo changes
const TodoItem = ({ todo }) => {
  return <div>{todo.title}</div>;
};

// ✅ Will update
const TodoItem = observer(({ todo }) => {
  return <div>{todo.title}</div>;
});

Problem 2: Over-observing

// ❌ Re-renders when ANY todo changes
const TodoList = observer(() => {
  const { todoStore } = useStores();

  return (
    <div>
      Completed: {todoStore.todos.filter(t => t.completed).length}
    </div>
  );
});

// ✅ Only re-renders when completed count changes
const TodoStore = types.model({
  todos: types.array(Todo),
}).views(self => ({
  get completedCount() {
    return self.todos.filter(t => t.completed).length;
  }
}));

const TodoList = observer(() => {
  const { todoStore } = useStores();
  return <div>Completed: {todoStore.completedCount}</div>;
});

Move calculations to computed values (views) in your store!

4. Time Travel Debugging

One of MST's superpowers is snapshots. Here's how to implement undo/redo:

import { applySnapshot, getSnapshot } from 'mobx-state-tree';

class TimeTravel {
  constructor(store) {
    this.store = store;
    this.history = [getSnapshot(store)];
    this.currentIndex = 0;

    onSnapshot(store, snapshot => {
      // Remove any "future" states if we went back
      this.history.splice(this.currentIndex + 1);
      this.history.push(snapshot);
      this.currentIndex = this.history.length - 1;
    });
  }

  undo() {
    if (this.currentIndex > 0) {
      this.currentIndex--;
      applySnapshot(this.store, this.history[this.currentIndex]);
      console.log('⏪ Undo');
    }
  }

  redo() {
    if (this.currentIndex < this.history.length - 1) {
      this.currentIndex++;
      applySnapshot(this.store, this.history[this.currentIndex]);
      console.log('⏩ Redo');
    }
  }
}

// Usage
const timeTravel = new TimeTravel(rootStore);
window.undo = () => timeTravel.undo();
window.redo = () => timeTravel.redo();

Now you can type undo() or redo() in the console to step through state changes!

5. Debugging Async Actions

Async actions can be particularly tricky. Here's how to add proper logging:

const TodoStore = types.model({
  todos: types.array(Todo),
  isLoading: false,
  error: null,
}).actions(self => ({
  async fetchTodos() {
    console.log('📡 Fetching todos...');
    self.isLoading = true;
    self.error = null;

    try {
      const response = await fetch('/api/todos');
      const data = await response.json();

      console.log('✅ Fetched:', data.length, 'todos');
      self.todos = data;
    } catch (err) {
      console.error('❌ Fetch failed:', err);
      self.error = err.message;
    } finally {
      self.isLoading = false;
      console.log('📡 Fetch complete');
    }
  }
}));

Use try-catch blocks and log at each stage to see where things break.

6. Production Debugging

You can't use console.log in production, but you can store logs:

class MSTLogger {
  constructor(store, maxLogs = 100) {
    this.logs = [];

    onAction(store, call => {
      this.addLog({
        type: 'action',
        name: call.name,
        path: call.path,
        args: call.args,
        timestamp: Date.now()
      });
    });

    onPatch(store, patch => {
      this.addLog({
        type: 'patch',
        op: patch.op,
        path: patch.path,
        value: patch.value,
        timestamp: Date.now()
      });
    });
  }

  addLog(log) {
    this.logs.push(log);
    if (this.logs.length > 100) {
      this.logs.shift(); // Keep last 100
    }
  }

  export() {
    return JSON.stringify(this.logs, null, 2);
  }

  sendToErrorTracking() {
    // Send to Sentry, LogRocket, etc.
    if (window.Sentry) {
      window.Sentry.captureMessage('MST Logs', {
        extra: { logs: this.logs }
      });
    }
  }
}

// Usage
const logger = new MSTLogger(rootStore);
window.exportLogs = () => logger.export();

When a user reports a bug, ask them to run exportLogs() in the console and send you the output!

7. MST DevTools

For the best debugging experience, use the MST Inspector:

npm install --save-dev mobx-state-tree-inspector

import { makeInspectable } from 'mobx-state-tree-inspector';

if (process.env.NODE_ENV === 'development') {
  makeInspectable(rootStore);
}

This adds a visual tree inspector to Chrome DevTools showing your entire state tree and all changes in real-time.

8. Common Debugging Scenarios

"My component isn't updating"

Checklist:

1. Is the component wrapped with observer?

2. Is it reading from an MST observable?

3. Is the data actually changing? (Add a patch listener)

// Add this temporarily
onPatch(rootStore.todos, patch => {
  console.log('Todo changed:', patch);
});

"Too many re-renders"

Checklist:

1. Are you creating new objects/functions in render?

2. Are you observing too much?

3. Move calculations to computed values

// ❌ Bad - creates new function every render
<button onClick={() => store.addTodo(text)}>Add</button>

// ✅ Good - stable reference
const handleAdd = () => store.addTodo(text);
<button onClick={handleAdd}>Add</button>

"State is wrong after API call"

Debug:

1. Log the API response

2. Check the action that processes it

3. Verify the model types match the data

async fetchTodos() {
  const response = await fetch('/api/todos');
  const data = await response.json();

  console.log('API returned:', data);
  console.log('Current todos:', getSnapshot(self.todos));

  self.todos = data;

  console.log('New todos:', getSnapshot(self.todos));
}

Note: It’s recommended to use MST’s flow for async calls to keep the transaction atomic.

import { types, flow } from "mobx-state-tree";

const UserStore = types
  .model("UserStore", {
    users: types.array(types.frozen()),
    // Track the lifecycle of the request
    status: types.optional(
      types.enumeration(["idle", "pending", "done", "error"]), 
      "idle"
    )
  })
  .actions((self) => ({
    // Use a generator function (note the *)
    fetchUsers: flow(function* () {
      self.status = "pending";
      try {
        // Use yield instead of await
        const response = yield fetch("https://api.example.com/users");
        const data = yield response.json();

        // MST automatically wraps this update in an action context
        self.users = data;
        self.status = "done";
      } catch (error) {
        console.error("Failed to fetch users:", error);
        self.status = "error";
      }
    })
  }));

9. Best Practices

1. Use TypeScript - Catch type errors before runtime

2. Keep stores small - Easier to reason about and debug

3. Use computed values in view - They're cached and easier to track

4. Name your actions - Clear names make logs more useful

5. One action per user interaction - Makes debugging straightforward

10. Quick Debug Snippet

Add this to your store for instant debugging:

.views(self => ({
  get debug() {
    return {
      snapshot: getSnapshot(self),
      // Add any useful computed data
      todoCount: self.todos.length,
      completedCount: self.todos.filter(t => t.completed).length,
    };
  }
}));

// In console
console.table(rootStore.debug);

Conclusion

Debugging MST apps is different from Redux, but once you know the tools, it's actually quite powerful. The key insights:

• Use onPatch to see what changed

• Use onAction to see what caused it

• Use trace() to debug component re-renders

• Use snapshots for time travel

• Set up logging in development mode

• Use flow() for async calls

With these tools in your belt, you'll spend less time debugging and more time building features. Happy debugging!

Resources:

• MST Documentation

• MobX DevTools

• MST Inspector

• MST Asynchronous Actions

What It Is

SolidJS is a declarative JavaScript library for creating web applications with a focus on performance and fine-grained reactivity. Its development began in 2016 by Ryan Carniato, with the first commit to the SolidJS repository occurring on August 21, 2016. The framework's official 1.0 release was in June 2021. It has gained significant popularity in recent years.

Key Features

• Fine-grained reactivity: SolidJS uses a reactive system that updates only the specific parts of the DOM that need to change, making it extremely fast.

• No Virtual DOM: SolidJS compiles your code to real DOM operations, which contributes to its excellent performance.

• Familiar syntax: If you know React, SolidJS will look very familiar. It uses JSX and has a component-based architecture with similar patterns to useState (called createSignal in Solid).

• Small bundle size: The framework itself is lightweight, typically resulting in smaller production bundles.

• True reactivity: State updates automatically propagate through your application without needing to worry about dependency arrays or optimization techniques.

How Does It Work

SolidJS's reactivity has three main components working together:

1. Signals - Hold reactive values and track their subscribers

2. Effects - Functions that auto-run when their dependencies change

3. Direct DOM references - Stored in closures, accessed by effects

Phase 1: Set up signals and bind to DOM notes

Phase 2: Trigger updates in signal and notify subscribers (DOM nodes)

The brilliance of SolidJS:

• Signals track which effects depend on them (the dependency graph)

• Effects hold direct references to DOM nodes (the O(1) access)

• When a signal changes, it notifies its effects, which update their DOM nodes directly

SolidJS vs. ReactJS

React uses the Virtual DOM to make DOM updates easier and more predictable for developers, not necessarily for raw performance. The Virtual DOM is actually an abstraction layer that adds overhead - it requires:

1. Creating a virtual representation of the UI in memory

2. Comparing (diffing) the old and new virtual trees

3. Then updating the real DOM

SolidJS can be more performant with its fine-grained reactivity and compile-time optimizations:

1. Direct DOM updates: When you write SolidJS code, the compiler analyzes your components at build time and generates code that updates specific DOM nodes directly when state changes—no diffing needed.

2. Surgical precision: Instead of re-running component functions and comparing trees, SolidJS creates reactive "subscriptions" that know exactly which DOM nodes depend on which pieces of state. When state changes, only those exact nodes update.

3. One-time setup: The component function runs only once during creation. After that, only the reactive values update, triggering their specific DOM updates.

RSCs run exclusively on the server, generate HTML output, and the component code is not sent to the browser. Unlike the traditional Client Components that render in the browser, RSCs execute on the server. RSCs can directly access server-side resources, such as databases or file systems, without requiring a separate API layer. On the flip side, they can’t access browser APIs or hooks, which should be done in the Client Components.

Server Components vs. Client Components

Starting from React 19, to define a Client Component requires adding 'use client' at the top of the file.

If the component needs any of the items listed below, it must be a Client Component.

• React hooks (useState, useEffect, etc.)

• Browser APIs (window, document)

• Event handlers (onClick, onChange)

• Third-party libraries that use browser-only features

The default for a component, without either of these directives, is a Server Component.

Read more on When to use Server and Client Components?.

Server Functions

The corresponding directive ‘user server‘ is not meant to be the signature of RSCs but rather that of Server Functions, also known as Server Actions. They can be created in Server Components and passed as props to Client Components, or imported into Client Components.

Leaves vs. Root Strategy

One of the best practices for improving web application performance is reducing the size of the JS bundle. RSCs reduce JS bundle size by:

• Running only on the server

• Not being included in the client-side JavaScript bundle at all

• Returning just HTML to the browser

JS bundle for RSCs vs. CSCs:

• Server Components = Code executes on server → HTML sent to browser → No JS bundle cost

• Client Components = Code sent to browser → Executes in browser → Full JS bundle cost

You may wonder about the impact of the HTML output, and in some cases, it might even be larger than the equivalent JavaScript. But there are important differences in how they affect performance:

1. Parse/Execute Cost

• HTML: Browser parses and renders it very efficiently - it's what browsers are optimized for

• JavaScript: Must be parsed, compiled, and executed before anything happens. This is CPU-intensive and blocks interactivity

2. When User Can Interact

• HTML: Visible and readable immediately (for non-interactive content)

• JS bundle: User waits for download → parse → execute → hydration before page is interactive

3. Main Thread Blocking

• HTML: Doesn't block the main thread

• JavaScript: Large bundles block the main thread, making the page feel sluggish

With the understanding of RSCs vs. CSCs, let’s consider these two approaches for a standard ui with a search bar:

❌ Root approach (bad):

• Put 'use client' at the Layout level (the root)

• All components imported into a Client Component become a Client Component

• The entire tree ships to the browser as JavaScript

✓ Leaves approach (good):

• Keep Layout, Header, and Sidebar as Server Components

• Only add 'use client' to Search and Navigation (the leaves)

• Only those small pieces ship as JavaScript

In a tree, leaves are at the edges/endpoints. In your component tree, you want to push 'use client' as far out to the edges as possible - to the smallest, most specific components that actually need client-side interactivity.

The closer to the root you place 'use client', the more of your tree becomes client-side code. The closer to the leaves, the less JavaScript you ship.

Composition Pattern vs. Rendering

The most common usecase for context is to set the theme. When you use a Context Provider, you must mark it as a Client Component:

// providers.js
'use client'  // ← Required!

import { createContext } from 'react';

export const ThemeContext = createContext();

export function ThemeProvider({ children }) {
  return (
    <ThemeContext.Provider value="dark">
      {children}
    </ThemeContext.Provider>
  );
}

Even though ThemeProvider is a Client Component, its children can still be Server Components. The Client Component boundary doesn't force everything inside it to become a Client Component—only the provider itself needs to be client-side.

// app/layout.js (Server Component by default)
import { ThemeProvider } from './providers';

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        <ThemeProvider>  {/* Client Component */}
          {children}      {/* Can still be Server Components! */}
        </ThemeProvider>
      </body>
    </html>
  );
}

Children become Client Components only if you import and render them directly inside a Client Component:

// ClientWrapper.js
'use client'

import ServerChild from './ServerChild';  // ← This import makes it client!

export default function ClientWrapper() {
  return (
    <div>
      <ServerChild />  {/* Now it's a Client Component */}
    </div>
  );
}

Strategy to Minimize Bundle Size

1. Keep as many components as Server Components as possible

2. Push 'use client' as far down the component tree as you can, or use the composition pattern

3. Split interactive parts into small Client Components nested within Server Components

Of course, there is a reason for everything, and there is always a tradeoff. In some cases, keeping a component as a Client Component will be more performant. For example:

• Virtual scrolling for huge lists

• Interactive dashboards with lots of client-side state

• Apps where data changes frequently

Key Reference Material:

• Build a Fullstack Next.js App, v4 Course Website

• Fullstack Next.js Github Repository

• Wikimasters Project Demo

The Stack

This workshop introduced a curated tech stack optimized for serverless architecture, developer experience, and production reliability:

• Next.js - The React framework with built-in SSR, SSG, and API routes

• TypeScript - Type safety across the entire application

• Neon PostgreSQL - Serverless Postgres with automatic scaling

• Drizzle ORM - Type-safe, SQL-like database queries

• Upstash Redis - Serverless caching for blazing-fast performance

• Vercel - Seamless deployment and hosting

• Resend - Modern transactional email

• GitHub Actions - Automated CI/CD pipeline

Database Layer: Neon (Serverless Postgres) + Drizzle ORM

• Neon:

  Neon's built-in authentication system integrates seamlessly with Neon PostgreSQL databases, providing pre-built tables and middleware for user management. The free tier is incredibly generous because you only pay for actual usage—the database scales up on demand and scales down to zero when idle. Perfect for side projects and MVP development.

• Key benefits:

  • Built-in authentication system with pre-configured tables

  • Database branching for development environments

  • Instant provisioning and automatic backups

  • Seamless Vercel integration

• Drizzle ORM:

  Highly "SQL-ish": Unlike ORMs that abstract SQL away, Drizzle keeps SQL logic exposed and accessible. Writing custom queries feels intuitive rather than fighting against the ORM.

  Deep TypeScript Integration: Drizzle automatically generates accurate types for your entire schema, including Neon's built-in Auth tables. This saves countless hours of manual type definitions and catches errors at compile time.

  Lightweight and Fast: Drizzle has minimal overhead compared to heavier ORMs, resulting in faster query execution and smaller bundle sizes.

  Creating the Database Schema & Migrating:

  1. Define your schema in db/schema.ts.

  2. Generate migrations: npx drizzle-kit generate

  3. Apply migrations: npx drizzle-kit migrate

  4. For instant experimental changes, use: npx drizzle-kit push (applies whatever is in your schema instantly)

Seeding Data:

1. Ensure there's at least one user. (Install tsx for TypeScript-based seeds)

2. Add seed logic to your data script

3. Run tsx src/db/seed.ts to seed your database

Auth Layer: AuthN (Authentication) & AuthZ (Authorization)

• AuthN*:* Confirms user identity; validates who the user is.

• AuthZ*:* Controls what authenticated users can do (resource permissions).

• Setup:

  • Implement backend logic on authz.ts within your db/ folder—allow logged-in users to edit their own articles based on role and permissions.

File Storage for Image Upload with Vercel

1. Link your Next.js app repo to Vercel.

2. Configure a blob storage in Vercel and add the required environment variables in next.config.js.

3. Reference the storage (image URL) in drizzle.config.ts.

4. Use Vercel's upload API for image input in upload.ts.

Caching with Upstash Redis

Redis provides sub-millisecond response times—orders of magnitude faster than database queries. For frequently accessed, infrequently changed data (such as article listings or user profiles), caching dramatically improves the user experience and reduces database load.

Upstash makes Redis serverless with per-request pricing, so you're not paying for idle time.

1. Create your Redis project on Upstash.

2. Add credentials to your .env.

3. Add cache logic to lib/data/articles.ts.

Email Support via Resend

Resend is a developer-friendly email API that makes transactional emails painless:

1. Set up a custom domain (DNS records) on Resend.

2. Configure sender/domain options.

3. Create/send templated emails (e.g., celebration notice).

4. Send a notification when the page view count passes a threshold (e.g., >10 views triggers an email).

CI/CD Pipeline with Vercel & Neon

1. Add Neon integration on Vercel’s dashboard.

2. Add current Vercel deployment URL to Neon (especially for unique/ephemeral URL management).

3. Manage environment variables for staging, production, and preview branches.

4. Separate blob storage by environment for isolation and reliability.

5. Vercel provides built-in analytics and speed insights (free for one project per account):

   • Real-time performance monitoring

   • Bot protection and firewall

   • Core Web Vitals tracking

Github Actions and Testing

Automate your workflow:

• Run lint → typecheck → test:ci (unit tests) → test:e2e:ci → deploy to production.

• Use GitHub secrets for per-env variables; copy carefully from Vercel except Neon (generate that API key on Neon).

• Always isolate test environments—a shared cache or DB may yield false positives/failures.

Best Practices & Key Takeaways

Database & Caching

• Use Redis exclusively for performance optimization, not data persistence—always persist to database periodically.

• Monitor cache hit rates to validate your caching strategy

Testing & CI/CD

• Isolate test environments completely to avoid cross-contamination between staging and production.

• Set up GitHub Actions to run the full test suite in CI before deploying

Deployment & Monitoring

• Automate domain cleanup if deployment URLs rotate frequently

• Use Vercel's analytics to monitor real-world performance and identify bottlenecks

• Enable bot protection to prevent spam

Developer Experience

• Drizzle's TypeScript integration catches errors at compile time, saving debugging time in production

• Neon's database branching allows safe experimentation without affecting production data

• Serverless architecture means you're not paying for idle resources

• Vercel integrates seamlessly with different services with key management

By combining Drizzle’s type-safe ORM, Neon’s flexible Postgres, blazing-fast caching with Upstash Redis, and modern deployment with Vercel, you can ship highly scalable Next.js apps with confidence and speed.

Managing multiple related projects can quickly become overwhelming when scattered across different repositories. NX offers a powerful solution for organizing React applications, shared libraries, and backend services in a single, well-structured monorepo. This guide walks you through setting up a production-ready NX workspace with modern best practices.

Why Choose NX for Your Monorepo?

NX has evolved significantly and now offers compelling advantages for development teams:

1. Intelligent Caching: NX automatically caches task results locally and remotely, dramatically reducing build and test times

2. Smart Builds: Only rebuilds projects affected by your changes, saving significant CI/CD time

3. Dependency Visualization: Interactive dependency graphs help you understand your codebase architecture

4. Modern Tooling: Built-in support for Jest, Vitest, Cypress, Playwright, and Storybook

5. Framework Agnostic: Supports React, Angular, Vue, Node.js, and many other frameworks

6. Code Generation: Powerful generators create consistent, well-structured code across your workspace

7. Nx Cloud Integration: Optional remote caching and distributed task execution for enterprise teams

Getting Started

1. Choose Your Monorepo Strategy

NX offers two approaches for organizing monorepos: Integrated and Package-Based.

Integrated Approach (Recommended for Most Teams):

• All dependencies in root package.json

• Single version policy across the workspace

• Faster setup for new projects

• Easier dependency management

• Better for teams working on interconnected projects

Package-Based Approach:

• More suitable if you need different dependencies and tooling between applications

• Each project can have its own package.json with specific versions

• Better for migrating existing projects

• More flexibility but increased complexity

• Ideal for independent apps with different React versions or tech stacks

2. Create Your NX Workspace

The latest version of NX (v21+) has streamlined workspace creation:

npx create-nx-workspace@latest my-workspace

During setup, you'll be prompted to choose:

• Preset: Select react-monorepo for a React-focused workspace

• Bundler: Choose vite (recommended) or webpack

• Test Runner: Select vitest (modern) or jest

• Nx Cloud: Enable for remote caching (recommended for teams)

For an integrated workspace (default), your structure will look like:

my-workspace/
├── apps/              # Applications live here
├── libs/              # Shared libraries
├── nx.json            # NX configuration
├── package.json       # Single source of truth for dependencies
└── tsconfig.base.json # Path mappings for imports

For a package-based workspace, each app/lib will have its own package.json.

2. Generate a React Application

The @nx/react plugin (formerly @nrwl/react) provides updated generators:

# Install the React plugin (if not already installed)
npm install --save-dev @nx/react

# Generate a React application
npx nx generate @nx/react:application my-app --style=scss --bundler=vite

3. Managing Multiple React Apps with Different Versions

One of the challenges in a monorepo is managing multiple apps that may need different versions of dependencies. Here's how to handle this:

Option 1: Using NPM Aliases (Integrated Approach)

If you need to support different versions of React in the same workspace, you can use NPM aliases:

// Root package.json
{
  "dependencies": {
    "react": "^19.2.0",
    "react-dom": "^19.2.0",
    "react-18": "npm:react@^18.2.0",
    "react-dom-18": "npm:react-dom@^18.2.0"
  }
}

Then configure your legacy app's tsconfig.json to map to the older version:

// apps/legacy-app/tsconfig.json
{
  "compilerOptions": {
    "paths": {
      "react": ["../../node_modules/react-18"],
      "react-dom": ["../../node_modules/react-dom-18"]
    }
  }
}

Option 2: Package-Based Workspace (Recommended for Different Versions)

For scenarios where apps truly need different dependency versions, use a package-based repository which is more suitable for having different dependencies and tooling between applications:

# Create a package-based workspace
npx create-nx-workspace@latest my-workspace --preset=npm

In this setup, each application has its own package.json:

my-workspace/
├── packages/
│   ├── modern-app/
│   │   ├── package.json      # React 19
│   │   └── src/
│   └── legacy-app/
│       ├── package.json      # React 18
│       └── src/
└── package.json              # Root for shared dev dependencies

Modern App (packages/modern-app/package.json):

{
  "name": "@my-workspace/modern-app",
  "version": "1.0.0",
  "dependencies": {
    "react": "^19.2.0",
    "react-dom": "^19.2.0",
    "@my-workspace/shared-ui-v3": "*"
  }
}

Legacy App (packages/legacy-app/package.json):

{
  "name": "@my-workspace/legacy-app",
  "version": "2.5.0",
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "lodash": "^4.17.0",
    "@my-workspace/shared-ui-legacy": "*"
  }
}

Option 3: Per-Project Dependency Overrides (Integrated Approach)

Even with an integrated approach, you can enable project-level dependency overrides. Create a package.json in your specific app:

// apps/legacy-app/package.json
{
  "name": "legacy-app",
  "dependencies": {
    "react": "18.2.0",
    "react-dom": "18.2.0"
  }
}

Then configure your package manager (pnpm example) to use these overrides:

# pnpm-workspace.yaml
packages:
  - 'apps/*'
  - 'libs/*'

Important Considerations:

• If projects use different versions of React, runtime issues can occur when sharing components between projects

• Maintain separate component libraries for each major version

• Use caution when sharing code between apps with different dependency versions

• React 19 introduced major features like Server Components and the Actions API, which may not be compatible with older React versions

3. Create Shared Libraries

Libraries enable code sharing across applications:

# Generate a UI component library
npx nx generate @nx/react:library ui-components --directory=libs/shared --style=scss --bundler=vite

# Generate a utilities library
npx nx generate @nx/react:library utils --directory=libs/shared --bundler=none

Key Options:

• --directory: Organizes libraries into folders

• --style: CSS/SCSS/styled-components/emotion

• --bundler: vite, rollup, or none (for non-buildable libraries)

• --unitTestRunner: vitest, jest, or none

Creating Version-Specific Libraries:

When managing apps with different React versions, create separate libraries for each version:

# Modern UI library (React 19)
npx nx generate @nx/react:library ui-modern --directory=libs/shared --style=scss

# Legacy UI library (React 18)
npx nx generate @nx/react:library ui-legacy --directory=libs/shared --style=scss

Configure library dependencies in package.json (package-based) or use peer dependencies:

// libs/shared/ui-modern/package.json
{
  "peerDependencies": {
    "react": "^19.0.0",
    "react-dom": "^19.0.0"
  }
}

// libs/shared/ui-legacy/package.json
{
  "peerDependencies": {
    "react": "^18.0.0",
    "react-dom": "^18.0.0"
  }
}

4. Generate Components

Create components within your libraries:

# Generate a component in a library
npx nx generate @nx/react:component Button --project=ui-components --directory=src/lib

# Generate a component with export
npx nx generate @nx/react:component Header --project=ui-components --export

The component will be generated with:

• Component file (.tsx)

• Style file (.scss)

• Test file (.spec.tsx)

• Automatic export from library's index file (if --export is used)

Working with State Management

Redux Toolkit

NX provides a Redux slice generator:

npx nx generate @nx/react:redux todos --project=my-app

This generates:

• Redux slice with TypeScript

• Configured store setup

• Test files

For shared state across apps, create a dedicated state library:

npx nx generate @nx/react:library state --directory=libs/shared
npx nx generate @nx/react:redux users --project=state

Sharing Assets and Styles

Global Styles Library

Create a centralized styles library:

npx nx generate @nx/react:library styles --directory=libs/shared --style=scss --bundler=none

Configure in your app's project.json:

{
  "targets": {
    "build": {
      "options": {
        "styles": ["libs/shared/styles/src/lib/global.scss"],
        "stylePreprocessorOptions": {
          "includePaths": ["libs/shared/styles/src/lib"]
        }
      }
    }
  }
}

Then import in your components:

@import "variables";
@import "mixins";

.my-component {
  background: $primary-color;
}

Shared Assets

Configure assets in project.json:

{
  "targets": {
    "build": {
      "options": {
        "assets": [
          "apps/my-app/src/favicon.ico",
          "apps/my-app/src/assets",
          {
            "input": "libs/shared/assets/src",
            "glob": "**/*",
            "output": "assets"
          }
        ]
      }
    }
  }
}

Testing Configuration

Unit Testing with Vitest (Recommended)

Modern NX workspaces use Vitest by default:

# Run tests for a specific project
npx nx test my-app

# Run tests for all projects
npx nx run-many --target=test

# Run tests only for affected projects
npx nx affected --target=test

Configure coverage in vitest.config.ts:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    coverage: {
      provider: 'v8',
      reporter: ['text', 'html', 'lcov'],
      thresholds: {
        branches: 80,
        functions: 80,
        lines: 80,
        statements: 80
      }
    }
  }
});

E2E Testing with Cypress

Generate E2E tests with Cypress:

# Configure Cypress for an application
npx nx generate @nx/cypress:configuration --project=my-app

# Run Cypress tests
npx nx e2e my-app-e2e

# Run Cypress in interactive mode
npx nx e2e my-app-e2e --watch

Cypress tests are automatically generated in a separate e2e project:

my-workspace/
├── apps/
│   ├── my-app/
│   └── my-app-e2e/              # Cypress E2E tests
│       ├── src/
│       │   ├── e2e/
│       │   │   └── app.cy.ts
│       │   ├── fixtures/
│       │   └── support/
│       ├── cypress.config.ts
│       └── project.json

Storybook Integration

Set up Storybook for component development:

# Configure Storybook for a library
npx nx generate @nx/react:storybook-configuration ui-components

# Run Storybook
npx nx storybook ui-components

# Generate stories for all components
npx nx generate @nx/react:stories ui-components

Modern Storybook Setup (v7+):

• Uses Vite for faster builds

• Component Story Format 3 (CSF3)

• Automatic story generation

• Interaction testing support

Building and Deployment

Production Build

# Build a specific app
npx nx build my-app --configuration=production

# Build all apps
npx nx run-many --target=build --configuration=production

# Build only affected projects
npx nx affected --target=build --configuration=production

Build Optimization

Configure in project.json:

{
  "targets": {
    "build": {
      "configurations": {
        "production": {
          "optimization": true,
          "extractCss": true,
          "sourceMap": false,
          "namedChunks": false
        }
      }
    }
  }
}

Essential NX Commands

Workspace Operations

# View project dependency graph
npx nx graph

# List all projects
npx nx show projects

# Show project details
npx nx show project my-app

# Run linting
npx nx lint my-app

# Format code
npx nx format:write

Affected Commands

NX's killer feature - only work on what changed:

# Show affected projects
npx nx affected:graph

# Test affected projects
npx nx affected --target=test

# Build affected projects
npx nx affected --target=build

# Lint affected projects
npx nx affected --target=lint

Removing Projects

# Remove a project
npx nx generate @nx/workspace:remove my-old-app

# Dry run first
npx nx generate @nx/workspace:remove my-old-app --dry-run

Path Mapping and Imports

NX configures TypeScript path mappings in tsconfig.base.json:

{
  "compilerOptions": {
    "paths": {
      "@my-workspace/ui-components": ["libs/shared/ui-components/src/index.ts"],
      "@my-workspace/utils": ["libs/shared/utils/src/index.ts"],
      "@my-workspace/state": ["libs/shared/state/src/index.ts"]
    }
  }
}

Import like this:

import { Button } from '@my-workspace/ui-components';
import { formatDate } from '@my-workspace/utils';

CI/CD Integration

NX automatically generates GitHub Actions configuration:

# .github/workflows/ci.yml
name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  main:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - run: npm ci

      - uses: nrwl/nx-set-shas@v4

      - run: npx nx affected --target=lint
      - run: npx nx affected --target=test
      - run: npx nx affected --target=build

Performance Best Practices

1. Enable Nx Cloud: Provides remote caching and distributed task execution

2. Use Affected Commands: Only build/test what changed

3. Configure Caching: Ensure all targets are cacheable in nx.json

4. Use Vite: Much faster than webpack for development and builds

5. Parallel Execution: NX automatically runs tasks in parallel when possible

6. Choose the Right Strategy:

   • Use integrated for better performance and simpler dependency management

   • Use package-based only when you truly need different dependency versions across apps

Dependency Management Strategies Comparison

NX fully supports both dependency management strategies, and you can even mix these strategies, using a single version policy for most dependencies while allowing specific projects to maintain their own versions when necessary.

Single Version Policy (Integrated - Recommended)

Pros:

• ✅ Simpler dependency management

• ✅ Better caching and performance

• ✅ Reduces duplication and conflicts

• ✅ Easier upgrades (update once, affects all)

• ✅ Guaranteed compatibility between shared libraries

Cons:

• ❌ All apps must coordinate on dependency versions

• ❌ Breaking changes affect entire workspace

• ❌ May need to keep older apps on older framework versions

Independent Dependencies (Package-Based)

Pros:

• ✅ Each app/package controls its own dependencies

• ✅ Easier to migrate existing projects

• ✅ Can run different React versions simultaneously

• ✅ Individual apps can upgrade independently

Cons:

• ❌ More complex dependency management

• ❌ Potential version conflicts when sharing code

• ❌ Larger total node_modules size

• ❌ Harder to ensure compatibility

• ❌ Runtime errors when sharing components between different React versions

When to Use Each Approach

Use Integrated (Single Version) When:

• All apps are actively maintained

• Teams can coordinate on upgrades

• Apps share significant code

• Performance and caching are priorities

• Starting a new monorepo from scratch

Use Package-Based (Multiple Versions) When:

• Migrating existing independent projects

• Apps have vastly different technology needs

• You need to support legacy apps alongside modern ones

• Different teams own different apps with minimal overlap

• Apps are published as independent NPM packages

Key Benefits Summary

• ✅ Test Components in Isolation: Storybook integration for component development

• ✅ Easy Code Sharing: Import libraries with clean TypeScript paths

• ✅ Modern Tooling: Vite, Vitest, Cypress, ESLint, Prettier pre-configured

• ✅ CLI Generators: Bootstrap apps, libraries, and components with consistent structure

• ✅ Visual Dependency Graph: Understand project relationships at a glance

• ✅ Smart CI/CD: Only test and build affected projects

• ✅ Framework Flexibility: React, Node.js, and many other frameworks in one repo

• ✅ Type Safety: Full TypeScript support across the workspace

Migration Notes from Legacy NX

If updating from older NX versions:

1. Package Names: @nrwl/* → @nx/*

2. Commands: nx affected:test → nx affected --target=test

3. Bundlers: Consider migrating from webpack to Vite

4. Test Runners: Consider migrating from Jest to Vitest

5. Configuration: workspace.json deprecated, use project.json files

Run the migration command:

npx nx migrate latest
npx nx migrate --run-migrations

Final Repository Structure

After following this guide, here are two example structures depending on your approach:

Integrated Workspace Structure (Single Version Policy)

my-workspace/
├── apps/
│   ├── customer-portal/                 # Modern React 19 app
│   │   ├── src/
│   │   │   ├── app/
│   │   │   │   ├── app.tsx
│   │   │   │   ├── app.module.scss
│   │   │   │   └── redux/
│   │   │   ├── main.tsx
│   │   │   ├── assets/
│   │   │   └── styles.scss
│   │   ├── project.json
│   │   ├── vite.config.ts
│   │   └── tsconfig.json
│   │
│   ├── customer-portal-e2e/
│   │   ├── src/
│   │   │   ├── e2e/
│   │   │   │   └── app.cy.ts
│   │   │   └── support/
│   │   ├── cypress.config.ts
│   │   └── project.json
│   │
│   └── admin-dashboard/                 # Another React 19 app
│       ├── src/
│       ├── project.json
│       └── vite.config.ts
│
├── libs/
│   └── shared/
│       ├── ui-components/              # Shared React components
│       │   ├── src/
│       │   │   ├── index.ts
│       │   │   └── lib/
│       │   │       ├── button/
│       │   │       ├── header/
│       │   │       └── card/
│       │   ├── .storybook/
│       │   ├── project.json
│       │   └── vite.config.ts
│       │
│       ├── utils/                      # Shared utilities
│       │   ├── src/
│       │   │   ├── index.ts
│       │   │   └── lib/
│       │   │       ├── date-utils.ts
│       │   │       └── string-utils.ts
│       │   └── project.json
│       │
│       ├── state/                      # Shared Redux state
│       │   ├── src/
│       │   │   ├── index.ts
│       │   │   └── lib/
│       │   │       ├── store.ts
│       │   │       └── slices/
│       │   └── project.json
│       │
│       ├── styles/                     # Shared SCSS
│       │   ├── src/
│       │   │   └── lib/
│       │   │       ├── _variables.scss
│       │   │       ├── _mixins.scss
│       │   │       └── global.scss
│       │   └── project.json
│       │
│       └── assets/                     # Shared images, icons
│           └── src/
│
├── .github/
│   └── workflows/
│       └── ci.yml
│
├── node_modules/
├── dist/
├── nx.json
├── package.json                        # Single source for all dependencies
├── tsconfig.base.json
└── README.md

Package-Based Structure (Multiple Versions Support)

Best for scenarios where apps need different React versions or independent dependencies:

my-workspace/
├── packages/
│   ├── modern-app/                     # React 19 application
│   │   ├── src/
│   │   │   ├── app/
│   │   │   └── main.tsx
│   │   ├── package.json                # React 19.2.0
│   │   ├── project.json
│   │   ├── vite.config.ts
│   │   └── node_modules/               # App-specific deps
│   │
│   ├── legacy-app/                     # React 18 application
│   │   ├── src/
│   │   │   ├── app/
│   │   │   └── main.tsx
│   │   ├── package.json                # React 18.2.0, lodash 4.17.0
│   │   ├── project.json
│   │   ├── webpack.config.js
│   │   └── node_modules/
│   │
│   ├── admin-portal/                   # React 19 with different packages
│   │   ├── src/
│   │   ├── package.json                # React 19.2.0, Material-UI 6
│   │   ├── project.json
│   │   └── node_modules/
│   │
│   ├── ui-modern/                      # UI lib for React 19
│   │   ├── src/
│   │   │   ├── index.ts
│   │   │   └── lib/
│   │   │       ├── Button/
│   │   │       └── Card/
│   │   ├── package.json                # peerDeps: React 19
│   │   ├── project.json
│   │   └── node_modules/
│   │
│   ├── ui-legacy/                      # UI lib for React 18
│   │   ├── src/
│   │   │   ├── index.ts
│   │   │   └── lib/
│   │   ├── package.json                # peerDeps: React 18
│   │   ├── project.json
│   │   └── node_modules/
│   │
│   ├── shared-utils/                   # Framework-agnostic utils
│   │   ├── src/
│   │   │   ├── index.ts
│   │   │   └── lib/
│   │   ├── package.json                # No React dependency
│   │   └── project.json
│   │
│   └── shared-types/                   # TypeScript types
│       ├── src/
│       │   └── index.ts
│       ├── package.json
│       └── project.json
│
├── .github/
│   └── workflows/
│       └── ci.yml
│
├── node_modules/                       # Shared dev dependencies only
├── dist/
├── nx.json
├── package.json                        # Root-level dev dependencies
├── pnpm-workspace.yaml                 # or yarn workspaces config
├── tsconfig.base.json
└── README.md

Real-World Example: Multi-Version Dependency Configuration

Root package.json (Package-Based):

{
  "name": "my-workspace",
  "private": true,
  "workspaces": [
    "packages/*"
  ],
  "devDependencies": {
    "@nx/react": "^21.6.4",
    "@nx/vite": "^21.6.4",
    "@nx/webpack": "^21.6.4",
    "typescript": "^5.3.0",
    "vitest": "^1.0.0",
    "eslint": "^8.55.0",
    "prettier": "^3.1.0"
  }
}

Modern App package.json:

{
  "name": "@my-workspace/modern-app",
  "version": "3.0.0",
  "dependencies": {
    "react": "^19.2.0",
    "react-dom": "^19.2.0",
    "react-router-dom": "^6.20.0",
    "@tanstack/react-query": "^5.0.0",
    "@my-workspace/ui-modern": "*",
    "@my-workspace/shared-utils": "*"
  }
}

Legacy App package.json:

{
  "name": "@my-workspace/legacy-app",
  "version": "2.14.5",
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-router-dom": "^6.20.0",
    "redux": "^4.2.0",
    "lodash": "^4.17.21",
    "@my-workspace/ui-legacy": "*",
    "@my-workspace/shared-utils": "*"
  }
}

Admin Portal package.json (Different UI library):

{
  "name": "@my-workspace/admin-portal",
  "version": "1.5.2",
  "dependencies": {
    "react": "^19.2.0",
    "react-dom": "^19.2.0",
    "@mui/material": "^6.0.0",
    "@emotion/react": "^11.11.0",
    "recharts": "^2.10.0",
    "@my-workspace/shared-utils": "*"
  }
}

Key Structure Highlights

Apps Directory: Contains deployable applications. Each app has its own configuration and can be built independently.

Libs/Packages Directory: Contains reusable code. In integrated mode, organized by scope (e.g., shared). In package-based mode, each package is independent.

Project Configuration: Each project has a project.json file defining its build, test, lint, and serve targets.

Path Mappings: The tsconfig.base.json creates clean imports:

// Instead of: import { Button } from '../../../libs/shared/ui-components/src/lib/button/button'
// You write:
import { Button } from '@my-workspace/ui-components';

// Package-based with version-specific libraries:
import { Button } from '@my-workspace/ui-modern';  // For React 19 apps
import { Button } from '@my-workspace/ui-legacy';  // For React 18 apps

Dependency Graph: NX tracks dependencies between projects. For example:

• Integrated: customer-portal → ui-components, state, utils

• Package-Based:

  • modern-app (React 19) → ui-modern, shared-utils

  • legacy-app (React 18) → ui-legacy, shared-utils

  • admin-portal (React 19) → shared-utils (uses MUI instead of custom UI)

This structure scales from small teams to large enterprises, keeping your codebase organized, maintainable, and performant while supporting multiple React versions and varying dependency requirements.

Conclusion

NX has matured into a comprehensive monorepo solution that dramatically improves developer productivity. With intelligent caching, affected-only commands, and modern tooling integration, it's an excellent choice for teams managing multiple related projects. Start small with a single app and library, then scale as your needs grow.

For more information, visit the official NX documentation.

If you are using React v19, React automatically adds memoization when it’s necessary with the React Compiler. React Compiler automatically analyzes code and memoizes components and functions that it determines will never change. It can automatically optimize performance by identifying and memoizing stable parts of the application at build time. If you are working on an older codebase, you would want to understand its usage.

React.Memo

Just wrap the expensive function with it, and it will only rerender if the props change.

However, for objects and arrays, React.memo performs a shallow comparison of props. This means it only checks if the new object has the same reference in memory as the old object, not whether the contents of the objects are identical.

If the parent component creates a new object on every render, even if the new object contains the same values, the memoized child component will still rerender. So in this case, put in the second parameter to actually compare its value.

import { memo, useState } from 'react';

const MemoizedChild = memo(({ user }) => {
  // expensive operations...
  return <div>{user.name}</div>;
}, (prevProps, nextProps) => {
  // actually compare its value
  return prevProps.user.name === nextProps.user.name;
});

function Parent() {
  const [count, setCount] = useState(0);

  // A new user object is created every time Parent re-renders
  const user = { name: 'John' }; 

  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>Increment</button>
      <MemoizedChild user={user} />
    </div>
  );
}

React.useMemo and React.useCallback

They both compare the value of the objects listed in the dependency list. useCallback is a wrapper of useMemo, so they do the same thing, and the syntax is very similar.

const render = useMemo(() => (user) => expensiveCall(user), [user]);
const render2 = useCallback((user) => expensiveCall(user), [user]);

The idea of memorization sounds very good, but don’t overuse it. Strings and numbers should never be memoized because they are compared by value, not by pointer. Also, there is a cost to make deep comparisons at every render, and it may cause bugs by not updating the child components correctly.

Overview

React Context is a built-in API for lightweight global state sharing. It’s ideal for passing data like themes, authentication, and language preferences down the component tree without manual prop drilling.

Best Use Cases

1. Static configuration or environment data

   • Themes (light/dark), app locale, and layout direction.

2. User authentication data

   • User objects, session tokens, or login states that only update occasionally.

3. Low-frequency UI preferences

   • Sidebar visibility, global UI toggles, or user settings shared across the app.

4. Dependency injection

   • Providing singletons or services (logger, analytics) across the app without prop chaining.

When Not to Use

Avoid using Context for rapidly changing or complex state (e.g., real-time data, form state) since every consuming component re-renders when any part of the context value updates.​

Example Projects

• Static websites or documentation portals.

• Small dashboards with limited global state.

• Apps where global data rarely changes.

MobX

Overview

MobX is a reactive state management library that uses observable data and computed values. You directly mutate observables, MobX tracks dependencies, and components re-render automatically. It shines when you need fine-grained reactivity and minimal boilerplate for updating complex, interdependent state values.

Best Use Cases

1. Medium-sized projects emphasizing reactivity

   • Live dashboards, trading terminals, or monitoring systems with auto-updating data streams.

2. Applications with real-time updates

   • Messaging apps, tracking interfaces, or collaborative documents.

3. Object-oriented state models

   • Domain stores like UserStore, CartStore, and SettingsStore reflecting real-world entities.

4. Interactive UI logic

   • Components with many derived values, filters, and computed relationships.

Key Advantages

• Automatic and selective re-rendering based on observed data access.

• Minimal ceremony — mutate state directly through actions.

• Natural developer workflow for complex reactive UIs.

When Not to Use

• Large multi-team apps need a rigid structure or auditability.

• Teams that rely heavily on explicit time-travel debugging and schema validation.​

Example Projects

• Live analytics dashboards.

• IoT or data visualization panels.

• Real-time editors or chat tools.

Redux

Overview

Redux is a predictable, centralized state container built around immutability and a unidirectional data flow. You dispatch actions, reducers create new state, and components re-render. It’s designed for scalability, debugging clarity, and long-term maintainability in complex applications.

Best Use Cases

1. Large-scale applications

   • E-commerce platforms, analytics suites, and project management tools where consistency across views is essential.

2. Collaborative multi-developer teams

   • Its strict structure (actions, reducers, store) provides clear collaboration boundaries and conflict-free state management.

3. Apps requiring auditability

   • Systems that need time-travel debugging, rollback, or user-session replays.

4. Complex asynchronous flows

   • APIs managed with Redux Thunk, Redux Saga, or RTK Query.

Key Advantages

• Predictability through pure reducers and explicit state transitions.

• Advanced dev tooling and ecosystem maturity.

• Easy integration with testing frameworks.

When Not to Use

• Smaller apps or prototypes where overhead from reducers and action patterns outweighs benefits.

• UIs focused on frequent, granular state changes — MobX is more performant in those cases.​

Example Projects

• Large enterprise or SaaS products with distributed teams.

• Financial dashboards or product catalogs with multiple layers of derived data.

• Any application whose global state must remain auditable across sessions.

Detailed Comparison

Here is a detailed comparison of React Context, MobX, and Redux, highlighting their differences in philosophy, implementation, and performance across key dimensions.​

Summary Interpretation

• React Context: Lightweight and built-in—ideal for themes, configuration, or simple shared state.

• MobX: Prioritizes developer ergonomics and render performance through automatic reactivity; excellent for medium-sized, UI-focused apps.

• Redux: Best for large, collaborative, or enterprise apps needing explicitness, scalability, and auditability for the global state.

Choosing between them depends on whether your top priority is ease, reactivity, or control.​ MobX delivers the most efficient re-render performance, Redux offers the most predictability and debugging power, and Context remains the simplest global state-sharing option when reactivity isn’t essential.

Create a function that takes in an array of numbers and returns an object in the specified format based on their counts.

Input array: [1, 2, 3, 3, 4, 3, 2, 4, 4, 5, 4]

Expected return: 
{
  unique: [1, 5],
  twice: [2],
  threePlus: [3, 4]
}

Notice the keys in the return object are set. So a type should be created for it. What are the other questions you could ask?

1. Should there be an empty array in the return object if there is no value in that category, or not have the category in the object at all?

2. Are the numbers sorted?

Below is a solution to set an empty array by default and keep the order of the numbers in the original list:

const numbers = [1, 2, 3, 3, 4, 3, 2, 4, 4, 5, 4];

type CountType = 'unique' | 'twice' | 'threePlus';

let counts: Record<CountType, number[]> = {
  unique: [],
  twice: [],
  threePlus: []
};
let countMap: Record<number, number> = {};

const checkCount = (numbers: number[]): Record<CountType, number[]> => {

  for (let n of numbers) {
    countMap[n] = countMap[n] ? countMap[n]+1 : 1
  }
  for (let c in countMap){
    if(countMap[c] === 1){
      counts.unique.push(Number(c)); //when you set a number as the key, js converts it into string
    } else if (countMap[c] === 2){
      counts.twice.push(Number(c));
    } else {
      counts.threePlus.push(Number(c));
    }
  }
  return counts;
}

If the numbers in the returned object should be sorted, the list should be sorted at the beginning instead of looping through the values in the return object again. And you won’t need the map to keep track of the count because you can compare the previous number with the next and get the count of that number.

Create a function to remove duplicates and empty spaces in a given string.

Step one is always to consider all possible conditions and ask questions to clarify. For example:

1. Should the check be case sensitive?

2. Does the new string keep the same casing and order?

Next, consider what data structures should be used with the conditions to meet the requirements.

In general, coding exercises involving strings are easier to handle by converting them into an array because it has a lot of handy methods. But it all comes down to the time and space complexity. For simple changes, even converting into a different data structure itself is an overhead cost. Another consideration is whether you can use an object for its advantage of O(1).

const removeDuplicates = (str:string): string =>{

  type letterMapType = {[key:string]: number};
  let letterMap:letterMapType ={};
  let uniqueString = "";

  for(const letter of str){
    const letterLowerCase = letter.toLowerCase();
    if(letter === " "){
        continue;
    }
    else if(!letterMap[letterLowerCase]){
        uniqueString += letter;
        letterMap[letterLowerCase] = 1;
    }
  }
  return uniqueString;
}

removeDuplicates('This is a test. TEST1 Test2 Done!'); // "Thisae.12Don!"

Also, for the questions involving uniqueness, consider using Set. One thing to remember is that Sets are case-sensitive, so an array needs to be converted to lowercase first, then a Set for a case-insensitive check. The output will then be all in lowercase as well, unless we loop through the original string again.

So let’s say the requirement for the function is simply to remove any duplicate letters in a case-sensitive way. Below is a quick solution using Set.

const removeDuplicates = (str:string): string =>{

  const letterSet = new Set(str.split(''));
  return [...letterSet].join('');

}

removeDuplicates('This is a test. TEST1 Test2 Done!'); //"This ate.ES12Don!"

TypeScript has become the de facto way to write JavaScript applications because it sets type guards at build time to ensure the code logic is as intended throughout the codebase. But when the application interacts with an external data source, it’s not something TypeScript can foresee and validate.

One of the most essential aspects of frontend development is collaborating with the backend developer to determine the necessary data in an optimal data structure. And there will be API changes later. How can we verify that the UI codebase and the backend are in sync? That is where Zod comes in — runtime validation.

Zod at a Glance

import * as z from "zod";

// create a schema for a post
const PostSchema = z.object({
  id: z.coerce.number(), //coerce string or boolean into number
  title: z.string(),
  body: z.string().nullable(), // string | null 
  email: z.email(),  //email validation
  published: z.coerce.boolean.(), 
  tags: z.array(z.string()).default([]) //array of string and default to an empty array
});

// create a type based on the schema
type Post = z.infer<typeof PostSchema>;

const getPose = async (id: number) => {
  // fetch mock data from jsonplaceholder
  const response = await fetch(https://jsonplaceholder.typicode.com/posts/${id});
  const post = response.json();

  // the parsed result is validated and type safe
  const post = PostSchema parse(post);
  return post;
}

If you have a type defined already, add validation to ensure the schema is validated against the type.

const PostSchema = z.object({
  id: z.coerce.number(), 
  title: z.string(),
  body: z.string().nullable() 
}) satisfies z.ZodType<Post>;

If you are excited to use Zod in your application, check out their website for additional advanced features, including error handling, custom error messages, and metadata. There is also an excellent tutorial to get you started.

Create a function to flatten an array without using the Array method .flat()

Given an array [1,2,[3,4, [5,6,7], 8], 9, [10, [20], 30]]

The function should return [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 20, 30]

Note in the example array, the number of levels is unspecified, and it can be nested in any way.

Looping through a list and repeating the same operation with different parts should prompt you to use recursion. Below is a decent solution.

const exampleArray = [1,2,[3,4, [5,6,7], 8], 9, [10, [20], 30]];
let flattenArray: number[] = [];
type DeepArray<T> = Array<T | DeepArray<T>>;

const flatten = (numbers: DeepArray<number>): void => {
  for (let num of numbers) {
    if (Array.isArray(num)){
      flatten(num);
    } else {
      flattenArray.push(num);
    }
  }
}

flatten(exampleArray); // [1,2,3,4,5,6,7,8,9,10]

If you want something fancier, use the Array method reduce.

const exampleArray = [1,2,[3,4, [5,6,7], 8], 9, [10, [20], 30]];

type NestedNumberArray = Array<number | NestedNumberArray>;

const flatten = (numbers: NestedNumberArray): NestedNumberArray => {
  return numbers.reduce((accu: NestedNumberArray, num: number | NestedNumberArray) => {
    if (Array.isArray(num)){
      accu = accu.concat(flatten(num));
    } else {
      accu.push(num);
    }
    return accu;
  },[]);
}

flatten(exampleArray); // [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 20, 30]

1. The Magical Property Flex

With Flexbox, you define a flex container and then control how its flex items behave inside it — including their size, order, and alignment.

With a parent container with class ‘container‘ and child items inside it. The magic starts with just setting the display to flex:

.container {
  display: flex;
}

2. Flexbox Properties

Flex container properties:

Flex item properties:

3. Example of a Responsive Two-Column Layout

.container {
  display: flex;
  gap: 1rem;
}
.sidebar {
  flex: 1;
}
.main {
  flex: 3;
}

Why Use Debounce and Throttle

• Debounce: Ensures a function only runs after a specified delay from the last time it was called. Ideal for search boxes, window resizing, or form validation, where you don't want to query the server on every keystroke—only after the user stops typing.

• Throttle: Ensures a function runs at most once in a set time interval. Perfect for scroll and resize events, where you want smooth updates without overwhelming the browser or APIs.

Debounce Implementation

function debounce(func, delay) {
  let timeoutId;
  return function (...args) {
    clearTimeout(timeoutId);
    timeoutId = setTimeout(() => func.apply(this, args), delay);
  };
}

const test = (text) => console.log(text);
const debounceTest = debounce(test, 10000);

debounceTest("Hello, World!");
// this call cancles the first timer
// "Hello, World! 2" is logged after 15 seconds
setTimeout(() => debounceTest("Hello, World! 2"), 5000);

Throttle Implementation

function throttle(func, limit) {
  let inThrottle;
  return function (...args) {
    if (!inThrottle) {
      func.apply(this, args);
      inThrottle = true;
      setTimeout(() => (inThrottle = false), limit);
    }
  };
}

const test = (text) => console.log(text);
const throttledTest = throttle(test, 10000);

//only the first one is logged
throttledTest("Hello, World! One and only.");
throttledTest("Hello, World! 2");
throttledTest("Hello, World! 3");

// call again after the throttle time
setTimeout(() => {
  //the first one is logged
  throttledTest("Hello, World! Again");
  throttledTest("Hello, World! 2");
}, 15000);

1. Use :focus-visible for keyboard-only focus outlines

/* Outline is shown only for keyboard-only focus */
button:focus-visible {
  outline: 2px solid blue;
  outline-offset: 2px;
}

2. Never remove outlines without replacement

/* Bad */
*:focus { outline: none; }

/* Good */
*:focus-visible {
  outline: 2px solid currentColor;
  outline-offset: 2px;
}

3. Use prefers-reduced-motion for animations

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Color & Contrast

4. Ensure sufficient color contrast

• Text: minimum 4.5:1 ratio (WCAG AA)

• Large text (18pt+): minimum 3:1 ratio

• Use tools like WebAIM contrast checker

5. Don't rely on color alone

Make sure there is text or other clear indications to convey the message.

6. Use currentColor for flexible theming

.icon {
  border: 2px solid currentColor; /* Inherits text color */
}

Typography

7. Use relative units for font sizes

/* Respects user's browser font size preferences */
body { font-size: 1rem; }
h1 { font-size: 2rem; }

8. Set comfortable line heights

body {
  line-height: 1.5; /* WCAG recommends 1.5 minimum for body text */
}

9. Limit line length for readability

p {
  max-width: 65ch; /* Optimal: 45-75 characters per line */
}

Responsive Design

10. Use clamp() for fluid typography

h1 {
  /* Minimum: 1.5rem (24px) - won't go smaller, even on tiny screens
     Preferred: 5vw (5% of viewport width) - scales with screen size
     Maximum: 3rem (48px) - won't go larger, even on huge screens
  */
  font-size: clamp(1.5rem, 5vw, 3rem);
}

11. Make tap targets large enough

button, a {
  min-height: 44px; /* Apple & Google recommend 44-48px */
  min-width: 44px;
}

12. Use gap instead of margins in flex/grid

.container {
  display: flex;
  gap: 1rem; /* Cleaner than margin hacks */
}

Visibility & Display

13. Add a custom class to hide content for screen readers only

/* Screen reader accessible but visually hidden */
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

14. Avoid display: none for focusable elements

/* Bad - removes from tab order */
.hidden { display: none; }

/* Good - visually hidden but still accessible */
.visually-hidden { /* use sr-only class above */ }

Forms

15. Style form validation states clearly

input:invalid {
  border-color: red;
}
input:valid {
  border-color: green;
}
/* But only after interaction */
input:not(:placeholder-shown):invalid {
  border-color: red;
}

16. Increase input padding for better touch targets

input, textarea, select {
  padding: 0.75rem 1rem;
  font-size: 1rem; /* Prevents zoom on iOS */
}

17. Style disabled states obviously

button:disabled {
  opacity: 0.6;
  cursor: not-allowed;
}

Layout & Spacing

18. Use logical properties for internationalization

/* Instead of margin-left */
margin-inline-start: 1rem; /* Works for RTL languages */

19. Prefer padding over height for vertical spacing

/* More flexible and accessible */
button {
  padding: 0.75rem 1.5rem;
  /* Not: height: 40px; */
}

20. Use aspect-ratio for responsive media

.video-container {
  aspect-ratio: 16 / 9; /* Modern browsers */
  width: 100%;

  /* Fallback for older browsers */
  @supports not (aspect-ratio: 16 / 9) {
    padding-bottom: 56.25%;
  }
}

Dark Mode

21. Support dark mode preferences

@media (prefers-color-scheme: dark) {
  body {
    background: #1a1a1a;
    color: #f0f0f0;
  }
}

Performance

22. Use content-visibility for long lists

.list-item {
  content-visibility: auto;
  contain-intrinsic-size: 0 200px;
}

23. Optimize animations with will-change

.animated {
  will-change: transform; /* Use sparingly */
}

Misc

24. Use pointer-events carefully

/* Be cautious - affects accessibility */
.overlay {
  pointer-events: none;
}

If you need to disable all user interactions on an element, consider using inert attribute:

• Removes elements from tab order

• Prevents clicks

• Hides from screen readers

• Can be toggled with JavaScript

// Toggle overlay
overlay.inert = false; // Make interactive
overlay.inert = true;  // Make non-interactive

25. Add :has() for parent-based styling

/* Style form if it has invalid input */
form:has(input:invalid) {
  border: 2px solid red;
}

26. Use scroll-margin-top for anchor links

:target {
  scroll-margin-top: 80px; /* Accounts for fixed header */
}

27. Smooth scrolling (with motion preference)

html {
  scroll-behavior: smooth;
}
@media (prefers-reduced-motion: reduce) {
  html {
    scroll-behavior: auto;
  }
}

These tips will help you build more accessible, user-friendly interfaces that work well for everyone, regardless of their device, abilities, or preferences.

Why JAMstack and Gatsby?

Before diving into the implementation, let's understand the foundation: JAMstack (JavaScript + APIs + Markup). This modern web development architecture is built on three core principles:

• JavaScript: Client-side code that handles dynamic functionality

• APIs: External services accessed over HTTPS with JavaScript

• Markup: Static content including HTML, CSS, and images

The key advantage? All static content is rendered at build time, not runtime. This approach delivers significant benefits:

• Better performance: Static files can be hosted on CDNs, ensuring lightning-fast load times

• Enhanced security: No server-side processing means reduced attack surface

• SEO-friendly: Pre-rendered HTML is easily crawlable by search engines

Why Gatsby for Documentation?

Gatsby excels at building documentation sites because it seamlessly handles multiple data sources. Whether you're working with Markdown files, WordPress, headless CMSs, or other sources, Gatsby's built-in GraphQL server fetches and processes data at build time, generating static files in the public folder.

For documentation sites, this means your Markdown files are converted into optimized HTML pages during the build process, resulting in a blazingly fast user experience.

Setting Up Your Gatsby Documentation Site

Initial Setup

Follow the Gatsby official tutorial to set up your project

Adding Sass Support

For styling flexibility, add Sass to your project:

npm install --save node-sass gatsby-plugin-sass

Configuration details can be found at gatsby-plugin-sass.

Handling Local Markdown Files

To work with local Markdown files, install the filesystem source plugin:

npm install --save gatsby-source-filesystem

This plugin allows Gatsby to read files from your local filesystem and make them available through GraphQL queries.

Markdown Processing and Syntax Highlighting

Install the necessary packages for Markdown transformation and code syntax highlighting:

npm install --save gatsby-transformer-remark gatsby-remark-prismjs prismjs

Prism.js provides beautiful syntax highlighting for code blocks in your documentation. You can preview and choose from various Prism themes to match your branding.

If you need to embed React components directly in Markdown files, check out gatsby-remark-component.

Working with Gatsby's Data Layer

Understanding GraphQL in Gatsby

Gatsby comes with a built-in GraphQL server that makes data fetching elegant and powerful. You can explore your data using GraphiQL (typically at http://localhost:8000/___graphql).

Pro tip: Press Ctrl + Space in GraphiQL to get autocomplete suggestions.

Here's a typical GraphQL query structure for Markdown content:

{
  allMarkdownRemark {
    edges {
      node {
        html
        frontmatter {
          updated
        }
      }
    }
  }
}

The edges array contains node objects, where each node holds your actual content.

Two Types of Queries

Gatsby supports two distinct query patterns:

Page Queries:

• Used in page components

• Accept query variables via pageContext

• Perfect for dynamic page generation

Static Queries:

• Can be used in any component

• Don't accept variables

• Use the useStaticQuery hook or StaticQuery component

Building Dynamic Routes

Creating Pages with gatsby-node.js

The gatsby-node.js file is where the magic happens for dynamic routing. Use createNodeField() to generate pages with friendly URLs based on your file structure.

Key steps:

1. Create a page template component

2. Pass context data to the template

3. Use dangerouslySetInnerHTML to insert the generated HTML into your React component

This approach allows you to create a documentation structure that mirrors your file organization, making it intuitive to manage.

Navigation with Gatsby Link

For internal navigation, always use Gatsby's Link component:

https://www.gatsbyjs.com/docs/reference/built-in-components/gatsby-link/

This provides optimized routing with preloading for a snappy user experience.

Styling Considerations

While Gatsby comes with CSS Modules support, there are some gotchas to be aware of:

• Nested CSS classes in Sass files may not work as expected with CSS Modules

• Class names must be camelCase (no dashes)

• File names need the .module.scss extension

For a documentation site with custom branding, you might opt for standard Sass files instead of CSS Modules to avoid these constraints.

Adding Swagger API Documentation

One of the more challenging aspects of developer documentation is incorporating API references. Here's how to integrate Swagger specifications:

Setup

Swagger generates documentation in JSON and YAML formats. To display these specs, use the swagger-ui-react component library:

npm install --save swagger-ui-react

Handling Server-Side Rendering Issues

Swagger UI doesn't support server-side rendering (SSR), which causes build failures with Gatsby. Here's a workaround using lazy loading:

export const SwaggerContainer = props => {
  const { slug } = props;
  const [file, setFile] = React.useState();

  // Only load swagger-ui-react on client side
  if (typeof window !== "undefined") {
    if (!file) {
      getFile(slug)
        .then(data => setFile(data))
        .catch(e => console.error);
    }

    const SwaggerUI = React.lazy(() => import("swagger-ui-react"));

    return (
      <React.Suspense fallback={<div>Loading...</div>}>
        <SwaggerUI spec={file} docExpansion="list" />
      </React.Suspense>
    );
  } else {
    return null;
  }
};

Customizing Swagger Display

Control how your API documentation appears:

• docExpansion="list": Expand operations only

• docExpansion="full": Expand all sections

• docExpansion="none": Collapse everything (default)

Note: Operations without explicit tags will appear under "default" in Swagger UI.

Fixing Jest Test Issues

After implementing lazy loading, you might encounter Jest test failures related to dynamic imports. Fix this by adding Babel support:

npm install --save @babel/plugin-syntax-dynamic-import

Create a .babelrc file:

{
  "presets": ["babel-preset-gatsby"],
  "plugins": ["@babel/plugin-syntax-dynamic-import"],
  "env": {
    "test": {
      "plugins": ["dynamic-import-node"]
    }
  }
}

SEO Optimization

Don't forget to add proper metadata to your pages for better SEO:

npm install --save gatsby-plugin-react-helmet react-helmet

React Helmet allows you to manage document head tags, including titles, meta descriptions, and Open Graph tags.

Final Tech Stack Summary

Here's what powers our documentation site:

• Gatsby: Static site generator and React framework

• Sass: CSS preprocessing for maintainable styles

• Markdown with Prism.js: Content creation with beautiful syntax highlighting

• Swagger UI React: Interactive API documentation

• React Helmet: SEO and metadata management

• Custom branding: No off-the-shelf themes, complete design control

Conclusion

Building a documentation website with Gatsby provides a perfect balance of developer experience and end-user performance. The JAMstack architecture ensures your docs load instantly, while Gatsby's plugin ecosystem handles everything from Markdown processing to API documentation.

The initial setup requires navigating some SSR gotchas (especially with Swagger), but the result is a fast, maintainable documentation site that scales beautifully. Whether you're documenting a small library or a complex API platform, Gatsby gives you the tools to create an exceptional documentation experience.

Ready to get started? Check out the Gatsby tutorials and start building your documentation site today!