Introduction to Reactive Programming

Picture a typical web application—say, an online store.

• A user clicks a button (to view product details).
• The application must send a request to a slow server and wait for the response.
• Only once the response arrives can it update the page.

1. The Core Problem: Why “Reactive” at All?

The classic (imperative) model: The application blocks while waiting for the response. Inefficient! It’s like ordering at a restaurant and then physically holding onto the waiter until your food is ready. In the meantime, he can’t serve anyone else.

The reactive solution: The application tells the server: “Send me the data when it’s ready. I won’t wait here, but I’ll leave you my phone number. Call me back when you have something.” Meanwhile, it can handle other tasks.

2. The Core Principle: Asynchronous Data Streams

Reactive Programming centers on two key ideas:

1. Asynchronicity: Tasks run in the background. The main program doesn’t block or wait for results.
2. Data streams: Everything can be treated as a sequence of events: mouse clicks, keyboard input, HTTP requests, database results, and so on. These streams can be generated, transformed, filtered, and combined.

3. The Analogy: The Subscription Model (Magazine vs. YouTube)

To grasp reactive thinking, compare two approaches:

	Imperative (Pull Model)	Reactive (Push Model)
Analogy	Buying a magazine	Subscribing to a YouTube channel
Action	You go to the newsstand and actively ask for the latest issue. (Pull)	You click “Subscribe.” (Push)
Future	You have to return to the newsstand next week to get the new issue.	You get a notification as soon as a new video is uploaded.
Benefit	You get what you want immediately.	You never miss anything and don’t have to keep checking. Content comes to you.

Reactive Programming follows the subscription model (Push principle). You subscribe to a data source and get notified whenever new data becomes available.

4. The Key Players: Observer and Observable

This abstraction appears in nearly all reactive frameworks (like RxJava, Project Reactor).

• Observable (or Publisher):

  • What is it? The data source. It produces a stream of events or data.
  • Examples: A button (produces click events), a sensor (produces measurements), a server response.
  • Responsibility: It keeps track of who’s interested in its data (its “subscribers”).

• Observer (or Subscriber):

  • What is it? The data consumer. It’s interested in the Observable’s data.
  • Examples: The function handling a click; the logic evaluating a sensor reading.
  • Responsibility: It subscribes to an Observable. It must handle three different types of notifications.

5. The Three Callbacks: How the Observer Responds

The Observer tells the Observable what to do for each event by implementing three methods:

1. onNext(T value)

   • When? Called when the Observable emits a new data element.
   • What to do? Process the received element (e.g., display products, log the sensor reading).
   • YouTube analogy: A new video was uploaded.

2. onError(Throwable error)

   • When? Called if an error occurs.
   • What to do? Handle the error (e.g., show an error message to the user, retry).
   • YouTube analogy: An error occurred while uploading the video.

3. onComplete()

   • When? Called when the Observable will send no more data. The stream is finished.
   • What to do? Clean up.
   • YouTube analogy: The YouTuber deleted their channel. No more videos will ever come.

6. A Code Example (Conceptual)

Imagine we want to log every mouse click on a webpage.

Imperative Approach (Pseudocode)

// We actively poll (PULL)
while (true) {
  if (mouseWasClicked()) { // Blocks until a click arrives!
    const clickEvent = getClickEvent(); // Fetches the click
    console.log('Click at: ', clickEvent.position);
  }
}
// Problem: The entire loop blocks and just waits for clicks.

Reactive Approach (Pseudocode with RxJS)

// We subscribe to the click data source (PUSH)
fromEvent(document, 'click') // Creates an Observable from click events
  .subscribe(                // Subscribe and define callbacks
    (clickEvent) => {        // onNext: What happens for each click
      console.log('Click at: ', clickEvent.clientX, clickEvent.clientY);
    },
    (error) => {             // onError: What happens on error
      console.error('Something went wrong: ', error);
    },
    () => {                  // onComplete: What happens at the end (never called here, since clicks never stop)
      console.log('No more clicks. Goodbye!');
    }
  );
// Benefit: The main thread is not blocked and can do other things.
// The callback is only invoked when an event actually arrives.

7. Why Is This So Powerful? Operators!

The real strength lies in manipulating these data streams with operators, much like map, filter, reduce in functional programming.

• filter: Let only certain events through. (E.g., clicks only within a specific div)
• map: Transform events. (E.g., convert a click event into {x: 10, y: 20})
• debounceTime: “Debounce” events. (E.g., process only the last click in a rapid click sequence—perfect for search fields!)
• merge: Combine multiple streams. (E.g., clicks and keyboard input into a single stream)

fromEvent(document, 'click')
  .pipe(
    filter(event => event.target.id === 'myButton'), // Only clicks on #myButton
    debounceTime(250),                               // Wait 250ms between clicks
    map(event => { return {x: event.clientX, y: event.clientY}; }) // Transform the event
  )
  .subscribe(coord => console.log('Clicked at: ', coord));

Summary

• Reactive Programming is a paradigm for non-blocking, asynchronous processing of data streams.
• It follows the push or subscription model: The data consumer (Observer) subscribes to a data source (Observable).
• The Observer responds to three types of events: new data (onNext), errors (onError), and completion (onComplete).
• Operators (like filter, map) enable elegant transformation and combination of data streams.
• Benefits: Better resource utilization (no blocking), elegant handling of asynchronous events, easier composition of complex workflows.