Fork me on GitHub
#fulcro
<
2021-10-21
>
sheluchin13:10:23

I find the docs here https://book.fulcrologic.com/RAD.html#Attributes a little bit confusing. In the second point it suggests not to think of attributes as being "owned" by a particular entity, but in the following point it says to place the attribute in "a namespace most closely representing the concept/entity for the attribute". It's like the former suggests a many-to-many mapping between attributes and entities, while the latter suggests a one-to-many. My understanding is that a keyword can be interned to an attribute in multiple namespaces. Is that right? If so, perhaps this portion of the docs could benefit from a clearer distinction between interned attributes, which have a one-to-one mapping with namespaces, and keywords, which map many-to-one with attributes and are irrespective of namespaces.

tony.kay15:10:35

Hey Alex, so, the general idea that I'm trying to get across is that identities is how you express "ownership", but the naming recommendation is just about finding the darn thing and preventing you from making duplicates.

tony.kay15:10:38

The docs need tuning for sure. I think it should say "put the attribute in the namespace of the attribute...sort of...like com.mycompany.model.person might be where I put all the attributes that I give the ns person to. It's just about easily making sure your model is clear/clean/easy to navigate. In general I don't recommend using generic attributes (e.g. :entity/something) for pragmatic reasons: they don't tend to perform well in queries (at least in Datomic)....but that's a db dependent bit of advice.

tony.kay15:10:26

If you're using SQL and can create an index willy-nilly then you can make those perform just fine.

tony.kay15:10:39

So, attributes, in RAD, are not "owned" so much as "can appear in entities identified by the following unique identity keys"

sheluchin15:10:49

Thanks Tony. Reading ahead combined with your response, it makes a lot more sense now.

roklenarcic17:10:43

When I show form (via clicking on a report row), it always tries to load information from the backend, even if I already have the information loaded. Any way around that?

tony.kay19:10:31

Write your own state machine for the form or report. Loading it is the right thing to do for many reasons: • the report may not have loaded everything the form needs • A long time may have elapsed between loading the report, and the user clicking on the form (the data you have is possibly stale) • The user could have had that form open in another tab, edited the object, and then clicked on it in the original tab...stale data again, but from a different context, and is confusing.

tony.kay19:10:40

RAD will always be loading the form. Period. 😄

tony.kay19:10:09

but everything in RAD is pluggable...so, use the fo/machine option and plug in your own behavior

tony.kay19:10:43

maybe you've got a websocket and you're using some kind of server push sync to keep it up-to-date.

roklenarcic19:10:45

I’ll start with the usual case, optimize later as needed

roklenarcic19:10:21

And I have a fairly powerful caching mechanism with strong invalidation on server side if needed

tony.kay19:10:24

Philosophy of RAD: Give you something you can stand things up with very rapidly, but don't get into the combinatorial explosion of an option for every possible need: instead make it easy to escape the provided things as needed (incrementally where possible). Behavior is a pluggable UISM. Rendering: just write your own body (it's just a defsc with helpers). etc.

roklenarcic20:10:10

I am trying to spice up my form title a bit with an icon, but it produces unwanted placement of form buttons:

fo/title (fn [_ {:keys [::m.user/name ::m.gen/email]}]
              (comp/fragment
                (ui-icon {:name "user"})
                (dom/div :.content (str name " (" email ")"))))
   
Produces:

roklenarcic20:10:37

seems like floating doesn’t work too well here

tony.kay21:10:50

There are some SUI options you can tune to tweak classes, but the idea is that you can create your own automatic layouts if you don't like those supplied. You can always take control of rendering in many different ways (custom UI plugin, write the body of the component, etc.). The intention for RAD generated UI is to be "good enough" for internal use and maybe alpha...refinement is up to you.