it depends on the rendering plugin. The rendering plugin itself can define everything about how it works. The well-known render-layout
is the only RAD-specific constant.
So, the answer is: look at the source (or docs if they exist, which unfortunately they do not yet) of the rendering plugin. I recommend using tools deps to add rad-semantic-ui as source to your dev env, and add it as a module to IntelliJ so you can easily browse among the project source. The general idea is that a rendering plugin defines a map that maps from top-level layout keys to layout functions, and then the rendering plugin from there defines how things map from there.
SUI’s take on composition is to use a “form env” that has the master and child forms. This child forms may need to know things about the parent, and have to run operations on the master (ultimate parent) because its state machine is in control of the form set.
So, in general UI plugins will have to follow a similar “shape”, because of the “form set” requirement of the top-level state machine.
BUT, all of that is also pluggable (you can change the state machine def on the form, at which point such a customization would probably also come with some custom functions you could call, etc).
Ah that makes sense!
I was missing the fulcro-rad-semantic-ui
source, I've got all others here and was stumbling around in the SUI-wrapper haha.
I'll check out the sources now.
I just need to build a table in my top-level form and add the subform items as rows. Should be simple enough from here. Thanks once again!
While watching the videos I noticed a neat little IntelliJ live template for defsc
- I was wondering if this has been posted or shared somewhere and also if there are any additional fulcro templates people have found to be helpful / useful?
Fulcro 3.4.2 is on clojars. Primarily improvements to dynamic routing namespace. • Ability to change routes relative to an unknown parent • Changed order of routing instructions to be depth first to reduce/eliminate flicker • Fixed problem where relative routing could be denied by router that was not being affected (relative route change could still be denied by router above the affected change)
hm. Quick fix: CLJC compiler error for the CLJ-side on 3.4.2. Patch released in 3.4.2-1