So, I’m working on a convenience macro for the common case. So far, I’ve got this working:

(defsc Person
  "A person component"
  [this {:keys [db/id person/name]} _ _]
  {:table         :PERSON/by-id
   :props         [:db/id :person/name]
   :initial-state {:db/id :param/id :person/name :param/name}}
  (dom/div nil
    name))

(def ui-person (om/factory Person {:keyfn :db/id}))

(defsc Root
  [this {:keys [people ui/react-key]} _ _]
  {:props         [:ui/react-key]
   :initial-state {:people [{:id 1 :name "Tony"} {:id 2 :name "Sam"} {:id 3 :name "Sally"}]}
   :children      {:people Person}}
  (dom/div #js {:key react-key}
    (mapv ui-person people)))

The basic syntax is:

(defsc ComponentName
   optional-docstring
   [thissym propsym computedsym children]
   options-map
   body)

where options-map can be used to generate the query, ident, and initial state. It does not support more advanced cases…defui is really the general utility. Just trying to save some headaches for the very common component case

options-map: - :children (optional) a map of keyword to class. Generate the query join, error checks your destructuring of props, and helps initial state generation work - :props a vector of the scalar props. Generates query elements, and error check destructuring - :id (optional, defaults to :db/id). Needed for ident. - :table (optional) The table side of the ident. If not supplied, you don’t get an ident. - :initial-state (optional). A map of key/value. Checked against queried props. Value for scalar props can be a scalar value OR the special :param/XYZ, which will pull the value from incoming parameters. Value(s) for children can be a map or a vector of maps which are treated as parameters to an automatic call of (get-initial-state ChildClass p). The value(s) in the option map(s) can be scalars or :param/XYZ.

I’m still playing with it, and am not ready to release, but if people have feedback/input before it becomes API I’d like to hear it.

It is on branch feature/defsc, with a devcard of convenience-macro-cards

Oh, and it does the ^:once bit for you as well. Thinking about adding in automatic generation of a deref factory with react key based on id (if there is an ident)…so you could do this: (@Person person-props). Still thinking about the options here. I think I fancy a deffactory more, since you can name the symbol then, and possibly have a bit more control. Thinking on it.

not sure it is worth it

The error checking is quite nice, actually…it makes it much harder to write broken UI code.

I have to say: after playing with it a bit, I really like it. It caught more than one mistake I made as I coded up the devcards for it, and reported the problem in an easy-to-understand way.

should have written this a year ago

I just pushed fulcro-1.0.0-beta10-SNAPSHOT with the new macro (fulcro.client.core/defsc). That will allow anyone to play with it easily to give feedback. NOTE: The API for it is not considered stable, but it is fairly well-covered by tests, and seems to work well as far as I’ve tried it.

@tony.kay Cool, makes total sense. Probably should not have mentioned component, the thing that I seem to be repeating is sending the component ident (ref). Mostly use post-mutation for loading flags, that i have in the component. currently send it as param, to avoid hard-coding it in the mutation.

I see. The ref is possibly somethign that could be automatically included, since it is data.

Hm. Composing in mutations is a problem…there is no way to know ref in load-action, for example

Yeah, it’s really not a good idea I don’t think to mix :ref into the post mutation environment. It would make people expect it there, and there are just too many circumstances when it cannot be supplied:

(load @app ...) 
(load reconciler ...)
(load parent-component-during-callback ...) ; wrong one

(load-action app-state-atom ...)

Frankly, it would be easier for you to write a wrapper for load that automatically augments your post-mutation parameters with a standard parameter. Then you’d know the limitations, and have the convenience.

@claudiu This is untested, but should be close:

(defn refload [component-instance keyword-or-ident QueryClass config]
  (let [ident  (when #?(:clj  (satisfies? om.next/Ident component-instance)
                        :cljs (implements? om.next/Ident component-instance))
                 (om.next/ident component-instance (om.next/props component-instance)))
        config (update config :post-mutation-params assoc :ref ident)]
    (load component-instance keyword-or-ident QueryClass config)))

and should only ever be called with a this from within a component

Actually, it should work just as well as load…ref just won’t show up if you use a reconciler or app

or a component that has no ident

Namespaces:

[om.util :as util]
[fulcro.client.data-fetch :as df]
[om.next :as om]

I tuned it up a bit…update tolerates nils well, so all that checking wasn’t necessary

thank you, will give it a try. 🙂

It's a really small thing, was curious why it's not there if it's a design decision. Makes sense not to add it given load-action 🙂

Still a lot of details to figure out. So far think I'm getting close to breaking even for this project, if I would have used js & python. Initial learning curve but things are going really smoothly and fast now 🙂

good to hear

of course you can just call that function load and make your own data fetch namespace 🙂

ahh yes 🙂 Don't know it the benefits would benefits will outweigh the cons. So far everything is almost perfect.

Only the fact that I can't use load on ssr seems to be missing. Still pretty awesome to have ssr, user experience is really nice 🙂

So, load on SSR…I think all you’d need to do is write a mock networking implementation for the server-side…I think it would be pretty small.

hmm would be crazy if it would work 🙂. Really pressed for time until the end of this month, but will give it a try afterwords.

You’re currently my biggest contributor on patreon, so I may just try it for you later today 😉

was thinking of custom networking like in the restful api in getting started, and just hook it up there with the fulcro-server. Is that what you mean or mocking as in testing ?

the former…it is just a protocol with a send method…instead of doing network stuff, call fulcro-parser

there’s no network error possible, so it’s very little code I think…

assuming I haven’t stubbed out something in the network stack that would break it

oh wait…it is even easier

the clj version of load could just call fulcro-parser directly!

don’t even have to involve any of the networking stack

there’s a little complication to it…load-action, etc

it would be better to have all the machinery in place, so I take that back

the implications if it would work are pretty nice. Just put in componentWillMount the initial loads, for ssr should have a fully populated page out of the box, with the same code that you use on frontend when doing routing.

there are several bits that may be non-trivial. I’ll have a look at it.

oh, no, you won’t get react lifecycle

react doesn’t run on the server

the string conversion process isn’t full-blown react

you’ll get started-callback.

in nodejs componentWillMount is the only one that runs on ssr. No idea if om-next mimics this behavior.

don’t know

not sure how the render to string is working there. I haven’t read the code.

my ideal flow, would be a static method initialLoad, that the router can call.

starter callback where I can call component static method that can use load inside sound really nice 🙂

thank you for taking the time to look over it 🙂

@claudiu As I thought: rendering to string is written in om.next by hand. There are no lifecycle calls

so not exact react behavior. In the react docs it says "Generally, we recommend using the constructor() instead." & figwheel also seems to trigger the method for every change to the file.

for what?

remember that figwheel changes the root level key, meaning react will throw away the DOM an rebuild it…which will trigger all lifecycle mounts I thnk

another reason to embed your load behaviors into mutations…avoid the UI-based side-effects

I never touch the react lifecycle unless I need it for the DOM…focus, ref to a canvas, that kind of stuff

but apart for componentWillMount and routing. Is there another place where to put the initial loading markers, and load ?

what do you mean? Why isn’t started-callback sufficient?

make your own routing mutations…the routing namespace has functions for composing routing into your own mutations

ahh, don't know why I did not think of extending the routing mutation.

😄 Sorry, that is the intended use

that way your routing mutation can check state, see what is stale, etc etc.

completely moves the side-effects to the proper place: mutations

Hm. That isn’t in the dev guide, is it 😞

I could swear I wrote that down in docs somewhere

route-to-impl! will work for composition when using all kinds of routers (including dynamic). update-routing-links works for just the standard union-based.

seems to be in the source, added with dynamic router 🙂

well, update-routing-links was there since defrouter

the new route-to-impl! was needed to support dynamic

I’m adding some comments to section M15 of the dev guide

totally missed that idea. Will move the initial load into routing mutations, for most of my use-cases think dynamic router is a better match. Haven't had time to look over it, as soon as I got routing working, focused my attention on other areas.

fulcro-template with full server configuration was a real life-saver 🙂

re-pushed SNAPSHOT of beta10 to clojars. I’ve hammered on defsc quite a bit, and think it is pretty close to API-ready. I fixed up initial state parameterization support, and documented it in section M05 of the devguide (not live, just on develop). It really makes writing most components a lot cleaner and easier. It could easily be exnteded to support react lifecycle as well, which would go a long way towards making it the only solution you’d need. The API it has should still be considered relatively unstable.

@currentoor @mitchelkuijpers @wilkerlucio @gardnervickers ^^^ I think you guys will like this, assuming you’re not using a lot of custom protocols on your components.

Will it be compatible with forms spec etc?

Good question 🙂

at the moment it is not, but it isn’t even officially released yet 😉

Yeah i might like it if it was 😜

Would be trivial to add that. Thanks for asking

np

oh…iniitial state might be troublesome, since form lifecycle can be complex

then again…if you make it a form, it’s just wrapping it in build-form, isn’t it?

can’t remember if that’s recursive

oh, doesn’t need to be…the sub-forms would auto-wrap it as well

See, I knew someone would have good feedback @cjmurphy

@cjmurphy Added. Now specify :form-fields [...] with your form field declarations. If you use initial state, it will auto-wrap it with build-form. I didn’t test it live, but the macro output looked right.

pushed to clojars on beta10-SNAPSHOT