From 0e1d94ef2fee3f22805b39132b0a9aeca32c3acc Mon Sep 17 00:00:00 2001 From: tannevaled Date: Sat, 10 Oct 2026 21:46:55 +0200 Subject: [PATCH] README: toolkit does import mvvm's core, since v0.124.0 The README said toolkit never imports mvvm. It has since v0.124.0 (PR #165, 2026-08-07): 107 of its files do, and widgets expose state as observables. What it must not import is a binder package, which would be a cycle. Measured with go list -deps. Co-Authored-By: Claude Opus 5.5 --- README.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 79ffad0..8189660 100644 --- a/README.md +++ b/README.md @@ -9,11 +9,13 @@ Binding glue between [`go-widgets/mvvm`](https://github.com/go-widgets/mvvm) ## Why a separate module -`mvvm` is deliberately toolkit-agnostic: it binds through a pointer to a -widget's value field and a pointer to its callback slot, and never imports any -widget package. `toolkit`, in turn, never imports `mvvm`. `mvvmtk` is the one -module that knows **both**, so an app wires a ViewModel to a widget in a single -call and never touches widget state fields directly. +`mvvm`'s core package is deliberately toolkit-agnostic: it binds through a +pointer to a widget's value field and a pointer to its callback slot, and +imports no widget package. `toolkit` does import that core (since v0.124.0: +its widgets expose state as `mvvm.Observable`s), but not the binders, which +would be a cycle. `mvvmtk` is the module that knows **both**, so an app wires +a ViewModel to a widget in a single call and never touches widget state fields +directly. ```go unbind := mvvmtk.BindText(entry, vm.Query, win.Invalidate) // entry.Text ⇄ vm.Query