neat! I'll check it out!

I implemented the basic form thing and it works fine https://github.com/thheller/shadow-experiments/blob/master/src/dev/dummy/fulcro.cljs

there are however still a whole lot of react references everywhere so running it without react doesn't work. it does no rendering with react but form-state breaks if react isn't loaded

(bind {:ui/keys [saving?]
         :user/keys [id name settings] :as u}
    (use-root :current-user User {}))

thats basically the emulated raw3/use-root. I don't know if use-fulcro is actually needed anywhere when none of the react-factory or DOM things are used

I think that’s right @thheller. I have not had time to review the dynamic vars completely, but the with-fulcro thing may not actually be necessary in most/all cases. It’s going to take a little more refactoring to get React completely out of code paths. Dynamic routing is broken because it expects there to be an app root, and it sounds like form-state as well, though both should be fixable I’d think.

Looking through it, it’s kind of a big project to isolate React as a library without breaking existing programs. I don’t think it’s terribly difficult, just a lot of tedious code movement of non-react stuff to new nses, and then making aliases from the original spots to them so that nses like form-state and such can refer to the common non-react stuff instead of the “mix” that is components currently.

Same for application. 99% React-free, but it has a tiny bit mixed in.

yeah I can imagine. getting the separation right is difficult

It isn’t too terrible actually. I think I’ve got most of it done (sans testing).

SHA c5a0cfe60c281c4a25f7de966298b67a349fccab has a first pass that should do it for most nses. There is now a raw.application and raw.components ns that are the base for the legacy ones. I also put in some fixes related to using this all from Clojure. So, to try it out and avoid react completely, use raw.components and raw.application nses.

alpha.raw pulls in both of those, and has use-root!

oh…missed something..sb

ad2425b9973af287f6b64fe9ad56808dd8c69eaa is the better SHA

the nc moved to raw.components, and formc to form-state

I have not tested this against live UI much, but all tests pass

Not sure what is optimal but you can always use the state (ie client DB)...

I have used the runtime atom for that - communicating to the error-action in this case the prior state of the app if a network call fails in order to rollback to the prior app state.

(defmutation delete-goal
  [{:keys [goal-id]}]
  (action [{:keys [state]}]
    (let [goal           (get-goal-tree goal-id @state)
          all-goals-flat (goal-tree->vec goal)]
      (swap! state
        (fn [s]
          (reduce (fn [acc goal] (ns/remove-entity acc (dm/goal-ident goal))) s all-goals-flat)))))

  (remote [{:keys [app state-before-action]}]
    (let [runtime-atom (get app ::app/runtime-atom)]
      (swap! runtime-atom (fn [s] (assoc s :prior-state state-before-action))))
    true)

  (error-action [{:keys [app state result]}]
    (let [runtime-atom (get app ::app/runtime-atom)
          {:keys [prior-state]} @runtime-atom
          server-error (fu/get-server-mutation-err result)]
      (let [new-state
            (-> prior-state
              (assoc-in (dm/goal-ident goal-id :ui/submit-state) :state/failed)
              (assoc-in (dm/goal-ident goal-id :ui/server-message) server-error))]
        (reset! state new-state)))))

Technically the most appropriate answer is what @U0522TWDA said: I would consider that “state”, and state atom is what I’d typically use. See form-state, for example: the entire basic mechanism of that is to make a copy of something (pristine) and then let you update it and try to save it. Ultimately you can either choose to revert it (copy the pristine back over the original) or commit the changes. Another thing to consider is that the params to the mutation are available in every section of a mutation, and do not change. You can close over whatever you want/need there, which allows you to control “state capture” from the UI. The runtime-atom is also a completely legitimate solution, particularly if what you want is more time-travel of state. That’s a lot harder to make user-friendly, because user’s don’t expect things to go back in time at some future point of interaction. A slow network interaction could allow them to move on to a whole other are of the app, which you then “snap them” back from.

@U0522TWDA have you used pathom placeholders with subforms? It seems that add-form-config isn’t finding subforms if my subform is split into placeholders…and struggling to figure out how to get around it

No I haven't :( Please let me know if you figure it out!

Perhaps subforms require that the thing being edited is an entity of its own and not a part of a bigger entity?

i think i’ll have to make a duplicate edge from A to B that doesn’t use pathom placeholders, seems the form state code assumes that any join is going to be flat, it doesn’t know how to walk the placeholder map

FYI https://clojurians-log.clojureverse.org/fulcro/2021-02-11

Oh nice! I tried searching for prior art and didn’t find this. However the link to the gist is broken for me. It also appears that a PR was never created. @UCFG3SDFV were you still working on this?

Here's the version I have:

$ cat .clj-kondo/hooks/fulcro.clj
(ns hooks.fulcro
  ""
  {:author "Adam Helins"}
  (:require
    [clj-kondo.hooks-api :as hook]))

(defn defmutation
  [{:keys [node]}]
  (let [[_call
         sym
         & arg+]    (:children node)
        docstring   (first arg+)
        [[param+
          & fn-like+]
         docstring-2] (if (hook/string-node? docstring)
                        [(rest arg+)
                         docstring]
                        [arg+
                         nil])]
    {:node (hook/list-node (concat [(hook/token-node 'defn)
                                    sym]
                                   (when docstring-2
                                     [docstring-2])
                                   [param+
                                    (hook/vector-node (map #(let [[_sym
                                                                   arg+
                                                                   & body] (:children %)]
                                                              (hook/list-node (list* (hook/token-node 'fn)
                                                                                     arg+
                                                                                     body)))
                                                           fn-like+))]))}))

Thanks. This is a simpler approach I think. I was under the incorrect assumption that mutation handlers could refer to each other, but that’s not the case (the :dispatch key in env holds those lambdas). On the flip side, I could see kondo implementing “unused lambda” lints one day, which would throw false positives with the above.

@U6GFE9HS7 Hi, here is my original gist: https://gist.github.com/helins/52d03847157b0dc95c6987844a74dd68 The PR slept out of my mind (had to work fast at that time) and I see you have already proposed something. Let me know it goes through, if not we can use that gist 🙂

Thanks, will do :)

I’d say regardless of backend data storage choice, the connective tissue with the client is always the same in Fulcro: pathom resolvers. So it’s pretty backend agnostic in that regard. Going with something you’re familiar with is likely a good choice. The problem domain might lend itself to one database over another as well.

Fulcro RAD has helpful database adapters for Datomic, and I think SQL (not sure about the state of that at this moment), and just days ago there was a post for a Crux adapter.

Demo repo for RAD is here: https://github.com/fulcrologic/fulcro-rad-demo

There’s info for using it with each database in the read me.

Ah awesome thank you for this I was wondering if Datomic was the right pairing I’ll give this a look!

I can highly recommend Crux (https://opencrux.com) for use with fulcro - it would fit for similar use cases as Datomic, but is open source and the team is amazingly nice and responsive if you have any feedback or questions

I’ve only used Fulcro with Datomic, so I’m biased. Fulcro’s query syntax was inspired by Datomic’s pull syntax and was originally designed to work directly with it. Pathom made it much easier to integrate with other DBs, but the pairing is still optimal.

Thank you both, Crux looks pretty awesome in general I’ve never heard of it. I’m also wondering does anyone have a good full stack example of fulcro with a backend or template they use. I read the docs but definitely still feel really daunted getting started and would love to poke around with a good starting off point. I’m also new to clojure generally so if fulcro is maybe a tough starting point let me know as well. It just seems like the best option for building a production app though as well.

I have a full-stack app template I base any new projects off of: https://github.com/dvingo/dv.fulcro-template fulcro may be a tough choice to start with, but as long as your expectations are accurate in terms of learning rate (I have a heuristic of giving myself about 3 months when learning something significantly new) then you should be okay - it would take a similar amount of time no matter what you pick, as you'll have to do the research and integration of a myriad of libraries which become your problem if you don't go with fulcro - in my opinion.

The reasons I like crux over datomic: • setup. start a new node: (crux/start-node {}) ◦ scales from one node to many seamlessly • no schema • open source and gratis • amazing team • has a query planner so you don't have to ever think about the order of your datalog clauses again • documents over entity attr value triples

I like this, I think I’m going to give crux a go regardless now seems really awesome

I think the learning curve sounds about right. My team and I are coming from react js/ts backgrounds so I was looking to fulcro because like you said we’d end up trying to build something similar out of libraries and such anyway. Learning curve of a few months seems accurate too, I think we may want to stick to a few internal projects with looser timelines to learn a bit more.

We did take up elm fir a few projects and sorta learned as we went and it was fine but this seems like there is a bit higher of a learning curve.