DEV Community: Yuriy Artamonov

State hoisting without Compose: an Anki-style app with Flowik and Vaadin

Yuriy Artamonov — Sun, 01 Nov 2026 18:12:27 +0000

In the first post I introduced Flowik, a small MobX-style state library for JVM UIs.

Today I built something with real state in it: an Anki-style flashcard app on Vaadin Flow. Decks, cards, a study loop with Anki's SM-2 scheduler, undo, daily limits, a card browser. And along the way I ended up borrowing the one idea from Jetpack Compose I like most — state hoisting — for a UI toolkit that has never heard of it.

This post is about why those two ideas, derived state and hoisted state, fit together so well.

Why Anki is a good test

Spaced repetition looks simple. You see a question, you reveal the answer, you rate yourself: Again, Hard, Good or Easy. The card comes back in ten minutes, or in four days, or in three months.

The state behind it is not simple at all. Every deck shows three counts — New, Learn, Due — and each of them depends on:

the schedule of every card in the deck,
what you already studied today, because of the daily limits,
the deck's own limits, which you can edit,
and the clock. A learning card due in ten minutes is not due now.

Answer one card and the counts on three screens are wrong. Undo it and they are wrong again. This is exactly the kind of state that, done the traditional way, ends up as a web of listeners that nobody dares to touch.

Derive, don't sync

There is no list of due cards anywhere in the app. Nothing adds a card to a "learning" queue or removes it from a "review" one. The queues are a computed:

val queues: Computed<Map<Long, DeckQueue>> = computed {
    val today = today
    val doneToday = log.items.filter { localDate(it.time, zone) == today }
    val cardsByDeck = cards.items.groupBy { it.deckId }
    decks.items.associate { deck ->
        deck.id to buildQueue(deck, cardsByDeck[deck.id].orEmpty(), doneToday.filter { it.card.deckId == deck.id })
    }
}

buildQueue is plain Kotlin: group the deck's cards by state, sort, cut to the limits, pick the next card — learning cards that are due first, then the most overdue reviews, then new cards. It reads card schedules, deck limits, the review log and the clock, and Flowik records every one of those reads.

So answering is just this:

fun answer(card: ObservableEntity<Card>, answer: Answer) = action {
    val before = card[Card::schedule]
    card[Card::schedule] = scheduler.answer(before, answer, now, zone)
    log.add(ReviewEntry(card, now, answer, before))
    tick()
}

Write the new schedule, append to the log, read the clock. Every count on every screen follows, because every count was derived from those three things. Undo is the same in reverse: put the old schedule back, drop the log entry. Nobody has to remember which counters to fix.

The scheduler itself is a pure function from a schedule and a time to a new schedule. It has no idea a UI exists, which made it the easiest part of the app to test.

State down, events up

The other half is the one I want to talk about, because it changed how the components look.

In Compose, a well-behaved composable doesn't own the state it shows. It receives values and reports events through lambdas — "state flows down, events flow up". The state lives with whoever actually needs it, usually higher up the tree.

The Vaadin version looks almost the same. Here is the deck overview — the screen with the three counts and the Study Now button:

class DeckOverview(
    deck: ObservableEntity<Deck>,
    queue: Supplier<DeckQueue>,
    onStudy: () -> Unit,
    onBack: () -> Unit,
    onAddCards: () -> Unit,
    onBrowse: () -> Unit,
    onOptions: () -> Unit
) : Div(), Bindings by Bindings() {
    init {
        val due = Div(stats, studyNow).apply {
            visible { !queue.get().isFinished }
        }
        val finished = register(Congratulations(queue, onBack)).apply {
            visible { queue.get().isFinished }
        }
        // …
    }
}

It doesn't know there is a store. It doesn't know where Study Now leads. It shows a deck and a queue, and it says when a button was pressed.

There is one difference from Compose, and it is the interesting part. A composable function is called again whenever its inputs change, so it can take a plain DeckQueue. A Vaadin component is built once. If I passed it a DeckQueue value, it would show the counts as they were when the screen opened, forever.

So the state goes down as a Supplier<DeckQueue> — a way to read the queue — and the component reads it inside its bindings. visible { !queue.get().isFinished } is a reaction: Flowik sees which observables queue.get() touched and re-runs it when any of them change. The reactivity travels through the lambda. The component stays stateless, and it is still live.

That is the whole trick, and I find it rather elegant: hoisting in Compose relies on recomposition; here it relies on auto-tracking, and the component code reads the same.

One class knows the store

If components only take state and callbacks, somebody has to hand them out. In the app that is AnkiView, the routed page, and it is the only class that ever sees AnkiStore:

is Screen.Study -> StudyScreen(
    deck = screen.deck,
    queue = { store.queueOf(screen.deck) },
    resume = screen.resume,
    intervalLabels = store::intervalLabels,
    canUndo = store::canUndo,
    onAnswer = store::answer,
    onUndo = store::undo,
    onEdit = ::openEditCard,
    onForget = store::forgetCard,
    onDelete = store::deleteCard,
    onBack = { store.showOverview(screen.deck) },
    onDecks = store::showDecks
)

Read it as a wiring diagram. Property references like store::canUndo convert to suppliers, so most of it is one line per input. Events map onto store actions. The view also opens the dialogs, so they are wired the same way.

Navigation is one more atom: the view switches its content on store.screen with childSwitch, and the screen it leaves is disposed with all its bindings. Going somewhere is writing a value.

Not everything goes up

My first version of this had the store hold the study session too: the current card, whether its answer was showing, the labels on the answer buttons. It worked. It was also wrong, and it took me
a while to see why.

Compose has a precise rule for this: hoist state to the lowest common ancestor of everything that reads it — no higher. Who reads "the answer is showing"? The study screen. Nobody else. The store
only held it because answer() took no card and fished the current one out of its own state.

So the session moved into the screen:

private var answerShown by observable(false, name = "answerShown")

/** Shown before the queue's pick until it is answered — the card an undo brought back. */
private var pinned by observableRef(resume, name = "pinned")

private val card = register(computedRef { pinned ?: queue.get().next })

private val answerLabels by computed { card.value?.let(intervalLabels).orEmpty() }

The card on screen is derived, locally, from local state and the hoisted queue. computedRef notifies only when a different card comes up, not every time the queue is recomputed, so the card
face isn't rebuilt for nothing. Showing the answer never leaves the component. Answering does:

private fun answer(answer: Answer) {
    val current = card.value ?: return
    if (!answerShown) return
    answerShown = false
    pinned = null
    onAnswer(current, answer)
}

The screen resets its own state and reports which card was rated. Rescheduling is the store's business. Until the store does it, the screen keeps showing the same card — which is precisely what
happens when a learning card is the only one left and comes straight back.

The store got smaller and more honest: decks, cards, the log, the clock, and which screen is showing. Things more than one screen cares about.

Dialogs report, they don't write

Dialogs follow the same rule. The card editor edits through a buffer —
createViewModel(card), which reads through to the card until you type — but it never writes the
card itself:

Button("Save") {
    onSave(form[Card::front], form[Card::back])
    close()
}

Cancel needs no code at all: the buffer is simply dropped.

Validation is derived like everything else. The "create deck" dialog takes a way to ask whether a name is taken, and the error message, the invalid state and the button all follow one computed:

private val deckName by observable("", name = "deckName")
private val nameError by computed {
    deckName.trim().takeIf(isNameTaken)?.let { "A deck named '$it' already exists." }
}

private val name = TextField("Deck name").apply {
    value(::deckName.asObservable())
    errorMessage(::nameError)
}

isNameTaken reads the store's decks, so the check is as reactive as everything else — but the dialog doesn't know that. It just calls a function it was given.

Testing without a store

This is where hoisting pays for itself. A component that only takes state and callbacks can be built in a test from a couple of observables. No store, no scheduler, no Spring:

val current = observableRef(queue(cat, dog))
val answers = mutableListOf<Pair<String, Answer>>()
val screen = StudyScreen(
    deck = deck,
    queue = current,
    resume = null,
    intervalLabels = { mapOf(Answer.GOOD to "10m") },
    canUndo = { false },
    onAnswer = { card, answer -> answers += card[Card::front] to answer },
    // the remaining callbacks are no-ops
)

shown(screen, "anki-show-answer").single().simulateClick()
shown(screen, "anki-answer-good").single().simulateClick()
assertEquals(listOf("cat" to Answer.GOOD), answers)

action { current.value = queue(dog) }
assertEquals("dog", shown(screen, "anki-card-front").single().element.text)

The test plays the store: it hands the screen a queue, checks what gets reported, then moves the queue on by itself. It checks both halves of the contract — the screen shows what it's given, and it reports instead of acting.

The honest part

It isn't completely free.

Parameter lists get long. StudyScreen takes twelve arguments. Named arguments keep the call site readable, and I prefer an explicit list to a component quietly reaching into a store, but it is not pretty.
A supplier must be read inside a binding. Call queue.get() once in init, outside any reaction, and you have a snapshot that will never update. The types don't catch it.
Time is an atom I tick by hand. The clock moves on every action and navigation, not on its own, so a card due in ten minutes doesn't appear while you stare at the screen. A proper observable clock is on my list.
Every deck's queue is recomputed when any card changes. Fine for a few hundred cards; a computed per deck would be better, and Flowik doesn't have that yet.

Try it

The app is in the repo under
flowik-vaadin-demo/.../anki:

./gradlew :flowik-vaadin-demo:bootRun
# then open http://localhost:8080/anki

Press Next day in the top bar to time-travel and watch tomorrow's reviews fall due.

What I like most about this approach is how little each piece knows. The scheduler doesn't know there is a UI. The screens don't know there is a store. The store doesn't know there is Vaadin. And the counts are right everywhere, because nobody is responsible for keeping them right.

Source: github.com/jreznot/flowik

Better JetBrains Marketplace screenshots for every plugin

Yuriy Artamonov — Fri, 30 Oct 2026 19:44:35 +0000

The media section is the first thing people see on a JetBrains Marketplace plugin page. It's also where most plugins look their worst: full-screen IDE captures shrunk to carousel size, unreadable 13px text, desktop wallpaper around the window, and every screenshot a different size.

The good-looking ones are usually composed slides. A short headline sits on a tinted background next to a cropped, zoomed-in IDE window, and one thing on screen is highlighted. Making those by hand in a design tool takes a while, and you redo all of it whenever the UI changes.

So I built mpshots. It's a small Node CLI. You give it your raw IDE screenshots and a YAML file, and it renders a consistent set of Marketplace slides.

Raw window capture…

…and the slide mpshots makes from it.

What it does

You describe each slide in a shots.yaml:

output:
  width: 1920
theme: dark
brand:
  name: Air
  accent: "#3574F0"
defaults:
  uiScale: 2              # Retina capture

slides:
  - id: accounts
    layout: hero
    headline: Bring your own agent and account
    body: Switch between JetBrains AI, a ChatGPT account or your own API key
    screenshot:
      src: screenshots/accounts.png
      crop: [574, 996, 1645, 720]          # x, y, w, h in source pixels
      highlight: [1561, 1256, 637, 413]    # draws an accent outline with a glow

Then run mpshots build. You get one PNG per slide, plus an index.html that shows them at about the size the Marketplace carousel uses.

There are four layouts:

text-left: text on the left, IDE window on the right running off the edge of the slide.
text-right: the mirror image of text-left.
hero: centred headline with a wide window below.
window: the window on its own, no text.

On any slide you can add highlights, which outline something on screen. You can also add an overlay, a second window floating on top, such as a browser preview next to the IDE.

Every slide uses the same logical 1920×1080 canvas, and output.width sets the pixel size: 1920, 2560 or 3840. Your set always comes out with one aspect ratio, which the Marketplace guidelines ask for.

Here's the full set for the Air plugin, all from one spec:

The checks

Laying out slides wasn't the hard part. The hard part was knowing whether a slide will still be readable once it's shrunk into the carousel. Before rendering anything, mpshots validate checks:

IDE text size: it estimates how big the IDE's 13px UI font ends up after your crop and zoom (13 × uiScale × zoom), and warns if it lands under 16px.
Upscaling: it warns if the screenshot has to be blown up more than 1.05×, because the result will look soft.
Copy length: headlines over 60 characters, body text over 240.
Hard errors: missing files, and crops or highlights that fall outside the image.

--strict turns warnings into failures, so you can run it in CI.

Building this taught me one thing: a 1920×1080 capture at 100% IDE zoom can't be both readable and sharp on a slide. To make the text big enough, you have to scale the capture up, and then it goes blurry. The fix is at capture time. Zoom the IDE to 125–150% (View › Appearance › Zoom IDE), or capture on a Retina display, and set uiScale to match. The Air screenshots above are 2800×1800 Retina window captures. They pass both checks without being scaled up.

Finding crop coordinates

Nobody wants to guess pixel rectangles. mpshots grid draws a labelled pixel grid over a capture so you can read off [x, y, w, h] directly:

mpshots grid screenshots/accounts.png
# → screenshots/accounts.grid.png

How it renders

There's no headless browser. Layout is done by satori, which turns flexbox-style elements into SVG. resvg turns that SVG into pixels, and sharp handles crops and resampling. Each screenshot is resampled once, with Lanczos, straight to the final output size. A slide takes about two to three seconds. It runs anywhere Node 18 does, CI included.

Try it

It installs straight from GitHub:

npm i -g github:jreznot/mpshots#v0.1.0
mpshots init      # creates shots.yaml and screenshots/
mpshots build

The repo includes two complete examples: a set built from generated mock IDE screens, and the Air set above from real captures. Clone it and run mpshots build in examples/air to see the whole pipeline.

Next I'd like to remove the manual capture step. An IDE action could save a clean window capture at a known zoom and write the crop rectangles for you.

Issues and PRs are welcome: github.com/jreznot/mpshots.

Dive into MobX with Flowik: how auto-tracking works

Yuriy Artamonov — Wed, 28 Oct 2026 20:07:31 +0000

In the first post I introduced Flowik, a MobX-style state library for Swing and Vaadin. Its pitch fits in one sentence: reading is subscribing. You read count.value inside an autoRun, and the autoRun re-runs when count changes. There is no subscribe() call anywhere.

The first time you see this it looks like magic. It isn't. The whole mechanism is a stack, a couple of sets and a counter, and it fits in about a hundred lines of Kotlin.

In this post we will build a toy version from scratch in three steps: observables with autoRun, then computed, then action. After that we will open Flowik's real Tracking.kt and see what changes when the toy has to survive a real UI. If you already use MobX in JavaScript, this is also a tour of what MobX does under the hood.

The picture in your head: a dependency graph

Every MobX-style app is a graph with three kinds of nodes:

Observables: the source state. They are mutable and know who reads them.
Computeds: values derived from other nodes. They are cached, and they are both readers and things being read.
Reactions (autoRun in Flowik): the leaves, where effects happen, such as updating a label.

flowchart LR
    subgraph S["Observable state"]
        F(["firstName"])
        L(["lastName"])
        A(["age"])
    end
    subgraph D["Derivations"]
        N["fullName<br/><i>computed</i>"]
        R1{{"autoRun:<br/>update header label"}}
        R2{{"autoRun:<br/>update age field"}}
    end
    F --> N
    L --> N
    N --> R1
    A --> R2
    classDef obs fill:#e7f1fb,stroke:#3b78c4,color:#10243e
    classDef comp fill:#efedff,stroke:#6b5bd2,color:#1d1640
    classDef react fill:#e5f4e4,stroke:#3d8c40,color:#12300f
    class F,L,A obs
    class N comp
    class R1,R2 react

Arrows point the way changes flow. Change age and only the age field updates. Change firstName and the header updates, while the age field is left alone.

The interesting part is that you never draw this graph. Nobody writes "fullName depends on firstName". The library discovers each arrow at runtime, by watching what each derivation reads while it runs. Let's build the machinery that does that.

Step 1: who is reading right now?

The whole trick is one piece of global state: a stack of derivations that are currently running. When an observable is read, it looks at the top of that stack and adds whoever is there to its observers.

interface Derivation {
    fun onDependencyChanged()
}

object Tracking {
    private val stack = ArrayDeque<Derivation>()

    val current: Derivation? get() = stack.lastOrNull()

    fun <T> track(derivation: Derivation, block: () -> T): T {
        stack.addLast(derivation)
        try {
            return block()
        } finally {
            stack.removeLast()
        }
    }
}

It is a stack rather than a single variable because derivations nest: a reaction reads a computed, which runs its own function while the reaction is still running.

An observable is a value plus a set of observers. The getter records the current reader. The setter notifies everyone, but only if the value really changed:

class Observable<T>(initial: T) {
    private var _value = initial
    private val observers = mutableSetOf<Derivation>()

    var value: T
        get() {
            Tracking.current?.let { observers += it }   // reading is subscribing
            return _value
        }
        set(newValue) {
            if (newValue == _value) return
            _value = newValue
            observers.toList().forEach { it.onDependencyChanged() }
        }
}

And an autoRun simply runs its effect inside Tracking.track, and runs it again whenever told that something changed:

class AutoRun(private val effect: () -> Unit) : Derivation {
    fun run() = Tracking.track(this, effect)
    override fun onDependencyChanged() = run()
}

fun autoRun(effect: () -> Unit) = AutoRun(effect).also { it.run() }

That's it. Let's try it:

val count = Observable(0)
autoRun { println("count = ${count.value}") }   // count = 0
count.value = 1                                  // count = 1
count.value = 1                                  // nothing: the value did not change

Here is what happened during that first run:

sequenceDiagram
    autonumber
    participant R as autoRun
    participant T as Tracking stack
    participant O as count (observable)
    R->>T: push(this)
    R->>O: read count.value
    O->>T: who is reading? current
    T-->>O: the autoRun
    Note over O: observers += autoRun
    O-->>R: 0
    R->>T: pop()
    Note over O: later: count.value = 1
    O->>R: notify, run() again

Notice that the subscription is a side effect of reading. That is why dependencies can be conditional. In autoRun { if (showDetails.value) println(details.value) }, the reaction only depends on details while showDetails is true. Our toy doesn't handle the other half of that yet, which is forgetting old dependencies. We'll come back to it.

Step 2: computed, the node with two faces

A computed sits in the middle of the graph, so it plays both roles. To its readers it looks like an observable: reading it records the current derivation. To its inputs it looks like a derivation: it evaluates its function inside Tracking.track(this, ...).

class Computed<T>(private val compute: () -> T) : Derivation {
    private var cached: T? = null
    private var dirty = true
    private val observers = mutableSetOf<Derivation>()

    val value: T
        get() {
            Tracking.current?.let { observers += it }   // observable to its readers
            if (dirty) {
                cached = Tracking.track(this, compute) // a derivation to its inputs
                dirty = false
            }
            return cached as T
        }

    override fun onDependencyChanged() {
        if (dirty) return             // already stale, downstream already told
        dirty = true                  // push: mark stale, compute nothing
        observers.toList().forEach { it.onDependencyChanged() }
    }
}

fun <T> computed(compute: () -> T) = Computed(compute)

The key design choice is push invalidation, pull evaluation. When an input changes, the computed does not recompute. It only marks itself dirty and passes the news downstream. The actual work happens later, when someone reads value. If nobody reads it, it never runs.

sequenceDiagram
    participant A as firstName
    participant C as fullName (computed)
    participant R as autoRun
    Note over A: firstName.value = "Bob"
    A->>C: invalidate()
    Note over C: isDirty = true<br/>(nothing recomputed yet)
    C->>R: schedule
    R->>C: read fullName.value
    C->>A: recompute: read firstName
    A-->>C: "Bob"
    C-->>R: "Bob Smith"

val firstName = Observable("Alice")
val lastName = Observable("Smith")
var evaluations = 0
val fullName = computed { evaluations++; "${firstName.value} ${lastName.value}" }

autoRun { println("Hello, ${fullName.value}") }   // Hello, Alice Smith
firstName.value = "Bob"                             // Hello, Bob Smith
println(evaluations)                                // 2

Two evaluations for two distinct states. Add ten more readers of fullName and it still evaluates once per change. That is the caching MobX is known for.

Step 3: action, or "not yet, please"

Our toy has a problem. A user renames a person, so we write two fields:

firstName.value = "Carol"   // Hello, Carol Smith   <- a name that never existed
lastName.value = "Jones"    // Hello, Carol Jones

The reaction ran twice, and the first run showed a half-updated state. In a UI that is wasted work and sometimes a visible flicker.

The fix is a batch: a depth counter and a set of pending reactions. While the depth is above zero, reactions are queued instead of run. When the outermost batch ends, each queued reaction runs once. A LinkedHashSet keeps the order and removes duplicates for free.

object Batch {
    private var depth = 0
    private val pending = linkedSetOf<AutoRun>()

    fun schedule(autoRun: AutoRun) {
        if (depth > 0) pending += autoRun else autoRun.run()
    }

    fun <T> action(block: () -> T): T {
        depth++
        try {
            return block()
        } finally {
            if (--depth == 0) {
                val toRun = pending.toList()
                pending.clear()
                toRun.forEach { it.run() }
            }
        }
    }
}

fun <T> action(block: () -> T): T = Batch.action(block)

The only change elsewhere is one line in AutoRun: instead of running directly, it asks to be scheduled.

override fun onDependencyChanged() = Batch.schedule(this)

Now:

action {
    firstName.value = "Carol"
    lastName.value = "Jones"
}                              // Hello, Carol Jones  (once)

sequenceDiagram
    participant U as action { }
    participant T as Tracking
    participant O as observables
    participant R as autoRun
    U->>T: beginBatch() depth = 1
    U->>O: firstName = "Carol"
    O->>T: schedule(autoRun)
    Note over T: batching: add to pending set
    U->>O: lastName = "Jones"
    O->>T: schedule(autoRun)
    Note over T: already pending, set dedupes
    U->>T: endBatch() depth = 0
    T->>R: flush: run() once

The counter, rather than a boolean, lets actions nest. A store method that is an action can call another action, and nothing flushes until the outermost one ends.

The diamond: why batching is about correctness, not only speed

Here is a shape that appears constantly in real screens: one input, two derived values, one view that shows both.

flowchart LR
    A(["price"]) --> B["net<br/><i>computed</i>"]
    A --> C["tax<br/><i>computed</i>"]
    B --> R{{"autoRun:<br/>show net + tax"}}
    C --> R
    classDef obs fill:#e7f1fb,stroke:#3b78c4,color:#10243e
    classDef comp fill:#efedff,stroke:#6b5bd2,color:#1d1640
    classDef react fill:#e5f4e4,stroke:#3d8c40,color:#12300f
    class A obs
    class B,C comp
    class R react

val price = Observable(100)
val net = computed { price.value }
val tax = computed { price.value / 5 }
autoRun { println("net=${net.value} tax=${tax.value}") }   // net=100 tax=20

price.value = 200
// net=200 tax=20   <- glitch: tax is stale
// net=200 tax=40

Without a batch, price notifies net first. net schedules the autoRun, which runs immediately and reads tax. But tax has not been told about the change yet, so it returns its old cached value. Then tax is notified and the autoRun runs a second time. For a moment the screen showed a net price and a tax that never belonged together. In reactive systems this is called a glitch.

Inside an action the problem disappears. Both computeds are marked dirty before any reaction runs, so the single run sees a consistent world:

action { price.value = 300 }   // net=300 tax=60  (once)

MobX handles this by treating every write as a tiny batch of its own, and by tracking stale and ready counts on each node so that a reaction waits until all its inputs are settled. The practical rule for our toy, and for Flowik today, is simple: change state inside actions. That is good style anyway, because an action names the intent ("rename", "delete") and gives you one place to put it.

From toy to Flowik

Our toy is about 90 lines and already has the right shape. Open Flowik's Tracking.kt and you will recognise it immediately: a stack of Trackers, a batch depth and pending sets. What the real version adds is mostly about surviving a long-lived UI.

Concern	Toy	Flowik
Tracking context	One global stack	A `ThreadLocal` stack, so each thread has its own context. State is meant to be used from the UI thread.
Stale dependencies	Never forgotten	Before each re-run, `AutoRun` and `Computed` unsubscribe from all old dependencies, then re-subscribe to what they actually read
Reaction kinds	`autoRun` only	`autoRun`, `reaction(supply, effect)` and `whenThen`, each with its own pending queue
Change detection	`==`	`equals` by default, plus `observableRef` (identity), `observableStruct` (deep) or a custom comparer
Derived values that notify only on real change	Not possible	`computedStruct` / `computedRef`, refreshed at the end of a batch before reactions run
Errors	Exception escapes into the writer	Caught per reaction, passed to `onError` or logged; the reaction stays alive
Lifetime	Lives forever	`dispose()` stops a reaction and releases its subscriptions

A few details are worth reading in the source.

Batches end even when things throw. endBatch() refreshes derived values inside a try/finally, so a failing derivation can't leave the thread stuck in batching mode, where it would silently swallow every later reaction.

Derived values settle before reactions run. Policy-based computeds such as computedStruct have to evaluate to know whether they changed, and one refresh can invalidate another downstream. So flushRefreshes() loops until nothing is left, with a guard of 100 rounds to report a cycle instead of hanging. Only then are reactions flushed.

untracked is a stack swap. Reading without subscribing needs no special flags on observables. Flowik just replaces the stack with an empty one for the duration of the block:

fun <R> untracked(block: () -> R): R {
    val saved = stack.get()
    stack.set(ArrayDeque())
    return try {
        block()
    } finally {
        stack.set(saved)
    }
}

Errors are reported outside tracking. AutoRun.run() pops itself off the stack before calling the error handler, so whatever the handler reads does not become a dependency of the failed reaction.

Two ways to listen. Observer.kt is just a fun interface with onChange(). It is the explicit subscribe() channel, which the UI bindings and collections use to forward changes, for example from a list element up to its list. Auto-tracking and explicit subscription live side by side, and you rarely need the second one in application code.

Wrapping up

The "magic" of MobX comes down to three ideas:

A stack of who is running. Reading an observable subscribes whoever is on top.
Push invalidation, pull evaluation. Changes only mark things dirty; work happens when someone reads.
Batching. An action delays reactions until the state is consistent, then runs each one once.

Everything else (disposal, error handling, comparison policies, async loading) is engineering around those three. Once you have built the toy yourself, the real source stops being intimidating. Flowik's whole core is under 3,000 lines of Kotlin, and Tracking.kt is about 150 of them.

The complete toy from this post fits in a single file, so paste it into a scratch file and break it. Try making the observable setter wrap its notifications in action { } and watch the diamond glitch disappear.

Flowik on GitHub: jreznot/flowik
The gist of MobX

Flowik: MobX-style reactive state for Swing and Vaadin

Yuriy Artamonov — Wed, 28 Oct 2026 18:43:51 +0000

Why I wrote this

I have spent most of my career writing UIs on the JVM. For nine years I built ERP and OLTP systems with Vaadin and Swing: order entry, warehouse screens, master/detail forms with dozens of fields that depend on each other. Today I work at JetBrains on the IntelliJ Platform team, and the IDE is still, to a large extent, a Swing application.

Along the way I also wrote frontends in GWT and React, and I fell in love with functional programming. That mix left me with an itch. On the web, state management is a solved and widely discussed problem. On the JVM desktop and in server-side UI frameworks, most of us still wire things together by hand.

This post introduces Flowik, a small Kotlin library that brings MobX-style reactive state to Swing, Vaadin and the IntelliJ Platform.

The problem: listeners all the way down

If you have built a non-trivial Swing or Vaadin form, you know this code:

quantityField.addChangeListener { recalcTotal(); updateSaveButton() }
priceField.addChangeListener { recalcTotal(); updateSaveButton() }
discountCheckBox.addActionListener { recalcTotal(); updateDiscountRow(); updateSaveButton() }

Every derived thing on the screen (a total, an enabled flag, a label) needs someone to remember every source it depends on. Add a field and you hunt down every listener that should now also call recalcTotal(). Forget one and the UI shows stale data. Remove a panel and forget to unregister, and you leak it.

The dependency graph is real, but it lives only in your head and is scattered across addXxxListener calls. In an ERP screen with 40 fields it is the main source of bugs. In an IDE with hundreds of settings panels and tool windows, the same pattern repeats at scale.

React taught a generation of developers a different model: describe the UI as a function of state and let the framework keep it in sync. MobX took that one step further for state itself.

MobX in one paragraph

MobX sums itself up in one line:

Anything that can be derived from the application state should be derived. Automatically.

You mark some values as observable. You write derivations, which are plain functions that read them. MobX records which observables each derivation actually read while it ran, and re-runs it when, and only when, one of those changes. There is no subscription code and no dependency list to maintain. Reading is subscribing.

What appeals to me as a fan of functional programming is that your UI becomes close to a pure function of state, while the state itself stays ordinary mutable objects. You get most of the benefit of the functional model without forcing immutable data structures onto a 15-year-old domain model.

The second thing I realised is that none of this is JavaScript-specific. The tracking mechanism needs only a place to record "who is reading right now" and a way to batch writes. The project that convinced me was RomanPozdeev/MobX, a compact Kotlin implementation of observables, computed, autorun and action with property delegates. Seeing the whole idea fit into a small, readable Kotlin library showed me that MobX is very portable, and that the JVM UI world could have it too. Flowik grew from that starting point, with a focus on the toolkits I work with every day.

Meet Flowik

A Flowik app has two parts. The store is a plain Kotlin class that holds observables and computed values. The view only reads from the store. It never registers a listener.

import flowik.core.*

class CounterStore {
    val count = observable(0)
    val doubled = computed { count.value * 2 }

    fun inc() = action { count.value += 1 }
}

The store knows nothing about Swing or Vaadin. The same class drives both UIs below.

Swing

import flowik.core.*
import flowik.layout.uiFrame
import flowik.swing.*

fun main() {
    val store = CounterStore()
    val bindings = Bindings()

    uiFrame("Counter", width = 240, height = 120, bindings = bindings) {
        center {
            vbox(gap = 4) {
                Label { "Count: ${store.count.value} (×2 = ${store.doubled.value})" }
                Button("Increment") { store.inc() }
            }
        }
    }.disposeOnClose(bindings)
}

The Label lambda reads count and doubled, so it re-renders whenever either changes. That is the whole binding.

Vaadin Flow

@Route("counter")
class CounterView : VerticalLayout(), Bindings by Bindings() {
    private val store = CounterStore()

    init {
        val label = Span()
        label.text { "Count: ${store.count.value} (×2 = ${store.doubled.value})" }
        add(label, Button("Increment") { store.inc() })
        disposeOnDetach()
    }
}

You will notice Bindings in every example. It is the owner of the subscriptions a window, view or panel creates, so they can be released together. Flowik makes that lifetime explicit instead of guessing from attach and detach events, which in Vaadin also fire when a component is merely moved.

Building blocks

The core module, flowik-core, has no UI dependency. Its vocabulary will be familiar to anyone who has used MobX:

Block	Flowik API	What it does
Observable state	`observable`, `observables`, `observableSet`	Mutable values that track who reads them
Cached derivation	`computed { }`	A value derived from others, recomputed only when an input changes
Side effect	`autoRun { }`, `reaction`, `whenThen`	Code that re-runs when what it read changes, usually a UI update
Batch	`action { }`	Groups writes so derivations fire once, at the end

A short tour:

val name     = observable("Alice")
val greeting = computed { "Hello, ${name.value}" }

autoRun { println(greeting.value) }      // prints "Hello, Alice"

action {
    name.value = "Bob"
    name.value = "Carol"
}                                        // prints "Hello, Carol" once

Two things are worth noticing. The autoRun never says which values it depends on. And the action produced one update, not two, which matters a lot when a single user gesture touches ten fields of an order.

Kotlin helps make this pleasant. Observables work as property delegates (var name by observable("")), bindings accept property references (TextField(store::name)), and observable(person) turns each property of a data class into its own reactive atom, so a label showing only the name does not re-render when the age changes.

Where it pays off: screens with many parts

A counter proves nothing. The real test is whether you can split a large screen into small parts that know nothing about each other, and still have them stay in sync. That is exactly where my ERP screens used to rot.

The Vaadin demo contains a port of the master/detail page from the Vaadin docs' "Compose with Components" example: an employee list on the left, the selected person on the right, plus editing, adding and deleting. Its shape is:

EmployeeStore            the only place state changes
└── EmployeesView        the one stateful component: wires store → children
    ├── EmployeeMaster   search + list, owns no state
    │   └── EmployeeRow × N
    └── EmployeeDetail   tabs, manager card, Edit / Delete, owns no state

One store, state down, events up

The store is plain Kotlin. Its setters are private, so nothing writes state past it. The filtered list is a derivation, not something anyone updates:

@SpringComponent
@UIScope
class EmployeeStore : Store {
    val employees = observables(*sampleEmployees().toTypedArray())

    var search by observable("")
    var selected by observableRef<ObservableEntity<Employee>?>(null)

    val visibleEmployees by employees.filter { employee ->
        val query = search.trim().lowercase()
        query.isEmpty() || employee.fullName.lowercase().contains(query)
    }

    fun select(employee: ObservableEntity<Employee>?) = action { selected = employee }
    fun updateSearch(query: String) = action { search = query }
}

The route view hands each child the slices it shows and a callback for each event it raises:

class EmployeesView(private val store: EmployeeStore) : Div(), Bindings by Bindings() {
    init {
        add(
            register(EmployeeMaster(
                employees = store::visibleEmployees,   // a computed slice
                query = store::search,
                onQueryChange = store::updateSearch,
                selected = store::selected,
                onSelect = store::select,
                onAddNew = ::addNew,
            )),
            Div().apply {
                childSwitch(store::selected) { employee ->
                    if (employee == null) NoSelection() else detail(employee)
                }
            },
        )
        disposeOnDetach()
    }
}

EmployeeMaster and EmployeeDetail never reference the store or each other. Both follow store.selected, so clicking a row, adding a person and deleting one all move the detail pane the same way. There is no code that keeps the two panes in sync, because there is nothing to sync.

Why the parts stay small

Inputs are Supplier<T>, not framework types. EmployeeMaster takes a Supplier<List<ObservableEntity<Employee>>>. Every observable and computed is a Supplier, and so is any lambda that reads them. A caller can pass a store property, derive a value inline (isSelected = { selected.get() === employee }) or pass a constant, and the child cannot tell the difference. Tracking flows straight through the lambda.
Entities are live, and fine-grained. A row, a person card and the detail tabs all receive the same ObservableEntity<Employee>. Each field reads only the property it shows, so changing someone's phone number re-renders only the places that show the phone number, on every page that shows it.
Editing is a transaction. The editor dialog gets a buffered createViewModel(employee). Nothing reaches the model until submit(), so Cancel needs no code, and the same dialog creates a new person from a draft that joins the list only on Save.
Lifetimes follow the composition tree. Every part is Bindings by Bindings(). register(child), items { } and childSwitch { } dispose what they drop. Whoever creates a component owns it.

Derived state is shared the same way. The Teams and Locations pages are one generic GroupsView fed with store.groupedBy { ... }. Change someone's title on the Employees page and the Teams page regroups, with no code connecting the two pages.

Testable without a browser

Because a part depends only on suppliers and callbacks, and bindings run without a Vaadin UI, it can be tested in plain JUnit, with no store and no browser harness:

val people = observables(*sampleEmployees().take(3).toTypedArray())
val selected = observableRef<ObservableEntity<Employee>?>(null)

val master = EmployeeMaster(
    employees = people::items,
    query = { "" },
    onQueryChange = {},
    selected = selected,
    onSelect = { println("select ${it.fullName}") },
    onAddNew = {},
)

master.rows()[1].click()                      // only reported: the master does not select by itself
action { selected.value = people.items[1] }   // its owner does, and the row follows
assertTrue(master.rows()[1].hasClass("selected"))

This is the part I missed most in nine years of enterprise UIs. Flowik lets you design the state (fine-grained entities, derived slices, edit buffers) and hand it to components that do not know where it comes from. The more parts a screen has, the more that matters. The whole demo is about 900 lines of Kotlin across ten files, and the source is on GitHub.

Status and how to try it

Flowik is experimental. The API is still moving between releases, and I would not put it under a production system yet. What it does have: bindings for Swing, Vaadin Flow and the IntelliJ Kotlin UI DSL, tests, and several demos. These include a Todo app, an Obsidian-like notes UI in Swing, and an employees master/detail screen in Vaadin.

Releases are published through JitPack:

repositories {
    mavenCentral()
    maven("https://jitpack.io")
}

dependencies {
    implementation("com.github.jreznot.flowik:flowik-swing:v0.5.0")
    // or flowik-vaadin, flowik-intellij
}

The bindings use Kotlin context parameters, so modules that depend on them compile with -XXLanguage:+ContextParameters.

If you build UIs on the JVM, I would love to hear how you manage state today. Try a demo, open an issue, or tell me in the comments what you would want covered next.

Source: github.com/jreznot/flowik

Will a couple of line markers in IDE make your microservice code more readable?

Yuriy Artamonov — Thu, 13 Jan 2022 07:17:34 +0000

Writing microservices has never been easy and does not become easier with growing codebases. All the complexity strives from tons of interactions between the moving parts of your applications.

And then we had this year's holidays and I had enough free time to think about it. Many complex measures can be used to make the code of microservices more readable, numerous expressive APIs, modern languages, we already use all of these, but the situation does not get better.

Finally, I've found a stupid simple approach to simplify the reading of code — just show a couple of icons for the most dangerous places where services interact with file systems, networks, make database queries, etc. And wow! It finally makes the code easier to read for me; I clearly see those important interaction points where things may go wrong.

Please welcome, the result of my Christmas holidays: Microservices Annotator plugin for IntelliJ IDEA. Because what else do developers from the IntelliJ IDEA team do on holidays — of course, they do plugins for IntelliJ IDEA!

In a nutshell, it just shows line markers for method calls in Java and Kotlin code where you call some well-known API methods, such as Spring Data or Spring Feign Client calls.

But that is just the tip of the iceberg. I know for sure, people use tons of custom APIs and not only OSS things like Spring Framework. That's why this plugin also enables you to mark any method in your codebase as some meaningful interaction point.

There are many interaction types supported:

Then the plugin just remembers your method signature in the project settings and you will be able to share the .idea/microserviceCalls.xml file with your colleagues. Also, if you try to annotate some API from a known public library, such as code inside org.springframework package, this usage will be reported to our server so this setting can be distributed to all users of the plugin after moderation. You can check APIs that have been recently approved on https://msa.strangeway.org/.

And this is a community-driven project, so all the data of marked public APIs are available on Github.

Finally, it is just that simple for you: Hit Alt-Enter on a method cal and Choose Mark microservice interaction method.

Please try and give us some feedback!

Would be great to hear not only positive feedback but also some criticism of this approach, maybe some better options exist. What do you think?

And answering the original question from the title: Yes, I believe this is a good thing for code reviews that will make your microservice code mode readable!