Fork me on GitHub
#fulcro
<
2020-03-21
>
tony.kay01:03:38

Update on RAD: the last few days I’ve managed to get a few new things working: • Datomic native IDs: the ability to map pathom/RADs concept of an id attribute (i.e. :account/id ) to Datomic’s :db/id so that you don’t have to use UUIDs. This is complete and working. You should be able to mix native ids with UUID ids in any combo. • Autocomplete (not yet documented, but working for time zone in account form in demo): basically you supply a resolver that can satisfy the options, and then dropdowns that need to search through a large number of options will hit that resolver to fill in possibilities. • Cascading dropdown in demo. I showed (New Invoice in Demo) how you can use the form on-change to trigger loading the possible options for a dependent field. Choosing a “category” limits the Item menu to only items in that category. The line item category is actually a virtual field that is for convenience only as well, so this is a particularly advanced combo. • Changed the sort behavior on to-many so sorts only happen at I/O, and not on every render.

tony.kay01:03:54

There’s a bit more polish still to go, but RAD is rapidly getting to the point that it can handle pretty complex forms. The new triggers and derived info abilities make spreadsheet-like behavior on a form quite simple, as is shown in the invoice forms in the demo for subtotals and total.

tony.kay01:03:35

There are some API consistency problems that I plan to address soon, so beware. The argument lists to lambdas on attributes/forms, in particular, I want to clean up. There’s also the possibility that I’ll rename a few keywords. I’d been using ::form/field-style and ::form/field-styles as the version of keys for attrs and forms respectively (because a form has more than one, and an attribute has only one). This was fine until I realized ::attr/field-options is already plural, and in fact, the field style one should have been ::form/field-style and ::form/fields-style, which is a bit more awkward, but allows for either thing to be plural…i.e. ::form/fields-options on forms and ::form/field-options on attributes.

tony.kay01:03:39

It has occurred to me with all of these keywords that docstrings are going to be necessary, so I’m considering making it standard to have helpers for setting things in these maps. You could still use the keywords, but if you used the helper you’d have a better time not misspelling things and also seeing what is avaiable. Think:

(defn attr-field-style
  "Set the form field field style to `style`"
  [attr-map style] 
  (assoc attr-map ::form/field-style style))

(defattr ssn :account/ssn :string 
  (-> {}
    (attr-field-style :social-security-number)
    (attr-read-only? true)
    ...))

👍 40
❤️ 20
fulcro 16
Frank Henard15:03:02

Hello, Fulcro newbie here. I'm rewriting an application I wrote in Re-frame/Reagent into Fulcro. Should I be doing it in RAD or regular Fulcro? Will regular Fulcro be abandoned in favor of RAD at some point? Any advice on when to use which?

tony.kay17:03:02

RAD is Alpha and not API-stable. You’re welcome and encouraged to try it, but expect it to possibly change a bit/break. As was said elsewhere, RAD is just pre-built components and such to make it faster to build new things…nothing in Fulcro proper is going away since RAD is written in it.

myguidingstar15:03:59

@ballpark RAD can be seen as an opinionated template of Fulcro, so regular Fulcro can't be abandoned. Maybe you should look closer at what RAD offers, if it contains many things you want, then go with it. Otherwise the cost of removing unused stuff is high, then build from scratch may be better

myguidingstar15:03:58

what does your backend look like?

Frank Henard15:03:47

Thanks @myguidingstar! I'm actually building the backend from scratch too, based on the recommendations of the Fulcro book and youtube videos. It's just a personal project that will someday serve a purpose, but I have a personal problem where new and shiny things cause me to rewrite applications 🙂