Clojurians Log v2

mxFlutter making steady progress, but we face a coordination problem not seen when wrapping HTML or qooxdoo or RN: state! 🙂 A flutter widget usually involves an associated state instance, from which we get context, and where we keep extras like controllers. But the state does not exist until Matrix renders MX stuff into Flutter stuff, so sth as simple as :color (-> (Theme/of ctx) .-colorScheme .-secondary) where ctx comes from the state (or is passed during rendering) -- no dice! This may be an insurmountable impedance mismatch. For now the workaround is a callback scheme where the base MX renderers need to check for property values being functions, and then calling them with the context:

:color (fn [me ctx]
              (-> (Theme/of ctx) .-colorScheme .-secondary))

Of course when the dust settles, that becomes:

:color (with-ctx (ctx)
              (-> (Theme/of ctx) .-colorScheme .-secondary))

What we cannot do is then have other MX properties derive their values from any property where evaluation cannot happen until render time. Mind you, in this case we could specify the :theme as an MX property and then no problem, but Flutter does this diabolical thing where we can not specify a theme and it silently supplies (.light m/ThemeData), and Matrix wrappers try to support the wrappee completely, so we support themes that can only be determined after rendering. sigh The team picked up on the Flutter expandable fab example https://docs.flutter.dev/cookbook/effects/expandable-fab and that is close to completion under mxFlutter, but it raises these crucial wrapping issues so I am taking my time on them. Then we do TodoMVC. It is not a great exercise -- the state dependency graph is quite trivial -- but it is a standard.