This form state stuff is really convenient, so glad I don't have to reinvent the wheel here

I was really (and perhaps naively) surprised by the variety of runtime errors that cropped up once we released our Angular app into the wild. There seem to be about on the order of 100 different kinds, a few which are true bugs, but the majority are due to old/uncompliant browsers and the like. For those of you running Fulcro in production and logging every runtime error, do you guys see similar things? Or is the Closure Compiler better at catching that sort of thing?

After editing an entity, using fs/add-form-config*, then if i delete that entity, do i need to clean up the form state? otherwise it will retain that old data right?

do most of you maintain separate namespace(s) for mutations or co-locate them with the UI components?

@currentoor I usually co-locate, the proximity of the code is something I care about, like we have a self-contained structure in a component, I like related mutations nearby as well, this is the most common case, but surely there are exceptions

yeah it's just too bad some mutations depend on the UI tree above the component of interest, like if i have a delete-package mutation and a list of packages elsewhere in the UI

then i have to put the logic for removing that ident in the mutation, feels like it couples the mutation to more than just the target component

you can always use declare

what do you mean?

clojure declare fn, like (declare MyComponent)

wait a sec, let me make a bigger example, just have to finish some rice first 😛

no worries, and thanks for explaining

@currentoor this:

(declare MyComponent)

(fm/defmutation my-mutation [input]
  (action [env]
    (fp/merge-component! (:reconciler env) MyComponent input)))

(fp/defsc MyComponent [this]
  {:query [:foo :bar]
   :ident [:id :id]})

you can use declare to reference something that is not available yet, so having the mutation before the component definition is not a problem

not sure if that would help

(defmutation delete-package [{:keys [id]}]
  (action [{:keys [state]}]
    (let [ident  [:package/by-id id]
          new-ps (fn [old-ps]
                   (vec (filter #(not= ident %) old-ps)))]
      (swap! state (fn [s]
                    (-> s
                        (dissoc :package)
                        (update :package/by-id dissoc id)
                        (update-in [:packages :tab :table :packages] new-ps)
                        (update ::fs/forms-by-ident dissoc {:table :package/by-id
                                                            :row   id}))))))
  (refresh [env] [:package :packages]))

i'm saying i don't like how [:packages :tab :table :packages] has to be hard coded in the mutation action

makes it hard for the same mutation to work in a devcard

because the main app has several joins to the list of packages, but in a devcard the list of packages is the root

oh, I use refs a lot to avoid deep nesting

so I hardly have data with nested maps, they are usually refs that point to something else

this way, when you transact, you send the ref with it, then is already a target

makes a lot easier, the data is always near

do you mean react refs or something else like idents?