Zustand does not have a built-in concept of async actions. An action is a function in the store, and a function can be async. That is the entire mechanism. The action calls await on a promise, then calls set with the result. Zustand does not intercept the promise, does not track its state, and does…
Reading state is passive. The component subscribes, and the store notifies it when something changes. Updating state is active: a function in the store receives new data and calls set to merge that data into the existing state. The set function is the only legitimate way to modify a Zustand store, and the way it…
Reading state in Zustand is not a single operation. It is a decision about subscription granularity. Every call to the store hook creates a subscription, and the selector passed to that hook determines exactly which changes trigger a re-render. A component that selects a single number re-renders only when that number changes. A component that…
A Zustand store is only as good as the subscriptions that read from it. A store can hold a hundred values, but if a component subscribes to the entire object, it re-renders on every change regardless of which value it actually uses. The selector is what makes Zustand efficient. It extracts a specific slice of…
Zustand is a state management library built on a single premise: state should be accessible without ceremony. Where Redux requires a provider wrapping the application, reducers, and action creators, and React Context requires a provider and careful memoization to avoid re-rendering every consumer, Zustand requires one function call. You install the package, call create, and…
The previous chapter established what a bridge is: a software switch that forwards frames between ports based on a learned MAC address table. This chapter is the operational sequence. Creating a bridge is a single command; making it work correctly requires a specific order of operations, and making it persist requires the correct configuration for…
A Linux bridge is a software switch. It connects two or more network interfaces at Layer 2, forwarding Ethernet frames between them based on MAC addresses, not IP addresses. The bridge itself becomes a logical interface—typically br0—that carries an IP address, while the physical interfaces attached to it become ports, stripped of their own addresses…
The previous chapter established the routing policy database and the rule selectors that drive it. This chapter is the operational counterpart: creating custom routing tables, populating them with routes, writing rules that direct specific traffic to them, and ensuring the entire configuration survives a reboot. A single policy rule is a proof of concept. A…
Classic routing makes a decision based solely on the destination address. A packet arrives, the kernel searches its routing table for the longest matching prefix, and forwards the packet accordingly. This model assumes that every packet destined for the same network should follow the same path. Policy routing breaks that assumption. It allows the administrator…
The default gateway is the route of last resort. When the kernel examines a packet’s destination and finds no matching entry in the routing table, it forwards the packet to the default gateway. This single route is what connects a host or a local network to everything beyond its directly attached subnets. Without it, the…