Forem: Dr Codewell

The Complete React Context Journey Beginner to Professional

Dr Codewell — Fri, 15 May 2026 17:57:19 +0000

Most developers learn React Context like this:

const ThemeContext = createContext();

…and stop there.

But Context is much deeper than “avoiding prop drilling.”

If you truly master it, Context becomes:

a dependency injection system
a global runtime container
a reactive architecture layer
a foundation for scalable frontend systems

This post walks through the full journey from beginner → advanced → professional patterns.

1. The Real Problem Context Solves

Imagine this:

<App>
  <Dashboard>
    <Sidebar>
      <Profile />
    </Sidebar>
  </Dashboard>
</App>

Now imagine Profile needs the current user.

Without Context:

<App user={user}>
  <Dashboard user={user}>
    <Sidebar user={user}>
      <Profile user={user} />
    </Sidebar>
  </Dashboard>
</App>

This is called prop drilling.

Context lets components access shared data directly.

2. Your First Context

Creating Context

import { createContext } from "react";

export const UserContext = createContext(null);

Providing Context

<UserContext.Provider value={{ name: "Ken" }}>
  <App />
</UserContext.Provider>

Using Context

import { useContext } from "react";

const Profile = () => {
  const user = useContext(UserContext);

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

That’s the beginner level.

Now the important part begins.

3. The Biggest Mistake Beginners Make

This:

<UserContext.Provider
  value={{
    user,
    setUser
  }}
>

Looks innocent.

But every render creates a new object.

That means:

ALL consumers rerender
performance degrades
large apps become slow

4. The First Professional Upgrade

Use useMemo.

const value = useMemo(() => ({
  user,
  setUser
}), [user]);

<UserContext.Provider value={value}>

Now React only updates consumers when dependencies actually change.

This single pattern separates many beginners from intermediate developers.

5. Split Your Contexts

Huge mistake:

<AppContext.Provider value={{
  user,
  theme,
  notifications,
  cart,
  settings
}}>

One update rerenders everything.

Professionals split contexts by responsibility:

<UserProvider>
  <ThemeProvider>
    <CartProvider>
      <App />
    </CartProvider>
  </ThemeProvider>
</UserProvider>

Benefits:

smaller rerenders
better organization
easier debugging
scalable architecture

6. Context Is NOT State Management

This confuses many developers.

Context is a transport mechanism.

It shares data.

It does NOT magically optimize updates.

For heavy state management:

Zustand
Redux
Jotai
Signals
React Query

may perform better.

Use Context for:

✅ authentication
✅ themes
✅ language
✅ app configuration
✅ dependency injection
✅ stable shared services

Avoid using Context for rapidly changing data like:

❌ mouse position
❌ animations
❌ realtime canvas state
❌ high-frequency updates

7. Custom Hooks Make Context Beautiful

Instead of:

const user = useContext(UserContext);

Create a custom hook:

export const useUser = () => {
  return useContext(UserContext);
};

Now usage becomes:

const user = useUser();

Cleaner.

Professional.

Reusable.

8. Add Safety Guards

A professional pattern:

export const useUser = () => {
  const context = useContext(UserContext);

  if (!context) {
    throw new Error(
      "useUser must be used inside UserProvider"
    );
  }

  return context;
};

This prevents silent bugs.

9. Advanced Context Architecture

Large applications often use Context like a service container.

Example:

<ApiContext.Provider value={apiClient}>
<AuthContext.Provider value={authService}>
<LoggerContext.Provider value={logger}>

Now components can access infrastructure globally.

This becomes extremely powerful in enterprise apps.

10. Context + Reducers

One of the best combinations:

const [state, dispatch] = useReducer(reducer, initialState);

Then:

<AppContext.Provider value={{ state, dispatch }}>

This creates a lightweight Redux-style architecture.

11. The Rerender Trap

Very important.

When context updates:

ALL consumers rerender.

Even if they only use one field.

Example:

const value = {
  user,
  notifications
};

Changing notifications rerenders components using only user.

Solutions:

split contexts
memoize values
selector libraries
Zustand/Jotai for granular subscriptions

12. Context in Next.js

In Next.js App Router:

"use client";

is required for client-side Context providers.

Example:

"use client";

export function Providers({ children }) {
  return (
    <ThemeProvider>
      {children}
    </ThemeProvider>
  );
}

Then wrap layout:

<html>
  <body>
    <Providers>
      {children}
    </Providers>
  </body>
</html>

13. Professional Folder Structure

A scalable structure:

src/
 ├── context/
 │    ├── user/
 │    │    ├── UserContext.js
 │    │    ├── UserProvider.jsx
 │    │    └── useUser.js
 │    │
 │    ├── theme/
 │    └── auth/

Keeps applications maintainable.

14. When NOT To Use Context

Do not force Context everywhere.

Sometimes props are cleaner.

Bad:

<ThemeContext.Provider>

for a single button component.

Good developers know when not to abstract.

15. Final Professional Mindset

Beginner mindset:

“Context avoids prop drilling.”

Professional mindset:

“Context is an application-wide dependency and communication layer.”

That shift changes everything.

Recommended Learning Path

Beginner

createContext
Provider
useContext

Intermediate

useMemo
custom hooks
provider composition
reducer patterns

Advanced

rerender optimization
architecture design
dependency injection
context splitting
hybrid state systems

Professional

scalable provider systems
performance engineering
server/client boundaries
runtime-aware architecture

React Context looks simple.

But mastering it teaches some of the deepest ideas in frontend engineering:

rendering behavior
state propagation
dependency management
architecture scaling
performance tradeoffs

And those lessons carry into every frontend framework you’ll ever use.

Building a Rust-Like Runtime for JavaScript in React

Dr Codewell — Fri, 15 May 2026 17:53:38 +0000

*JavaScript is flexible. Sometimes *too flexible.
**
A string becomes a number.
undefined appears from nowhere.
Async code silently fails.
One mutated object breaks an entire component tree.

After fighting those problems for years, I started experimenting with something different:

A runtime layer for JavaScript that brings stricter memory handling, typed structures, controlled loops, and safer async execution — while still working inside React.

I call the idea StrictJS Runtime.

Why I Started Building It

Modern frontend apps are becoming extremely complex:

Realtime dashboards
ML in the browser
Heavy state synchronization
WebAssembly integrations
Streaming APIs
Massive React trees

But JavaScript still allows things like:

const user = {};
user.profile.name.first.last = "Ken";

…and we only discover the mistake at runtime.

I wanted something closer to systems programming ideas:

predictable structures
explicit memory ownership
strict schemas
controlled execution
safer async behavior

Without abandoning JavaScript completely.

The Core Idea

Instead of replacing JavaScript, the runtime wraps dangerous behavior.

Example:

import strictInit from "strictjs-runtime";

const {
  StrictObject,
  StrictString,
  StrictNumber,
  Schema
} = await strictInit({});

Now objects become schema-driven:

const UserSchema = new Schema({
  username: StrictString,
  age: StrictNumber
});

const user = new StrictObject(UserSchema, {
  username: "alex",
  age: 22
});

Invalid data throws immediately:

user.age = "twenty two";
// Error

Safer Async Functions

One thing I hate in frontend apps:

fetch("/api")
  .then(r => r.json())
  .then(data => ...)

Errors disappear everywhere.

So I experimented with a StrictFunction wrapper:

const fetchUser = new StrictFunction(async () => {
  const res = await fetch("/api/user");
  return await res.json();
});

The runtime can then:

track execution
monitor memory usage
enforce return structures
detect invalid async flows

Controlled Loops

Another experiment:

new StrictForLoop({
  start: 0,
  end: 1000,
  callback(i) {
    console.log(i);
  }
});

Why?

Because large uncontrolled loops can freeze React rendering.

A runtime-managed loop can eventually support:

chunked execution
cancellation
cooperative scheduling
React-aware yielding

React Integration

React is where this becomes interesting.

Imagine state that cannot accidentally mutate:

const [user, setUser] = useState(
  new StrictObject(UserSchema, {
    username: "ken",
    age: 20
  })
);

Or runtime-validated hooks:

const useStrictState = (schema, initial) => {
  const [state, setState] = useState(
    new StrictObject(schema, initial)
  );

  return [state, setState];
};

Now your React state becomes structurally protected at runtime.

WebAssembly + Rust Direction

The long-term vision is pushing critical parts into Rust/WASM:

memory management
validation engine
async scheduler
reactive graph execution

JavaScript becomes the interface layer.

Rust becomes the execution core.

This hybrid model could make frontend apps significantly more predictable under heavy workloads.

Is It Faster?

Not always.

Strict systems add overhead.

But the goal is not just raw speed.

The goal is:

reliability
predictability
developer control
safer large-scale frontend systems

In some workloads — especially structured data processing — the tradeoff becomes worth it.

Example: Strict Fetch

const { strict_fetch } = await strictInit({});

const data = await strict_fetch("/api/users")
  .json();

Potential future features:

typed responses
response validation
automatic retries
streaming control
memory tracking

StrictJS Runtime: Bringing Rust-Like Safety to JavaScript with WebAssembly

Dr Codewell — Wed, 06 May 2026 06:34:38 +0000

JavaScript is powerful, flexible… and sometimes too flexible.
If you’ve ever dealt with unpredictable types, silent bugs, or performance bottlenecks in heavy computations, you already know the trade-offs that come with JavaScript’s dynamic nature.
That’s where StrictJS Runtime comes in.

⚡ What is StrictJS Runtime?

StrictJS Runtime is an experimental, low-level JavaScript runtime powered by WebAssembly (WASM). Its goal is simple but ambitious:
Bring strict typing, predictable memory behavior, and high performance into JavaScript—without leaving the ecosystem. �
Libraries.io

Think of it as a hybrid approach:

🦀 Rust-like safety
⚡ C-like performance
🌐 JavaScript flexibility

Why JavaScript Needs Something Like This

JavaScript wasn’t designed for strict memory control or type safety.
Some common issues:

1. Dynamic typing → hidden bugs
2. Garbage collection → unpredictable performance
1. Flexible structures → runtime errors These problems become critical in:
Games
AI / ML workloads
Financial systems
Real-time applications

StrictJS Runtime tackles this by introducing typed, structured data running inside a WebAssembly core. �
Libraries.io
🧠 Core Idea: Strict Structures in JavaScript
Instead of relying on loose objects and arrays, StrictJS gives you strict, *schema-based data structures.
*

Example: Strict Object

import strictInit from "strictjs-runtime";

const run = async () => {
  const { StrictObject } = await strictInit({});

  const userSchema = {
    id: "u32",
    name: "string",
    age: "u8",
    isActive: "bool",
    balance: "f64"
  };

  const user = new StrictObject(userSchema);

  user.setField("id", 123);
  user.setField("name", "Alice");

  console.log(user.getFieldAsString("name"));
};

run();

👉 This enforces structure at runtime—no more accidental type mismatches.

**Key Features

WebAssembly-Powered Performance**

StrictJS uses WASM under the hood for computation-heavy tasks.

Faster execution for numeric operations
Better performance for large datasets
Ideal for simulations and AI

2. Runtime Type Safety
Unlike TypeScript (which is compile-time only), StrictJS enforces types at runtime.

Unlike TypeScript (which is compile-time only), StrictJS enforces types at runtime.

Prevent invalid assignments
Reduce production bugs
Catch issues early

3. Strict Memory Control
You get predictable data handling:

Fixed-size arrays
Typed memory layouts
No unexpected resizing

4. Cross-Platform Compatibility

Runs anywhere JavaScript runs:

Browser
Node.js
React Native
Even TensorFlow.js integrations �
Libraries.io

**
🧩 Core APIs
StrictArray**

const arr = new StrictArray(HeapType.U8, 3);
arr.set(0, 10);
console.log(arr.get(0)); // 10

StrictFunction

const multiply = new StrictFunction(
  (a, b) => a * b,
  ["u8", "u8"],
  "u8"
);

console.log(multiply.call([5, 6])); // 30

These APIs bring low-level control into high-level JavaScript.

🧪 Real-World Use Cases
StrictJS Runtime shines in areas where performance + safety matter:

🎮 Game engines
📊 Data processing pipelines
💹 Trading systems
🤖 AI / ML workloads
🧠 Simulation systems

⚠️ Current Status (Be Real About It)
StrictJS Runtime is still experimental:

APIs may change
Not production-ready for all use cases
Best for learning, experimentation, and advanced tooling � Libraries.io That said—it’s a very interesting direction for JavaScript evolution.

The Bigger Vision
StrictJS isn’t just a runtime.
It could evolve into:

A full framework
A new programming model
Or even a compiled language targeting strict JavaScript ~~"Wherever JavaScript runs, StrictJS can run too.” � Libraries.io~~

💡 My Take
StrictJS Runtime is one of those projects that makes you rethink JavaScript entirely.
It challenges the idea that:

~~“JavaScript must always be dynamic and loose.”~~

Instead, it asks: 👉 What if JavaScript could be strict, predictable, and still flexible?

📦 Getting Started
Install it:

npm install strictjs-runtime

Explore more here:
👉 Check StrictJS Runtime on npm⁠�

✍️ Final Thoughts
If you’re a developer who:
Loves performance
Wants safer JavaScript
Or is curious about WebAssembly
Then StrictJS Runtime is worth exploring.
It may not replace your current stack today—but it might shape how we write JavaScript tomorrow.

StrictJS

Dr Codewell — Sun, 25 Jan 2026 09:30:02 +0000

StrictJS Part 1: Rethinking Numbers and Strings in JavaScript

JavaScript is one of the most successful programming languages ever created.
It runs everywhere, scales from small scripts to massive systems, and powers the modern web.

But its success came with a trade-off.

Over the years, we’ve normalized silent coercions, implicit conversions, and runtime surprises as “just how JavaScript works.” We write defensive code, add endless checks, and hope bugs don’t surface in production.

StrictJS is my attempt to step back and ask a simple question:

What if JavaScript values actually meant what they said?

In this first post, I’ll start at the foundation: numbers and strings.

The Problem With JavaScript Numbers

JavaScript has only one numeric type: Number.

That decision simplified the language early on, but it also introduced behavior that most developers eventually learn to work around instead of trust.

Consider this:

"5" + 1   // "51"
"5" - 1   // 4
0.1 + 0.2 // 0.30000000000000004

None of these are bugs. They are design decisions.

But they also mean:

Values silently change meaning
Types lie about intent
Errors show up late, not early

In real systems—financial calculations, counters, async pipelines—this is dangerous.

StrictJS does not try to “fix” JavaScript.
It simply refuses to guess.

Strict Numbers in StrictJS

In StrictJS, a number is not just a value.
It is a contract.

Core principles:

No implicit coercion
Explicit creation only
Operations fail fast
Intent matters more than convenience

Example:

const a = StrictNumber(5)
const b = StrictNumber("5") // ❌ Error

If something is a string, it stays a string.
If something is a number, it behaves like one.

Operations are explicit:

a.add(1)        // ✅ StrictNumber(6)
a.add("1")      // ❌ Type error

This might feel strict at first—but that’s the point.

I would rather see an error while writing code than debug it months later in production.

Why This Matters in Real Systems

Silent numeric coercion doesn’t usually break small demos.
It breaks long-lived systems.

Financial calculations drift
Counters misreport
API boundaries blur
Async pipelines amplify small mistakes

Strict numbers move these failures to the surface, where they belong.

Early errors are cheaper than late surprises.

The Problem With JavaScript Strings

Strings in JavaScript often pretend to be something else.

"5" == 5        // true
"true" == true // false

Strings cross system boundaries:

User input
JSON payloads
Network responses

Yet JavaScript frequently treats them as almost numbers, almost booleans, or almost anything.

In practice, this leads to ambiguity.

A string that looks like data is not data.

Strict Strings in StrictJS

In StrictJS, a string is always just a string.

No automatic casting.
No silent parsing.
No assumptions.

const name = StrictString("Kenneth")
const age  = StrictString("25")

age + 1        // ❌ Error
age.toNumber() // ✅ Explicit conversion

Parsing is not an accident.
It is a decision.

By forcing explicit conversion, StrictJS makes intent visible in code. When someone reads it months later, there is no ambiguity about what is happening.

JavaScript vs StrictJS (Quick Comparison)

Operation	JavaScript	StrictJS
`"5" + 1`	`"51"`	❌ Error
`"5" - 1`	`4`	❌ Error
`0.1 + 0.2`	Precision loss	Explicit handling
String → Number	Implicit	Explicit only

StrictJS doesn’t try to be clever.
It tries to be honest.

What’s Next

This post only covers the foundation.

In the next parts, I’ll dive into:

Strict booleans
Strict objects and schemas
Async execution with guarantees
Memory-aware JavaScript

StrictJS is not about replacing JavaScript.

It’s about disciplining it—bringing back clarity, intent, and trust in our code.

"Acquire Proficiency in JavaScript Code Integration Through the Development of a Task Manager Application."

Dr Codewell — Sun, 10 Sep 2023 13:55:30 +0000