State

/reɪs kənˈdɪʃən/

noun — "outcome depends on timing, not logic."

Race Condition is a concurrency error that occurs when the behavior or final state of a system depends on the relative timing or interleaving of multiple executing threads or processes accessing shared resources. In a race condition, two or more execution paths “race” to read or modify shared data, and the result varies depending on which one happens to run first. This makes the system nondeterministic: the same code, given the same inputs, may produce different results across executions.

Technically, a race condition arises when three conditions are present simultaneously. First, multiple execution units run concurrently. Second, they share mutable state, such as memory, files, or hardware registers. Third, access to that shared state is not properly coordinated using synchronization mechanisms. When these conditions align, operations that were assumed to be logically atomic are instead split into smaller steps that can interleave unpredictably.

A classic example is incrementing a shared counter. The operation “counter = counter + 1” is not a single indivisible action at the machine level. It involves reading the current value, adding 1, and writing the result back. If two threads perform this sequence concurrently without synchronization, both may read the same initial value and overwrite each other’s updates, resulting in a lost increment.

# conceptual sequence without synchronization
Thread A reads counter = 10
Thread B reads counter = 10
Thread A writes counter = 11
Thread B writes counter = 11   # one increment lost

From the system’s perspective, nothing illegal occurred. Each instruction executed correctly. The error emerges only at the semantic level, where the intended invariant “each increment increases the counter by 1” is violated. This is why race conditions are particularly dangerous: they often escape detection during testing and appear only under specific timing, load, or hardware conditions.

Race conditions are not limited to memory. They can occur with file systems, network sockets, hardware devices, or any shared external resource. For example, two processes checking whether a file exists before creating it may both observe that the file is absent and then both attempt to create it, leading to corruption or failure. This class of bug is sometimes called a time-of-check to time-of-use (TOCTOU) race.

Preventing a race condition requires enforcing ordering or exclusivity. This is typically achieved using synchronization primitives such as mutexes, semaphores, or atomic operations. These tools ensure that critical sections of code execute as if they were indivisible, even though they may involve multiple low-level instructions. In well-designed systems, synchronization also establishes memory visibility guarantees, ensuring that updates made by one execution context are observed consistently by others.

However, eliminating race conditions is not just about adding locks everywhere. Over-synchronization can reduce concurrency and harm performance, while incorrect lock ordering can introduce deadlocks. Effective design minimizes shared mutable state, favors immutability where possible, and clearly defines ownership of resources. Many modern programming models encourage message passing or functional paradigms precisely because they reduce the surface area for race conditions.

Conceptually, a race condition is like two people editing the same document at the same time without coordination. Each person acts rationally, but the final document depends on whose changes happen to be saved last. The problem is not intent or correctness of individual actions, but the absence of rules governing their interaction.

See Synchronization, Mutex, Thread, Deadlock.

/ˈkɒnˌtɛkst/

n. “Sharing state without prop-drilling chaos.”

Context in React is an API that allows data to be passed through the component tree without manually passing props at every level. It is designed to solve the problem of “prop-drilling,” where intermediate components receive props only to pass them down to deeper components that actually need the data.

At a high level, the Context API consists of three key parts: React.createContext(), the Provider component, and the useContext hook (or Context.Consumer in class components). The Provider wraps a tree of components and supplies a value, while useContext allows nested components to access that value directly.

For example, in a themeable application, you might create a ThemeContext that provides the current color scheme. Any component can then call const theme = useContext(ThemeContext) to access the theme, eliminating the need to pass theme props through multiple intermediate components.

Context is not meant to replace Redux, React-Redux, or other state management libraries for complex global state. Instead, it excels at lightweight, app-wide concerns like theming, localization, user authentication info, or feature flags.

One important consideration is performance: updating a Context value will cause all consuming components to re-render. In larger applications, it’s common to separate contexts or memoize values to avoid unnecessary renders.

Combined with hooks and functional components, Context provides a clean, declarative way to manage shared state. Components remain unaware of the full tree structure, focus on rendering, and rely on Context for their dependencies. This keeps code maintainable and avoids the boilerplate of prop-drilling.

Essentially, Context is a bridge for global or semi-global state, giving React developers a standardized, testable, and efficient way to share data across the component tree without cluttering the interface with endless props.

/ˈriːˌdʌks/

n. “Predictable state. Fewer surprises.”

Redux is a state management library for JavaScript applications, most commonly used with React. Its core purpose is to centralize application state, making it predictable, traceable, and easier to debug. In complex applications, juggling state across multiple components can quickly become chaotic — Redux offers a structured solution.

At its heart, Redux revolves around three principles: a single source of truth, state is read-only, and changes are made with pure functions called reducers. All application state lives in a single store object. Components read from the store, and the only way to change state is by dispatching actions that reducers handle.

Example usage: imagine a shopping cart application. Instead of managing the cart state across multiple components independently, the cart’s contents, totals, and checkout status are all stored in the Redux store. When a user adds an item, an ADD_ITEM action is dispatched, the reducer updates the state, and any subscribed component automatically reflects the change.

Redux solves several common problems: eliminating state duplication, making state transitions predictable, and enabling powerful tools like time-travel debugging. Developers can inspect the entire state tree, replay actions, and identify exactly when and why a bug occurred.

Middleware is another powerful feature of Redux. Libraries like Redux Thunk or Redux Saga allow asynchronous operations like API calls to be integrated into the state flow without breaking the core principle of predictability.

Beyond React, Redux can be used with other frameworks or even vanilla JavaScript, though its popularity surged alongside React. When combined with React-Redux, the connection between the store and React components becomes seamless via hooks like useSelector and useDispatch.

While some modern React patterns, such as Context API with hooks, can replace Redux for simpler applications, Redux remains invaluable for large-scale apps with complex state interactions, asynchronous flows, or requirements for detailed debugging.

In essence, Redux is the map of your app’s state landscape: clear, predictable, and traceable. It turns chaotic, scattered component state into a single source of truth, helping developers understand, maintain, and scale applications without surprises.