Fork me on GitHub

@tony.kay Good talking yesterday — and you’ve turned me into a believer on UI State Machines. You had suggested that instead of replacing each state, one by one, to just copy the entirety into my namespace, to make it easier. Got all the needed changes to lazily load all the Trello card comments very quickly. Eventually, I’ll post the diffs vs. the default RAD report state machine, which will make it more obvious what my changes were. But, just in case, to anyone who might find it helpful, here’s what I did. • change any :: to ::report • wrote a my-load-report! my-goto-page* and a load-comments-for-page Surprisingly straightforward to do, as @holyjak and @tony.kay predicted! Modified state machine and helper functions posted here!

😻 2
👍 2

Also, a reflection: I had told @tony.kay this ridiculous sounding statement: “I’m finding the archiving Trello cards operations to be agonizingly long — it takes 1-2 seconds, where I have to wait until the Trello API completes before allowing the user to process the next card.” …and asked what would it take to allow a better user experience. Based on his suggestion, I optimistically deleted the card, and in the case of failed Trello API operation, just put the card back into the RAD report loaded-data field, and called a new :event/repaginate event, which just redoes the sort and filter operations, thus undoing the card deletion. I got this running correctly in less than an hour, which utterly blew my mind. It’s for reasons like this that I’m finding Fulcro and Fulcro RAD so high leverage. Amazing!

(defn undo-delete-card!
       " remove ident from list "
       [app state list-id card-id]
       (println "undo-delete-card! " list-id card-id)
       (let [cards-path [
         (log/warn "undo-delete-card! ident: " cards-path)
         (log/warn "undo-delete-card! card-id " card-id)
         (swap! state update-in cards-path conj [:trello-card/id card-id])))

 (m/defmutation repaginate-report [_]
      (action [{:keys [app state]}]
        (println "mutation: repaginate-report: ")
        (uism/trigger! app (comp/get-ident (comp/registry-key->class :com.example.ui.trello-list-report/ListCards)
                             {}) :event/repaginate)))


So, you should not be doing those bits via side-effecting functions on state and new mutations. You can do them right inside the ok-action of the original mutation. You have the state atom there. If you follow my general recommendations about writing mutation helpers ( then you can easily compose such operations. The exception is the uism/trigger! , which should be a new transaction.

(defn add-row-to-report* [state-map rad-report-id row-ident]
  (update-in state-map [::report/id rad-report-id :ui/loaded-data] conj row-ident))
would be a nice general-purpose helper



(defmutation ...
  (ok-action [{:keys [app state] :as env}]
    (when-not (successful? env)
      (swap! state add-row-to-report* :com.example.ui.trello-list-report/ListCards [:trello-card/id id])
      (uism/trigger! app [::report/id :com.example.ui.trello-list-report/ListCards] :event/repaginate))))


or you could even add an :event/add-row handler to your custom state machine that could combine those operations into a single thing, so that in your mutation you could have done just a trigger on :event/add-row with event data that has the ident.


Something like:

      (fn [env]
        (let [{:keys [row-ident]} (::uism/event-data env)
              old-raw-rows (uism/alias-value env :raw-rows)]
          (-> env
            (uism/assoc-aliased :raw-rows (conj old-raw-rows row-ident)


(uism/trigger! app report-id :event/add-row {:row-ident [:trello-card/id id]})


Super super! Thx!