Fork me on GitHub
#om
<
2016-02-01
>
jimmy02:02:51

@pithyless: om next is awared of the query segment, each query segment is indexed with the corresponding components through indexer in om next. They are tracked and re rendered accordingly.

hueyp03:02:38

anyone know the importance of path in the parser env?

selfsame03:02:09

My app has generic panels that can be configured to show components, and I'm having trouble getting their queries properly set up. Has this been discussed anywhere?

hueyp04:02:53

are computed props just non-query props?

hueyp04:02:11

like the idea is to keep them separate, or am I missing something deeper

cjmurphy04:02:02

That's how I think of them too - calculated from real props (so derivable from them), or unrelated to real (query) props such as when you want to pass functions around.

cjmurphy04:02:52

I've also used them for master props being used in the child component, from advice given here. (I use master/detail for data and parent/child for components - but it all of course gets mixed up ;-))

hueyp04:02:46

okay, makes sense. I am going around the kanban example and it uses them for handlers and such, but when toying around I was just merged them into normal props and it worked, so was a bit confused. I wonder if its purely organizational, or if om benefits from the separation

cjmurphy04:02:50

Doesn't make complete sense to me yet. But it is a question going to have to keep coming back to. :om.next/computed - another map for that inside of props map - is all that it is in the code - or that's what I assume for devcards and it works.

hueyp04:02:17

omg so much slack magic

geraldodev12:02:58

how to get the root component from the read function ? In mutate we can (:root @(:state reconciler))

anmonteiro12:02:45

@geraldodev: there's a function for that

anmonteiro12:02:52

(om/app-root reconciler)

geraldodev12:02:01

Thank you @anmonteiro. Now I got it, a function for (:root @(:state reconciler)). Sweet

denik13:02:18

Is there a way to make idents for a coll of items? In my scenario a coll will get processed into one item, so I don’t need to make components with idents for each item.

iwankaramazow13:02:13

@denik: it's the same as making 'normal' idents

denik13:02:33

@iwankaramazow: yep works thanks!

anmonteiro14:02:14

@dnolen: there was an issue brought up in the channel a few days ago: currently transact! doesn't call transform-reads when the first argument is the reconciler; is this intended?

dnolen14:02:13

@anmonteiro: yes maybe - it’s the case where you can control the behavior

dnolen14:02:33

if you’re calling directly on the reconciler you might want that level of precision

anmonteiro14:02:42

@dnolen: makes sense, thx

jlongster14:02:35

is it an anti-pattern to create a component just with om/Ident and om/IQuery methods for normalization, no rendering?

dnolen15:02:30

there may be more support for that later since you might want normalization support server side

jlongster15:02:51

@dnolen: thanks, good to know

denik15:02:52

is there a way to provide nested idents in om.next?

denik15:02:13

deep queries work with the parser but there is no ident equivalent

denik15:02:50

do often, when I don’t need additional components for deeply nested data I find myself normalizing into the app state manually

iwankaramazow15:02:58

@denik: I tried something like this with the pattern @jlongster described above

denik15:02:03

datascript solves that w/ a schema living outside

iwankaramazow15:02:39

Just make components with it's sole purpose Ident

denik15:02:43

@iwankaramazow: can you link it?

jlongster15:02:45

@denik: it sounds like your problem is similar to the one I just faced; yes just create a "query" component and pull it in the leaf of your query https://gist.github.com/jlongster/40f59e71318087e649f3

jlongster15:02:05

[{:transactions ~(om/get-query TransactionTableItem)}]

jlongster15:02:15

np (that query could be arbitrarily deep obviously)

denik15:02:21

yeah get it

denik15:02:35

it seems hacky

jlongster15:02:36

feels like there might be a more elegant solution at some point, but this isn't that bad for now

iwankaramazow15:02:50

I get the same feeling

denik15:02:59

if I have nested queries why not nested idents?

iwankaramazow15:02:10

this might be a use case for datascript

denik15:02:31

om.next could do it

denik15:02:21

wouldn’t switch frontend db just for that. Also the om.next datascript story is not ready yet

jlongster15:02:05

@denik I agree, though nested idents seems complicated to implement (how would you, the user, specify idents for arbitrary data?)

denik15:02:57

@jlongster: it seems to me that since they match the structure of the query you could express them as functions in a map

denik15:02:02

let me type something up

jlongster15:02:27

making coffee brb

denik15:02:55

(def state
  {:user {:id         1
          :first-name "David"
          :posts      [{:id    2
                        :title "CSP"}
                       {:id    3
                        :title "The X Doctrine..."}]
          :friends    [{:id         4
                        :first-name "Jane"}
                       {:id         5
                        :first-name "Jack"}]}})

(def by-id-ident (fn [prefix]
                   (fn [ent]
                     [(keyword (str (name prefix) "/by-id"))
                      (:id ent)])))

;; ident expr
[{:user {:ident-fn (by-id-ident :user)
         :posts    {:ident-fn (by-id-ident :post)}
         :friends  {:ident-fn (by-id-ident :user)}}}]

;; query expr.
[{:user [:id
         :first-name
         {:posts [:id :title]}
         {:friends [:id :first-name]}]}]

jlongster15:02:14

@denik: yeah, might work. I haven't given this enough thought to say much about it. you can easily implement your own tree->db, which duplicates stuff sure but it's possible

jlongster15:02:39

(ideally long-term Om would include common solutions, of course)

iwankaramazow15:02:53

From the 'thinking with links' tutorial, the root query is: '[{:items [:id :title [:current-user _] }] What if current-user has reification in the database? Is there an easy way to rewrite this to [:current-user {:items [:id :title]}], i.e. for remote querying?

denik15:02:59

@iwankaramazow: I think the idea is that link lookups are not for remote querying

denik15:02:22

you establish it in the initial state and modify going forward

iwankaramazow15:02:20

@denik: I 'fixed' it by placing the equivalent of [:current-user] in my app somewhere higher up the component chain to initiate the remote query. Feels wrong in my gut, but it gets the job done..

denik15:02:18

@iwankaramazow: I’m curious: what triggers the query?

iwankaramazow15:02:37

just the initial render of a page, i have a list of items which need an ident 'thinking-with-links' style. The ident has reification in the database. I solved it by giving my ItemOverview component a query with my [:current-user] -equivalent.

iwankaramazow15:02:08

In my parser I delay the load, so I can use om/db->tree

denik16:02:31

hmm not sure I understand from the gist

iwankaramazow16:02:14

moral of the gist, I just added a redundant query somewhere higher in the tree

Kamuela16:02:46

how should one approach learning om next if coming over from react and redux with es2015 js?

jethroksy16:02:10

any clojure(script) experience?

Kamuela16:02:57

about a week of it, just reading living clojure, brave and true, various code snippets, and watching a bunch of talks

jethroksy16:02:14

I've not been keeping up, but you should go through om.next's tutorials on GH

Kamuela16:02:25

i’m probably specifically looking for a way to dive into om because I don’t intuitively feel like there’s a large syntax gap that I need to overcome, I write small functions, do compositions, and try to be as immutable as possible with JS anyway

jethroksy16:02:27

the conj talk is worth watching for a whirlwind overview

Kamuela16:02:42

so being forced to dump any last non-functional ideas should be alright

Kamuela16:02:21

I did watch that one

Kamuela16:02:49

I think I’ll walk through the github as you’ve said, i started and no reason why I shouldn’t continue

jethroksy16:02:51

tony has an amazing interactive tutorial here: https://github.com/awkay/om-tutorial

jethroksy16:02:47

if you can work through that you should be good to go

Kamuela16:02:56

thank you jethroksy

hueyp17:02:11

@iwankaramazow: in Relay each component specifies fragments vs query, so something like

relay/IFragment
(fragments [this]
  {:user [:user/name]
   :overview [:overview/count]})

hueyp17:02:26

I had been wondering if links would accomplish the same thing in all cases for om.next

hueyp17:02:32

like if I would miss fragments

hueyp17:02:15

the most common case I used in Relay was an active item … current user, selected channel, etc, which seemed like links capture well

iwankaramazow18:02:23

@hueyp: if I recall correctly fragments are just 'fragments' of a query, i.e. pieces/parts. Fragments compose together to the root query. In Om it's all just a query...

hueyp18:02:59

yah, but you might want different query into different root

iwankaramazow18:02:51

both with om/set-query! and om/update-query! you can modify queries at runtime

iwankaramazow18:02:56

without breaking time travel

hueyp18:02:57

e.g. if a components query is [:user/name :overview/count]

hueyp18:02:12

the parent wants to pull those fields up into different roots

hueyp18:02:01

my understand is that you accomplish this doing [:overview/count {[:current-user _] [:user/name]}]

iwankaramazow18:02:06

to pull queries from a child, you should use (om/get-query subcomponent)

iwankaramazow18:02:43

example of an index-page I'm writing:

(defui IndexPage
  static om/IQuery
  (query [this]
         [(first (om/get-query nav/Navbar))
          (first (om/get-query overview/Overview))
          {:navbar/items (om/get-query nav/MenuItem)}
          {:overview/panels (om/get-query overview/OverviewItem)}
          ])
  Object
  (render [this]
          (let [{:keys [navbar/items title overview/panels]} (om/props this)]
            (dom/div nil
                       (nav/navbar {:title title :items items})
                       (spl/splash)
                       (dom/div #js {:className "content-wrapper"}
                                (dom/div #js {:className "content"})
                                (overview/overview {:panels panels})
                                (intro/intro)
                                (ft/footer))))))

hueyp18:02:01

so the childs query is [:user/name :overview/count], the parents [{[:overview/by-id 2] (om/get-query child)}]

hueyp18:02:06

that produces an invalid query

hueyp18:02:16

what I’m saying is you kind of want to say ...

hueyp18:02:51

[{[:overview/by-id 2] (om/get-query child :but-only-fields-for-overview)} {[:current-user _] (om/get-query child :but-only-fields-for-user)}]

hueyp18:02:57

e.g. fragments 😜

iwankaramazow18:02:46

a query is just data, i.e. a vector/list/map

hueyp18:02:47

I’m not sure if they are necessary or if children can always accomplish the same thing with links

iwankaramazow18:02:08

you can use functions to filter/modify queries to the result you want

iwankaramazow18:02:06

[{{:overview/by-id 2] (into [] (filter #(anonymous-function-which-filters-overview-fields) (om/get-query child))}]

hueyp18:02:02

ah, smart simple_smile

firstclassfunc19:02:49

Has anyone seen "Uncaught TypeError: Cannot read property 'render' of undefined” Thrown from the reconciler before? I am using alpha26

anmonteiro19:02:57

@firstclassfunc: that could happen due to a number of things. My suggestion is you use the latest alpha and if it's still happening make a minimal case

hueyp21:02:38

is there something that forces whether om tries a query with a remote or not?

hueyp21:02:03

my parser is returning {:value :loading :remote true} but its never being called with a remote target

anmonteiro22:02:40

I just wrote about creating Om Next reloadable devcards. The dom-node approach and the current Om Next helpers in Devcards blow away the local state on reload. Read on to see how to make it work https://twitter.com/anmonteiro90/status/694281787657314304

pithyless22:02:57

@hueyp: correct me if I’m wrong, but doesn’t the reconciler :send fn get called when parser returns :remote?

hueyp22:02:47

the parser gets run with / without a remote target set … so if you have 2 remotes, its run once without a remote, once with the first remote, once with the second remote

hueyp22:02:54

at least this is my understanding at the moment

hueyp22:02:23

the issue I’m having is that this components query is only being parsed without a remote. I’m wondering if I have to hint at om or something

nano23:02:27

How would I, in om next, create something similar to the om-prev tutorial, where it only allows entering non-numbers in an input? In the old one it always caused a re-render allowing the input box to keep only valid values, but I can't get that to work now. Tried both transacting to app-state, and using local state.

nano23:02:37

As when I transact the old value, it will not cause a re-render. Same with set-state with the same value again.

nano23:02:13

I tried supplying the key that changes as a last parameter to transact, but that causes a JS error, "Uncaught TypeError: Cannot read property 'add' of null"

nano23:02:43

Ah.. the error was because I had the key to re-read outside the query, but moving it inside still doesn't help, other than getting rid of the error message.