Skip to main content

Svelte 5 Migration: Refactoring Complex RxJS Stores to Runes ($state)

 

The Hook

You are migrating a large-scale Svelte 4 application to Svelte 5. You have heavily relied on RxJS BehaviorSubjects or complex observable chains to manage asynchronous state (websockets, search typeaheads, complex data modeling).

In Svelte 4, the auto-subscription syntax ($store) made RxJS interoperability seamless. In Svelte 5, however, the paradigm shifts to Runes ($state, $derived). Attempting to mix the push-based nature of RxJS with the pull-based, granular reactivity of Runes often results in "reactivity gaps"—where the UI fails to update because the Signal graph doesn't realize the Observable stream has emitted a new value.

The Why: Signal Graph vs. Event Stream

The fundamental issue lies in how Svelte 5 tracks dependencies.

  1. Svelte 4 (Compiled Reactivity): The $ prefix was compiler sugar. It generated code to .subscribe() to the store and trigger a component invalidate on every emission.
  2. Svelte 5 (Runtime Signals): Runes rely on a runtime dependency graph. When a component renders, it "listens" to the specific $state signals accessed during that render.

RxJS Observables are opaque to this signal graph. When a BehaviorSubject emits .next(), it happens outside Svelte's tracking scope. Unless you explicitly mutate a $state proxy or trigger a signal, Svelte 5 components will not re-render.

We need a bridge: a mechanism that subscribes to the Observable and synchronously mutates a $state rune, effectively piping the "Push" (RxJS) into the "Pull" (Svelte Runes).

The Fix

We will implement a clean architecture pattern I call the Reactive Service Bridge. We will create a utility to bind Observables to Runes, and then implement a robust Service class that keeps business logic in RxJS while exposing Svelte-native Runes to the view.

Step 1: The fromObservable Primitive

First, we need a reusable primitive. While Svelte provides fromStore, it is often insufficient for strictly typed RxJS streams where initial values and error handling are critical.

Create src/lib/runes/rx.ts:

import { Observable } from 'rxjs';
import { onDestroy } from 'svelte';

/**
 * Consumes an RxJS Observable and mirrors it into a readonly signal property.
 * Automatically handles subscription cleanup.
 */
export function fromObservable<T>(obs$: Observable<T>, initialValue: T) {
  let value = $state(initialValue);

  const sub = obs$.subscribe({
    next: (v) => {
      value = v;
    },
    error: (err) => {
      console.error('RxJS Stream Error:', err);
    }
  });

  // Cleanup when the context (component or effect root) is destroyed
  onDestroy(() => {
    sub.unsubscribe();
  });

  return {
    get current() {
      return value;
    }
  };
}

Step 2: The Service Refactor

Let's assume a complex scenario: A live cryptocurrency ticker that filters data based on user input.

Legacy Svelte 4 Approach (Mental Model): You likely had a writable for the filter and a derived store that piped into an RxJS switchMap.

Modern Svelte 5 Approach: We keep the RxJS complexity private and expose simple $state fields.

Create src/lib/services/crypto-service.svelte.ts:

import { 
  BehaviorSubject, 
  combineLatest, 
  switchMap, 
  timer, 
  map, 
  distinctUntilChanged 
} from 'rxjs';
import { fromObservable } from '../runes/rx';

export interface PriceData {
  symbol: string;
  price: number;
  timestamp: number;
}

export class CryptoService {
  // 1. INPUT: Native Svelte State
  // We use standard runes for inputs the UI controls directly.
  filter = $state('BTC');
  
  // 2. INTERNAL: The Bridge
  // Private BehaviorSubject to ingest state changes into the RxJS pipeline
  private filter$ = new BehaviorSubject<string>('BTC');

  // 3. INTERNAL: The RxJS Pipeline
  // Complex async logic stays in RxJS land (debouncing, polling, merging)
  private pipeline$ = this.filter$.pipe(
    distinctUntilChanged(),
    switchMap(symbol => 
      // Simulate polling a WebSocket or API every second
      timer(0, 1000).pipe(
        map(i => ({
          symbol: symbol.toUpperCase(),
          price: 10000 + (Math.random() * 500), // Mock data
          timestamp: Date.now()
        }))
      )
    )
  );

  // 4. OUTPUT: The Rune wrapper
  // We initialize the rune wrapper with a safe default
  private _liveData = fromObservable<PriceData | null>(this.pipeline$, null);

  constructor() {
    // 5. GLUE: Sync Rune changes to Observable Stream
    // $effect tracks 'this.filter' and pushes to Subject
    $effect.root(() => {
      $effect(() => {
        this.filter$.next(this.filter);
      });
    });
  }

  // Public Getters
  get data() {
    return this._liveData.current;
  }
}

// Singleton instance (optional, depending on architecture)
export const cryptoService = new CryptoService();

Step 3: The Component Usage

The component becomes incredibly dumb. It reads properties and writes to properties. It knows nothing about Observables, subscriptions, or $ syntax.

src/routes/+page.svelte:

<script lang="ts">
  import { cryptoService } from '$lib/services/crypto-service.svelte';

  // Format helper
  const fmt = new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' });
</script>

<div class="dashboard">
  <h1>Market Watch</h1>

  <!-- Two-way binding works natively with the class property -->
  <div class="controls">
    <label>
      Filter Symbol:
      <input type="text" bind:value={cryptoService.filter} placeholder="e.g. ETH" />
    </label>
  </div>

  <div class="ticker">
    {#if cryptoService.data}
      <div class="card">
        <h2>{cryptoService.data.symbol}</h2>
        <p class="price">{fmt.format(cryptoService.data.price)}</p>
        <span class="meta">Last Update: {new Date(cryptoService.data.timestamp).toLocaleTimeString()}</span>
      </div>
    {:else}
      <p>Initializing stream...</p>
    {/if}
  </div>
</div>

<style>
  .dashboard { font-family: sans-serif; max-width: 600px; margin: 2rem auto; }
  .card { border: 1px solid #333; padding: 1.5rem; border-radius: 8px; margin-top: 1rem; }
  .price { font-size: 2rem; font-weight: bold; color: #4ade80; }
  input { padding: 0.5rem; font-size: 1rem; }
</style>

The Explanation

1. The Reactivity Boundary

We established a clear boundary. Inside CryptoService, RxJS handles the "Time" dimension (handling sequences of events, cancellation via switchMap, intervals). Outside, Svelte handles the "State" dimension (current value snapshot).

2. The $effect Glue

Inside the constructor, we use $effect:

$effect(() => {
  this.filter$.next(this.filter);
});

When bind:value={cryptoService.filter} updates in the component, Svelte's runtime detects the mutation. It triggers the effect, which pushes the new string into the RxJS BehaviorSubject. This wakes up the Observable pipeline.

Note on $effect.root: In Svelte 5, if you instantiate a class with effects outside of a component initialization phase (like a global singleton), the effects might not register or clean up correctly. Wrapping it in $effect.root ensures the scope is managed, though for pure singletons, you might simply allow the effect to run forever.

3. The fromObservable Wrapper

Our utility function creates a closure containing a $state variable. The subscribe callback mutates this local state. Crucially, the returned object exposes a getter.

get current() { return value; }

When the component reads cryptoService.data, it hits this getter. Svelte records that the component depends on the value signal. When RxJS pushes a new value, value is updated, notifying Svelte to re-render the component.

Conclusion

You do not need to rewrite your complex RxJS business logic to migrate to Svelte 5. You simply need to wrap it. By treating RxJS as your "backend for the frontend" and Runes as the "view model," you get the best of both worlds: the stream processing power of RxJS and the granular, boilerplateless performance of Svelte 5 Runes.

Labels: