Clojurians Log v2

Made a little helper:

(defn expose-layout [child-or-children-thunk]
  (fx/layout-builder
    {:builder (fx/->CBAsIs
               (fn [ctx ^m/BoxConstraints box-constraint]
                 (fx/fx-render ctx (child-or-children-thunk
                                    {:min-h (.-minHeight box-constraint)
                                     :max-h (.-maxHeight box-constraint)
                                     :min-w (.-minWidth box-constraint)
                                     :max-w (.-maxWidth box-constraint)}))))}))

(fu/expose-layout 
  (fn [{:keys [max-w]}]
    (fx/sized-box {:width (/ max-w 2)})))

Nice. I have been meditating on the verbosity of even CLJD-macrofied code and thinking there is a big opportunity for CLJD somewhere in Flutter, possibly as a prototyping language. Which just happens to compile to a production app. 🙂

"Builds a widget tree that can depend on the parent widget's size." Ha, this is funny. Cells got created over a layout challenge. The parent needed one property of a child to decide one of its properties, but the child needed a parent property to decide one of its own. There was no cycle, but neither parent nor child could decide their layouts in toto on their own. "the framework calls the https://api.flutter.dev/flutter/widgets/ConstrainedLayoutBuilder/builder.html function at layout time" That scares me. But I panic easily. 🙂 Lemme give it a try. Prolly needs a new factory macro to support the interesting builder parameter, the BoxConstraints.

I meant to say, functions all the way down are great for things like expose/layout , totally crushing boilerplate. And devs/teams can roll their own little DSL, shallow enough for new hires to get up to speed in short order.

Ah, just looked at the FAB example which has a parallel pattern with an explicit :builder property. Feeling better! 🙂 One thing I suspect is that Flutter itself will be calling the builder itself whenever it has a new BoxConstraints for us to adjust to, so we may not even need f/mx reactivity. But lemme see what I can implement. Every new example helps. ..... OK, latest f/mx is set up to run new layout builder by default. clj -M:cljd flutter -d macos Or one of the desktop/web device options will let you conveniently resize window to see fontsize tracking window size. 🛏️ time. 🙂

I'll move that to the f/mx sandbox when I am up.

ps. Yeah, we do not need reactivity to handle the BoxConstraint, but the built widget can have whatever reactivity it needs off the size. I make the color sensitive to the size in an update. Moving it to the sandbox now.

OK, haha, just noticed we can test resizing in the sim by rotating it. 🤦 OK, the sandbox is set up to run the layout builder sample...as soon as I push. 🤦 Need more ☕

👍🏻 Thank you!

Heads up! I switched the f/mx repo back to defaulting to the Flutter standard, the Counter demo. Modify main to launch x029/make-app if needed. The example is also now in the sampler repo. Make the same mod to main to run it there. Happy coding!