Clojurians Log v2

defui SearchTable [{[:search :tab] [:es-type :es-sort-fields :sort-ascending?]}
                    {:hits (get-query SearchTableRow)}
                    :total]

(defui SearchTab [{:hits (get-query SearchTable)}

i do load-field-action on :hits in SearchTab, and this causes the props to have not-found

so far I haven't noticed any issues in production with this, and everything still works as expected

but it would be nice if load-field-action excluded [:search :tab] like it would exclude :ui/foobar

load field should narrow the query to JUST the field

it does

i'm loading :hits on SearchTab

yeah, so [:search :tab] should not be affected

this is the behaviour i'm seeing

are you right at a union?

the ident might be confused?

so the api-read is going to see a query like [:search [{:hits [:hits :total [:search :tab]]}]]

notice I have 2 :hits in my example so it's confusing

why is :search :tab there?

remember that that is an ident

yes I need access to that data in SearchTable

i was hoping idents would be stripped out like ui/foobar is stripped out

putting an ident in a query is valid om.next syntax

but it shouldn't be sent to the server

it is, but you're saying the SERVER should return it

by putting it in load-field's query

which overwrites it

totally valid thing to ask for, but you're unintentionally asking for it

no way to automatically elide that

load-field has a :without option for this kind of case, but not sure we tested an ident case

i agree the case is contrived a bit, but sticking with my analogy on ui/foobar, if I load-field-action on :hits, and the query was [:search [{:hits [:hits :ui/foobar]}]] that would not be sent to the server

:ui prefix is defined to always be elided...separate issue

an ident is valid query syntax

oh ok

(to server)

i guess that's my confusion I thought an joining on an ident has no meaning server side

in fact, load-field sends and ident-based join to the server 🙂

i'll try without 🙂

[:type-of-thing id] makes total sense to a server 🙂

if it is a persistent thing

Yah I see now

nods okay, i'll use computed props or something

try :without. We should make that support idents

k

it may "just work". Have not looked at the impl

but it should just work 😉

so in this case, when the server returns data for the ident, do you automatically merge it into [:search :tab] ?

:without #{[:type :id]}

merge is recursive on return value, and since you asked for it but didn't return it: not-found

though technically the sweep step should turn not-found into literally nothing...that's a minor bug too

it's weird to see anything at all in the global state at [:search :tab :hits [:search :tab]] for the ident [:search :tab], because if I actually returned a value from the server for [:search :tab] it would not exist in the global state at the path [:search :tab :hits ...] the data would be merged into [:search :tab], and then when om.next computes the props for the query [... [:search :tab]] it would fill it in

but as it stands I see [:search :tab] not found in the global state under hits

yah "into literally nothing" i guess we're on the same page 🙂

oh right. that's a little screwy

it should have totally "wiped" your :tab entry of the :search table

that's another ident-related merge bug, I'd say

when the ident isn't in a join (perhaps)

https://github.com/untangled-web/untangled-client/issues/29 here's the first bug

thanks

fyi i'm starting to write a series of little addons to our untangled project, i'm not sure they're suitable for mass adoption, but they work in all our use cases and simplify the API

so i'll entertain you with the list of addons fyi 🙂

1) i wrote my own transact! to never require an apostrophe on the query

(defmacro transact!
  ([txs]
   `(transact! (:reconciler @admin.core/app) ~txs))

  ([reconciler txs]
   (let [txs (->> txs
                  (mapv (fn [xf]
                          (if (list? xf)
                            (let [[mutation-sym & args] xf]
                              (assert (symbol? mutation-sym))
                              `(list (quote ~mutation-sym) ~@args))
                            xf))))]

wrote my own defui macro that returns a factory when you do @MyComponent, and also expects query as 2nd argument

(defmacro defui [name q & forms]
  {:pre [(symbol? name)
         (or (map? q) (vector? q) (list? q))]}
  `(let [factory-fn# (atom nil)]
     (om.next/defui ~(with-meta name {:once true})

         ~'static cljs.core/IDeref
         (~'-deref [this#]
          @factory-fn#)

         ~'static om.next/IQuery
         (~'query [this#]
          ~q)

         ~@forms)

     (reset! factory-fn#
             (om.next/factory ~name {:keyfn (framework.core/mk-defui-keyfn ~name)}))))

it also uses ident as the react-key by default

if no idents, then it uses GUID

good enough for our purposes

in our mutations you can bind a mutation namespace to an ident, so that the 'ref' is always set to the binding for any mutation that begins with myns/foobar

(m/bind-ns-to-singleton-ref! 'search admin.ui.search.core/SearchTab [:search :tab])

this let's us transact! from anywhere on (search/...) and still have the mutation implementation leverage 'ref'

you can also bind namespaces to ComponentType

(m/bind-ns-to-component! 'search-row admin.ui.search.table/SearchTableRow)

so the idea here is to use computed props less

and just have transact! be applied to relevant parent

hope that's useful

i guess another would be I have swap-this! swap-global!

swap-global! is just swap! on app state

swap-this! is swap! on app state + ref

(defmethod m/mutation 'search-row/activate-listing [env _ params]
  {:action (fn []
             (m/swap-this! env assoc :status "ACTIVATED"))})

Yeah, I like the swap helpers. Not quite following what the bind things are doing. I'm a little tired today...not thinking very fast 😕

The deref trick for factories is an interesting twist

ah, I see on your binding. Interesting. A bit more convoluted on the ref bit. Harder to trace what's going wrong when things bubble like that, but tractable.

I can see how that reduces some of the boilerplate

@tony.kay fyi the deref trick code I wrote doesn't work in :advanced mode yet 😞

i think 'static' has some issues in advanced that i'm not appreciating

you using the latest Om/UC?

yes

I think there was a static fix, but perhaps it didn't get merged yet

hm interesting

i'll try it out i haven't tested advanced in 2 months