Clojurians Log v2

How can I chain mutation functions in a load post-mutation? https://clojurians.slack.com/archives/C06DT2YSY/p1496100336889588

chaining: I don’t recommend that…kinda messy. Rather, write a support function that accepts a state map for all of your state manipulations, then it is easy to chain them:

(swap! state (fn [s] (-> s  (do-a) (do-b) (do-c))))

and your simple mutations are just (defmutation do-thing [args] (action [{:keys [state]}] (swap! state do-thing)))

but technically, there is no problem with pulling an action out of a call to mutate. It is just a multimethod.

(defn open-menu-impl [state-map id] (assoc-in state-map [:menu/by-id id :open?] true)

(defmutation open-menu [{:keys [id]}]
  (action [{:keys [state]}] (swap! state open-menu-impl id)))

Makes sense — thank you

welcome

Has anyone extended untangled-ui forms support in a way that you can have a field which has a query? I have a field that needs to load options from a remote place and then show them and then you can create or select an existing. I tried to make a field and now I am creating a subform But then I have the problem that the subforms ident will change based on what the user selects.. Not sure if that is a problem btw.

btw I think that making this a subform is the wrong solution for what I am trying to do

@tony.kay FYI use case, in case it's helpful for future designs — essentially I want my post mutation to do 'foo and 'bar, but 'bar itself is also a mutation that can be triggered from elsewhere in the UI. For example, after loading data fields on a record, I want to expand a detail view and select a particular tab; selecting a particular tab is a mutation that can be triggered by the user via the UI as well.

@mitchelkuijpers Yeah, it isn’t a subform. What you want is a control that has it’s query, a load that fills in that control, and a callback that can tell you when you’ve interacted (selected). Then you can hook the callback up to fill in the form field (just modify the value in app state).

and probably pass in the current value via computed (since you won’t be querying for the current selection in the control).

So, you have UI control that takes the possible selections (via query), a selected value (via computed), and has a callback to tell you when it is selected. The parent (form) does the transact to update the actual value.

and since forms are just stacked on top of regular state, that just means updating that field’s value. Of course, you’ll want that field to be properly declared (for submission, dirty check, etc.)

but the control details are just orthogonal.

was there a question in there? It sounds like my response from 5:49pm yesterday (PST) applies just fine.

@timovanderkamp just for my info: are you planning on making those extensions to om-css?

@tony.kay yes, but first i will continue playing with this version to see if more has to be fixed

great

that’s always a good approach. see where things are broken usually leads to better design

:)

@tony.kay I was a bit scared of just modifying the app state. But I will try this out. Good to know that I am on the right track

The hardest part is getting the current value since it is an ident and I cannot query the form state (I think)

I was also thinking.. wouldnt implementing a $ prefix for preventing localization make the Global protocol unnecessary?

@mitchelkuijpers You have to query the form state (e.g. your field value)

@timovanderkamp Hm. I was thinking that it would mainly be top-level components that would contribute to the global. Something like a Button should not need to, but you might need the nesting selectors.

So, I’d say both are nice to have

Ah so just query the untangled.ui.forms/form-key

oh, not what I meant 🙂

yes, you do query that, but the current value is just your local current value…you still treat the form-data as opaque

it is the “pristine” copy

Ah ok

along with field decl config

So maybe just copy the current value from the ident when it's get selected

um. let me try an example…forgive me if I don’t get the naming right, I don’t have it all in my head:

No problem, I have been breaking my head a bit to long about this so I might be a bit slow today

(defui SelectorComponent
  ... query for your selector, which will act as UI for form field. This is NOT a form field ...
  ... ident ...
  (render [this] 
    (let [{:keys [current-value onChange] (om/get-computed this)
          {:keys [selections]} (om/props this)]
    ... render your selector, with current-value, and selections. Call onChange when a change happens))

That would be the selector thingy. It is not part of the form…just a UI component with query, ident, and some computed stuff

Then, your form. Let’s say you’re selecting tire-size. At some point you’ll need to load the tire sizes for the selections of the above component, but that is orthogonal to the form…just for the selector thingy

(defui TireForm
   ... declare form fields, including :tire-size ...
   ... query (include :tire-size and other form stuff, ALSO include a join {:tire-selector (om/get-query SlectorComponent)}) >..
   ... ident as usual ...
   (render [this]
      ; let, extracting tire-size and tire-selector
      (ui-selector (om/computed tire-selector {:current-value tire-size}))
      ; other form stuff))

so you see you’re feeding the selector the current value through computed

so the selector can be parallel to your form

You can just mutate the tire-size as you would in any component

Now, you could abstract that all into functions (one that returns the query bit, one that calls the rendering with proper options) and add that in the form-field multi-method.

So basically just create a component which handles the options and the current value, and then on change updated the correct part of the form-state so I still get the pristine and other goodies

yeah, this is how you’d implement a form field extension that also needs to query for data

:tire-selector isn’t part of the form, per-se, it is just rendering assistance

Yeah the biggest problem was that I need to add a query, form-spec item and a certain render. But maybe I can just extend the multimethod which I also did for our own text-field component and then just create a function for the needed queries based on the form-spec

Big + of creating a data structure for the form

Thank you @tony.kay this helps a lot. I was banging my head against a wall

no problem.

It does. No question here, was thinking about it and realized it might be useful in general to share my use case 🙂

Can you think of an example when you would use rather vanilla omnext (build some custom framework around it) instead of untangled?