$mol state behaves like a spreadsheet: you declare how a value is computed, and everything that depends on it updates by itself. No stores, no dispatch, no effect hooks — the dependency graph tracks what to recompute.
A method decorated with @ $mol_mem is a cached, reactive cell. It runs once, remembers its result, and recomputes only when something it read has changed.1namespace $.$${2export class $my_counterextends$.$my_counter{3@ $mol_memcount(){return 0}45@ $mol_memdoubled(){6return this.count()*27}8}9}doubled reads count, so it subscribes to count automatically. Change count and every view showing doubled refreshes — there is nothing to subscribe to by hand.
A property is both getter and setter: call it with no argument to read, with an argument to write.1@ $mol_action2increment(){3this.count(this.count()+1)4}
This one distinction keeps reactive code predictable:@ $mol_mem is a pure computation — only read other cells and return a value.@ $mol_action is an effect — writes to state, network calls, and timers belong here.Writing to a cell from inside a @ $mol_mem creates a feedback loop (the write invalidates a dependency, which recomputes, which writes again). $mol reports this as a circular subscription. The fix is always the same: keep side effects in actions, keep computations pure.In @ $mol_mem you maybut notButton handlers are generated as @ $mol_mem on the base class; override them with @ $mol_action so they can write safely:1@ $mol_action2submit(){3this.saved(true)4}
