Fork me on GitHub
Danny Almeida03:10:07

What's the default renderer in the latest fulcro release ? Is it still ident optimized or keyframe renderer ?


Now that we have React hooks and the related Fulcro support I'd lean more towards that and less towards the specific rendering plugin.


The multi-root renderer was an attempt to get disconnected (from the query tree) components into the middle of applications, and RAD uses that a tiny bit; however, the support for things like use-component are much more effective and easy to reason about...and they don't require a rendering plugin:


esp in the context of generated ids that can be GC'd


I also found a really fast way to do props diffing on those, so the performance is quite good.

Danny Almeida05:10:31

thanks @U0CKQ19AQ. I was watching Fulcro 3 tutorials and so was confused as to how to go about using derived values.


The Fulcro model is very very simple on that front: UI is a pure f(s), where f is denormalizing the database. Period. There are no intermediate hidden wheels/gears/knobs. The view is a direct result of the data in the state map. If you want derived values you can: 1. derive them as pure calculations in the view (the most common). js is very fast, and many derivations work quite well that way and are trivial to get right and debug. 2. Cache the derived values in the state map at a well-known (and queried for) place, and define a lifecycle for that derived state. UISM is very nice for doing that. Good examples are RAD forms and reports. They come with state machines that do all manner of intermediate processing at well-defined interactions, and are self-contained. You can also use entry points like router will-enter, React lifecycle, hooks, etc. 3. You can use any the facilities of (2) and various customization points of Fulcro’s internals to add something more complex. I’ve never wanted/needed such a thing, but it is totally possible. For example, a really simple one would be to add a watch to the global state atom and watch it for certain changes and auto-derive state, then trigger a refresh (even a targeted one if you use the indexes) of the UI. Fulcro watches that atom in dev mode for Inspect, but does not use watches on the atom for any other purpose itself (e.g. swaps on the atom do not cause rendering…which is why you’d have to schedule a render yourself. The tx processing system is primarily where ui refresh is scheduled from).

❤️ 1
Danny Almeida07:10:43

Thanks @U0CKQ19AQ.  I'm still coming to grasp with how everything in Fulcro is a function of state.  I'm going through all the tutorials and they contain a lot of gems, but require multiple viewings to put everything together cohesively in my mind. Thank again for the videos, they help a lot to clear concepts. Cheers 🙂

Danny Almeida07:10:39

And thanks for being so responsive and proactive on this channel. 👍:skin-tone-3:

Jakub Holý (HolyJak)09:10:03

It seems I have committed myself to hold a 1-2h Intro to Fulcro workshop at the coming re:Clojure 😅

👏 2

Good morning all! I have a design question. I am building a mobile-first web app. I have several screens of forms that will not be submitted until the last screen is filled out. Each screen has a route. What is the best way to organize my project so that I can submit the data correctly from these screen when the front-end is in the right state?


So, I would tend to make it a single form (with subforms) so the state can be managed as a single "unit", then do the rendering according to what "page" you're on.


I would not use a router


something like

(defsc Wizard [this {:ui/keys [page] :as props}]
 {:query [:ui/page fs/form-config-join ...]
 (case page
   1 (dom/div ...)
is one way


that way your overall validation, diff, save, load, etc are way more unified.


If you really want a collection of related components to work together towards a goal, then yes, I'd definitely use a UISM


Do I need a parent defsc or a uism or something else?


Hi all, I am getting an odd resolution error in IntelliJ on a new fulcro-rad template project, it looks like the mount defstate macro is somehow not expanding properly. I've never seen this issue in the IDE before. Update: In fact, no expressions defined via macros as opposed to functions are being resolved. Maybe there is an easy IntelliJ/Cursive setting I am missing?

👍 1

tell it to resolve-as def


could also be a problem with your project overall, but macros that are not part of core may not be understood. In that case choose the quick fix, resolve as..., and choose the existing macro/form that is already understood. Most macros look like def or defn or just choose the one that best approximates an existing one.


Thanks, Tony! You mentioning it, I remember having to define these explicitly in the clj kondo config when I was using Calva before switching over to IntelliJ, so this makes perfect sense.