---

C# Reactive Programming: From Zero to Spreadsheet Hero

Discover the power of C# reactive programming by building a system where data flows automatically. Learn to create input and compute cells that dynamically update, mimicking spreadsheet logic, and eliminate manual state management for good.

---

You’ve been there before. You’re building a complex user interface or a data dashboard in C#. A user changes a value in one input field, and suddenly, five other labels, two chart points, and a summary total all need to be updated. Your code quickly becomes a tangled mess of event handlers, manual updates, and brittle logic. One small change breaks the entire chain, and debugging feels like untangling a ball of yarn in the dark.

This frustrating, error-prone process is a classic sign of imperative programming hitting its limits. You are manually commanding every single update, step-by-step. But what if there was a better way? What if you could simply declare the relationships between your data points and let the system handle the updates automatically, just like a spreadsheet recalculates a formula when you change a cell?

This is the promise of reactive programming. In this comprehensive guide, we will deconstruct this powerful paradigm from the ground up. You will learn not just the theory but also how to implement your own basic reactive system in C#, a core skill featured in the kodikra C# learning path. By the end, you'll be able to build more robust, maintainable, and elegant applications that react to change, rather than being commanded by it.

---

What is Reactive Programming?

Reactive programming is a declarative programming paradigm centered around data streams and the propagation of change. Instead of writing a sequence of commands to execute, you model your system as a network of interconnected data sources. When one piece of data changes, the change automatically flows through the network, updating all dependent components.

The most intuitive analogy is a spreadsheet:

• Input Cells: These are cells where you manually enter a value (e.g., A1 = 10). In our system, these are called InputCell objects.
• Compute Cells: These cells contain formulas that depend on other cells (e.g., C1 = A1 + B1). In our system, these are ComputeCell objects.

When you change the value in cell A1, the value in C1 updates instantly without any extra command from you. You simply declared the relationship (C1's value is the sum of A1 and B1), and the spreadsheet engine handles the propagation. Reactive programming brings this powerful, declarative model to general-purpose programming in languages like C#.

Core Concepts Explained

• Observable: Represents a source of data that can be "watched." In our case, every cell is an observable. It emits a notification whenever its value changes.
• Observer: A component that "watches" an observable. When the observable emits a change, the observer reacts to it. A ComputeCell acts as an observer to its dependency cells.
• Dependency Graph: The network of relationships between cells. An InputCell is a root node, and ComputeCell objects are nodes that depend on others. Changes propagate through this graph.

---

Why is a Reactive System Essential in Modern C#?

While you can write any application without explicitly using a reactive model, adopting this paradigm unlocks significant benefits, especially as application complexity grows. It's not just an academic concept; it’s a practical solution to common software engineering problems.

Simplifying Complex State Management

Modern applications, from desktop GUIs with WPF or .NET MAUI to web frontends with Blazor, are all about managing state. User interactions, API responses, and background processes all modify the application's state. Synchronizing the UI with this state is a major source of bugs. A reactive system centralizes state logic, making dependencies explicit and updates automatic, drastically reducing boilerplate code and potential for human error.

Enhancing Asynchronous Programming

C# has excellent asynchronous support with async/await, but managing multiple concurrent data streams can still be tricky. Reactive programming, especially with libraries like Reactive Extensions (Rx.NET), treats events—mouse clicks, API responses, timer ticks—as data streams. This allows you to compose, filter, and transform these asynchronous events with the same ease as working with collections using LINQ.

Improving Code Readability and Maintainability

Imperative code often hides the "why" behind the "how." You see a list of commands but have to mentally reconstruct the underlying data flow. Reactive code, being declarative, makes the relationships between data components the central focus. This makes the system's logic easier to understand at a glance and simpler to modify or extend without causing unintended side effects.

---

How to Design Our Reactive System in C#

To build our system, we need to model the core components: a generic concept of a "cell," a specific type for user inputs, and another for computed values. We'll rely on fundamental C# features like events, delegates (Func), and generics to make our system flexible and type-safe.

The Component Blueprint

1. Cell<T> (Abstract Base Class): This will be the foundation. It will define the common interface for all cells: a Value property and an event to notify subscribers of changes. We make it abstract because a "cell" on its own doesn't have a behavior; it must be either an input or a compute cell.
2. InputCell<T>: This class represents a root of the dependency graph. It inherits from Cell<T> and has a public setter for its Value property. When the value is set, it fires the change notification event.
3. ComputeCell<T>: The heart of the system. It also inherits from Cell<T>. Its value is determined by a computation function (a Func) that takes the values of other cells (its dependencies) as input. It subscribes to the change events of its dependencies. When any dependency changes, it re-evaluates its own value and, if the new value is different, fires its own change event, propagating the update.
4. Callbacks: We need a way for external code to react to changes in a ComputeCell. We'll add a mechanism to register callback actions that are invoked whenever the cell's value is updated.

Data Propagation Flow

Understanding the flow of data is critical. A change in an InputCell triggers a cascading effect through the dependency graph. This diagram illustrates the propagation.

  ● User Sets Value
  │
  ▼
┌─────────────────┐
│ InputCell.Value │
│   is changed    │
└────────┬────────┘
         │ Fires 'ValueChanged' Event
         ▼
┌─────────────────┐
│ ComputeCell A   │  ←───┐
│  (Depends on    │      │
│   InputCell)    │      │
└────────┬────────┘      │
         │ Re-computes & Fires Event
         ▼
┌─────────────────┐
│ ComputeCell B   │
│  (Depends on    │
│   ComputeCell A)│
└────────┬────────┘
         │ Re-computes & Fires Event
         ▼
    ◆ Any Callbacks?
   ╱           ╲
 Yes            No
  │              │
  ▼              ▼
[Invoke Callback] [End of Chain]

This chain reaction ensures that the entire system remains in a consistent state automatically. The key is the event subscription model: each ComputeCell is an observer of its dependencies.

---

The Complete C# Solution

Here is the full implementation based on the design from the exclusive kodikra.com curriculum. The code is structured into the abstract Cell class and its two concrete implementations, InputCell and ComputeCell. Pay close attention to the use of generics, events, and delegates.

using System;
using System.Collections.Generic;
using System.Linq;

// Custom EventArgs to hold the new value when an event is fired.
public class ValueChangedEventArgs<T> : EventArgs
{
    public T NewValue { get; }

    public ValueChangedEventArgs(T newValue)
    {
        NewValue = newValue;
    }
}

// Abstract base class for all cell types.
public abstract class Cell<T>
{
    // Event that fires when the cell's value changes.
    public event EventHandler<ValueChangedEventArgs<T>> ValueChanged;

    private T _value;

    // The current value of the cell.
    public virtual T Value
    {
        get => _value;
        protected set
        {
            // Only update and notify if the new value is different.
            if (!EqualityComparer<T>.Default.Equals(_value, value))
            {
                _value = value;
                OnValueChanged(new ValueChangedEventArgs<T>(_value));
            }
        }
    }

    protected Cell(T initialValue)
    {
        _value = initialValue;
    }

    // Method to raise the ValueChanged event.
    protected virtual void OnValueChanged(ValueChangedEventArgs<T> e)
    {
        ValueChanged?.Invoke(this, e);
    }
}

// Represents a cell whose value can be set directly by the user.
public class InputCell<T> : Cell<T>
{
    // Public setter allows external code to change the value.
    public override T Value
    {
        get => base.Value;
        set => base.Value = value;
    }

    public InputCell(T initialValue) : base(initialValue) { }
}


// Represents a cell whose value is computed based on other cells.
public class ComputeCell<T> : Cell<T>
{
    private readonly Func<T> _computeFunc;
    private readonly List<object> _dependencies; // Store dependencies to manage subscriptions
    private readonly List<Action<T>> _callbacks = new List<Action<T>>();

    // We override the base Value property to prevent direct setting.
    public override T Value
    {
        get => base.Value;
        protected set => base.Value = value;
    }

    // Constructor for a compute cell with one dependency.
    public ComputeCell(Cell<T> dependency, Func<T, T> compute)
        : this(new object[] { dependency }, () => compute(dependency.Value))
    {
    }

    // Constructor for a compute cell with two dependencies.
    public ComputeCell(Cell<T> dep1, Cell<T> dep2, Func<T, T, T> compute)
        : this(new object[] { dep1, dep2 }, () => compute(dep1.Value, dep2.Value))
    {
    }
    
    // Private generic constructor to handle dependency subscription.
    private ComputeCell(IEnumerable<object> dependencies, Func<T> compute)
        : base(default(T)) // Initialize with default, then compute
    {
        _dependencies = dependencies.ToList();
        _computeFunc = compute;

        // Subscribe to the ValueChanged event of all dependencies.
        foreach (var dep in _dependencies)
        {
            // Use reflection to attach the event handler generically.
            var valueChangedEvent = dep.GetType().GetEvent("ValueChanged");
            if (valueChangedEvent != null)
            {
                var handler = (Action<object, EventArgs>)((sender, args) => UpdateValue());
                var delegateHandler = Delegate.CreateDelegate(valueChangedEvent.EventHandlerType, handler.Target, handler.Method);
                valueChangedEvent.AddEventHandler(dep, delegateHandler);
            }
        }

        // Compute the initial value.
        UpdateValue();
    }

    // Recalculates the cell's value and triggers notifications if it changed.
    private void UpdateValue()
    {
        T newValue = _computeFunc();
        this.Value = newValue; // The setter in Cell<T> handles the change check
    }
    
    // Override OnValueChanged to also trigger registered callbacks.
    protected override void OnValueChanged(ValueChangedEventArgs<T> e)
    {
        base.OnValueChanged(e);
        // Execute all registered callbacks with the new value.
        foreach (var callback in _callbacks)
        {
            callback(e.NewValue);
        }
    }

    // Public method to add a callback.
    public void AddCallback(Action<T> callback)
    {
        _callbacks.Add(callback);
    }

    // Public method to remove a callback.
    public void RemoveCallback(Action<T> callback)
    {
        _callbacks.Remove(callback);
    }
}

---

Detailed Code Walkthrough

Let's dissect the solution to understand the role of each part. A solid grasp of these mechanics is essential for mastering this topic in the Kodikra C# curriculum.

1. Cell<T> - The Abstract Foundation

This class establishes the contract for all cells.

• Generics <T>: By using generics, our reactive system can work with any data type (int, string, custom objects, etc.), making it highly reusable.
• ValueChanged Event: This is the core notification mechanism. It uses the standard EventHandler<TEventArgs> pattern. We created a custom ValueChangedEventArgs<T> to pass the new value to subscribers, which is more efficient than having them query the sender again.
• Virtual Value Property: The property has a public getter but a protected setter. This means only the class itself or its descendants (InputCell, ComputeCell) can change the value. The setter contains crucial logic: it only raises the ValueChanged event if the new value is actually different from the old one. This prevents unnecessary re-computations and infinite loops in the dependency graph.

2. InputCell<T> - The Data Source

This class is remarkably simple, and that's by design. Its only job is to provide a public entry point for data into the reactive system.

• public override T Value: It overrides the base Value property to expose the setter publicly. When you write myInputCell.Value = 10;, you are invoking the base class's setter logic, which checks for a change and fires the ValueChanged event.

3. ComputeCell<T> - The Reactive Engine

This is where the magic happens.

• Constructors and _computeFunc: The constructors are designed for convenience, accepting one or two dependencies and a corresponding Func delegate. For example, Func<T, T, T> is a function that takes two arguments of type T and returns a value of type T. All constructors ultimately call a private, more generic constructor. This private constructor stores the computation logic in the _computeFunc field.
• Dependency Subscription: In the private constructor, it iterates through its dependencies. It uses C# reflection (dep.GetType().GetEvent("ValueChanged")) to find the ValueChanged event on each dependency, regardless of its specific generic type. It then dynamically creates a delegate and subscribes its own UpdateValue() method to that event. This is the crucial link: when a dependency changes, UpdateValue() gets called.
• UpdateValue() Method: This private method is the reaction. It calls the stored _computeFunc() to get the new value and then assigns it to its own Value property. This assignment triggers the base setter logic, which in turn fires this cell's own ValueChanged event, continuing the propagation chain.
• Callbacks: The AddCallback and RemoveCallback methods manage a list of Action<T> delegates. The overridden OnValueChanged method ensures that after notifying other dependent cells, it also executes these external callbacks, allowing the rest of your application to react to the final computed value.

Event Subscription and Callback Mechanism

This diagram illustrates how a ComputeCell subscribes to its dependencies and how external code registers a callback to listen for the final result.

    ● ComputeCell Creation
    │
    ▼
  ┌──────────────────┐
  │  Constructor     │
  │   (Receives      │
  │    Dependencies) │
  └────────┬─────────┘
           │ Subscribes to...
           ├───────────────────► ┌───────────────┐
           │                     │ Dependency A's  │
           │                     │ ValueChanged  │
           │                     └───────────────┘
           └───────────────────► ┌───────────────┐
                                 │ Dependency B's  │
                                 │ ValueChanged  │
                                 └───────────────┘
    ● External Code
    │
    ▼
  ┌──────────────────┐
  │ Calls            │
  │ AddCallback(myAction) │
  └────────┬─────────┘
           │ Registers 'myAction'
           ▼
  ┌──────────────────┐
  │ ComputeCell      │
  │   (Callback List)│
  └────────┬─────────┘
           │ When its own value changes...
           ▼
     ● Invokes 'myAction'

---

Pros & Cons / Potential Risks

No programming paradigm is a silver bullet. While reactive programming is powerful, it's important to understand its trade-offs and potential pitfalls before adopting it for a large-scale project.

Pros (Advantages)	Cons (Risks & Disadvantages)
Declarative & Readable: Code focuses on the "what" (the relationships) not the "how" (the update steps), making complex state logic easier to reason about.	Debugging Complexity: The flow of control is inverted. Instead of a linear call stack, you have chains of events. A bug can be hard to trace back to its source, often referred to as "callback hell".
Reduced Boilerplate: Eliminates manual update logic, event wiring, and state synchronization code, leading to cleaner and more concise applications.	Memory Leaks: A common issue is the "lapsed listener" problem. If a ComputeCell is no longer needed but hasn't been unsubscribed from its dependencies, it won't be garbage collected, creating a memory leak. Our simple implementation lacks a `Dispose` method for cleanup.
Automatic Consistency: The system ensures that all dependent values are always up-to-date, preventing inconsistent state bugs.	Circular Dependencies: If Cell A depends on B, and Cell B depends on A, a change to either will trigger an infinite loop of updates, resulting in a StackOverflowException. Our implementation does not detect this.
Excellent for UI & Async: Naturally fits event-driven environments like user interfaces and simplifies the composition of asynchronous data streams.	Performance Overhead: For very simple cases, the overhead of creating cell objects, delegates, and managing subscriptions can be slower than a direct, imperative update. The benefits shine with complexity.

---

When to Build Your Own vs. Using a Library

Implementing a reactive system from scratch, as we've done in this kodikra module, is an invaluable learning experience. It forces you to understand the underlying mechanics of events, delegates, and data flow. For educational purposes or small, contained problems, this approach is perfect.

However, for production applications, it is almost always better to use a mature, well-tested library. The premier library for reactive programming in .NET is Reactive Extensions (Rx.NET).

Use a library like Rx.NET when:

• You are building a production-grade application.
• You need advanced features like throttling, debouncing, merging, or filtering data streams.
• You require robust error handling and stream completion semantics.
• You need to manage scheduler and thread affinity for UI updates.
• You want a solution that is heavily optimized for performance and memory usage.

Think of this exercise as learning how a car engine works by building a simple one. You wouldn't use that simple engine to race, but the knowledge makes you a much better driver and mechanic when using a high-performance, production-ready one.

---

Frequently Asked Questions (FAQ)

What is the main difference between reactive and imperative programming?

Imperative programming is about control. You write a series of commands: "do this, then do that." You are responsible for every step. Reactive programming is about flow. You declare relationships between data sources and let the system automatically propagate changes through that flow. It's a shift from "how to do it" to "what it is."

How would you handle circular dependencies in this reactive system?

Our current implementation would crash with a StackOverflowException. A robust solution requires detection. One common strategy is to track the "computation stack" during an update. When a cell begins to compute, it adds itself to a global stack. If it finds itself already on the stack during a computation, a circular dependency has been detected, and an exception can be thrown immediately with a clear error message.

Is this implementation thread-safe?

No, this implementation is not thread-safe. If two threads tried to set the value of two different InputCell objects that feed into the same ComputeCell at the same time, you could have race conditions during the update propagation. A thread-safe version would require using locks (e.g., lock statements) or other synchronization primitives around value updates and event invocations.

How does this relate to the Observer design pattern?

Reactive programming is essentially a more advanced and formalized application of the Observer design pattern. In the classic Observer pattern, a "Subject" (our Cell) maintains a list of "Observers" (our other ComputeCells). When the Subject's state changes, it notifies all its Observers. Reactive programming builds on this with powerful compositional operators and a focus on data streams.

What is the "glitch problem" in reactive programming?

The "glitch problem" occurs when a node in the dependency graph receives updates from its dependencies out of order, causing it to compute a temporary, incorrect ("glitchy") value. For example, if C = A + B, and both A and B change, C might recompute after hearing from A but before hearing from B. More advanced reactive systems solve this using transactional updates or topological sorting of the dependency graph to ensure nodes are only computed once all their dependencies have settled.

Why use a Func<T> delegate instead of just passing a method name?

Using a Func<T> delegate provides immense flexibility. It allows the creator of the ComputeCell to define the computation logic on the fly using a lambda expression (e.g., () => dep1.Value + dep2.Value). This decouples the ComputeCell from any specific class or method, making it a truly generic and reusable component.

Can this system be extended with more complex operations?

Absolutely. The foundation is solid. You could create new types of ComputeCells that handle more complex scenarios, such as combining streams, filtering values, or introducing time-based operations like delays or buffers. This is where libraries like Rx.NET truly excel, providing a rich vocabulary of such operators out of the box.

---

Conclusion & Next Steps

You have successfully journeyed from the core theory of reactive programming to a hands-on implementation in C#. You've built a system that embodies the "spreadsheet" model of data flow, where changes propagate automatically through a network of dependent cells. This declarative approach is a powerful tool for taming complexity in modern, event-driven applications, leading to code that is more maintainable, readable, and less prone to state-related bugs.

The concepts you've mastered here—delegates, events, generics, and dependency graphs—are fundamental to advanced C# development. While you might reach for a powerful library like Rx.NET in your next production project, the deep understanding you've gained from building this system from scratch will make you a more effective and insightful developer.

Ready to tackle the next challenge? Continue your journey on the C# Learning Path or explore our comprehensive C# guides to further sharpen your skills.

Disclaimer: The code and concepts in this article are based on modern C# and the .NET 8 ecosystem. While the core principles are timeless, specific syntax and library features may evolve in future versions.

---

Published by Kodikra — Your trusted Csharp learning resource.