Derived stateful classes

[HugeLetters]

Is there an idiomatic way to do this? basically i have state, then I have some derived state but it's not pure - it's stateful too.
here's a basic example

class Counter {
	counter = $state(0);
}

class CounterWithAdded {
	counter = $state(0);

	sum;
	constructor(props: { add: number }) {
		this.sum = $derived(this.counter + props.add);
	}
}

const a = new Counter();

// no, this will reset internal counter every time
const c1 = $derived(new CounterWithAdded({ add: a.counter }));

// recommended approach but wieldy when you have several options like that
const c2 = new CounterWithAdded({
	get add() {
		return a.counter;
	},
});

// works and less verbose when a lot of properties probably but feels icky
class AddProps {
	add = $derived(a.counter);
}
const c3 = new CounterWithAdded(new AddProps());

as for the real use case - we're a bank and we have a lot of functions built around svelte 4 stores where a function sets up a bunch of state, and then reused by other functions which derive from its state but declare its own state too and so on. when migrating this to runes - it's not very clear whats a nice, clean solution

it may look like this

function userCardsStore() {
	const cards = writable([]);

	return { cards };
}

function userCreditCardsStore() {
	const creditStatus = writable('new');

	const cards = userCardsStore();
	const creditCards = derived(cards.cards, ($cards) => $cards.filter(isCredit));

	function updateCreditStatus() {
		if (get(creditCards).length === 0) {
			creditStatus.set('empty');
		} else {
			creditStatus.set('with-cards');
		}
	}

	return {
		creditCards,
		creditStatus,
		updateCreditStatus,
	};
}

assume creditStatus cannot just be a derived and since it needs creditCards, we can't just split these stores - it kinda has to be a stateful derived. And it's a big app so we can't be changing the logic much here so of course ideally there should be a straightfoward way to move store code to rune code.

I guess the 4th option is to introduce some Rune type { current: T} - akin to what fromStore returns and use that instead of Readable/Writable everywhere

This probably has been asked before but kinda hard to search for

This is a duplicate question from Discord: https://discord.com/channels/457912077277855764/1489264519468552294

[MukundaKatta]

Your c2 pattern (passing a get add() accessor) is actually the idiomatic answer — but you can dress it up so it stops feeling icky when you have many inputs. A few techniques that scale well:

1. Let the constructor take "reactive inputs" as functions

Instead of reading this.counter + props.add directly, treat the inputs as thunks. The callsite gets clean at the cost of one tiny unwrap in the class:

type Reactive<T> = () => T

class CounterWithAdded {
  counter = $state(0)
  #addFn: Reactive<number>

  constructor(opts: { add: Reactive<number> }) {
    this.#addFn = opts.add
    this.sum = $derived(this.counter + this.#addFn())
  }

  sum: number
}

const a = new Counter()

const c = new CounterWithAdded({
  add: () => a.counter, // no getter boilerplate, still reactive
})

Arrow functions are cheap to write, the reactive graph still correctly subscribes to a.counter (because the $derived evaluates this.#addFn() which reads it), and you're not instantiating an extra class.

2. A tiny helper for "bag of reactive inputs"

If you have a lot of these, make the thunk-to-getter conversion a utility so the class stays ergonomic:

function reactify<T extends Record<string, () => unknown>>(thunks: T) {
  const bag = {} as { [K in keyof T]: ReturnType<T[K]> }
  for (const k of Object.keys(thunks) as (keyof T)[]) {
    Object.defineProperty(bag, k, { get: thunks[k], enumerable: true })
  }
  return bag
}

// usage
const c = new CounterWithAdded(reactify({
  add: () => a.counter,
  multiplier: () => someOther.value,
  name: () => user.fullName,
}))

Now props.add inside the class is a plain property read that happens to be reactive, so your class body reads like boring, un-reactive code. For your bank-store migration this is probably the sweetest spot — store code typically has ~5–10 inputs per layer, and this keeps every layer a plain class definition.

3. For the store-factory pattern, compose classes, not functions

Your Svelte-4 example is literally a function returning a bag of stores. In runes land the direct translation is a class returning a bag of $state fields, and layered stores become classes that accept the lower-layer class as a constructor arg:

class UserCardsStore {
  cards = $state<Card[]>([])
}

class UserCreditCardsStore {
  creditStatus = $state<'new' | 'active' | 'blocked'>('new')
  #base: UserCardsStore
  creditCards: Card[]

  constructor(base: UserCardsStore) {
    this.#base = base
    this.creditCards = $derived(this.#base.cards.filter((c) => c.type === 'credit'))
  }
}

const user = new UserCardsStore()
const credit = new UserCreditCardsStore(user)

• $state is the instance field: each new gets its own cards. No "resets on rerender" surprises because you only call new once, not inside a $derived like your c1 example.
• $derived on an instance field reads the base class's $state transparently — no getter boilerplate, because classes already expose fields as implicit getters/setters.
• No reactify() needed here because you're passing the base class instance, not individual values. That's the key change from your current approach: pass the owning class, not its fields.

Your c1 failure (const c1 = $derived(new CounterWithAdded(...))) is the "don't construct inside a derived" pitfall — every time a.counter changes, the derived re-runs, which calls new, which wipes internal state. That's working as designed; the fix is either (1) "pass the owning instance" as in this last pattern, or (2) "pass reactive thunks" as in patterns 1–2.

Rule of thumb

• If one class owns another class's full lifecycle (like "credit cards derive from cards"), pass the instance.
• If one class just consumes a few reactive values from unrelated sources, pass thunks (or { get … }, same thing — thunks are just less verbose).
• Avoid $derived(new Foo(...)); it always resets.

That's the whole design space in the runes model. Once the team internalises "pass instances for ownership, pass thunks for loose inputs," the Svelte-4 store-composition shapes migrate without getting ugly.