Fork me on GitHub
#om
<
2016-05-17
>
ag00:05:49

@danburton: hey Dan… I think IQueryParams is what you need

ag01:05:54

errr… someone please help me with a query. if I have a data like this

[{:foo :wack}{:foo :quack}{:foo :wack}{:foo :stuck}]
and I need to select only items where (= :foo :wack) how should the query look like?

ag01:05:18

basically I need to render 2 lists in one of them I need to include everything that (= :foo :wack) and in the second I need to include everything that (= :foo :quack)

ag01:05:50

how do I do that?

ag01:05:21

I should be able to do this without having to declare 2 (same looking components)

jimmy03:05:48

@ag: let's say you have that data at root of db like this :data [ ... ;; your data ]

jimmy03:05:06

you can define 2 read funcs, like this wack-items and quack-items each of those you just return (filter (fn [[k v]] (= v :wack / :quack)) (:data @state)))

ag03:05:07

@nxqd: I think I solved it with parameterized query

jimmy03:05:17

ah ok, it's better with parameterised in this case 🙂

pedroiago14:05:29

I have a question. I've just took the macro approach as in om.dom to create macros for some webcomponents (instead of wrapping them with defui). But does that means I am not taking advantage of om shouldComponentUpdate hook? if so, is there a way I can add it without giving up on the macro approach?

anmonteiro20:05:17

@dnolen: I get the feeling this has worked before. Is this supposed to work?

(defui User
  static om/Ident
  (ident [this {:keys [id]}]
    [:user/by-id id])
  static om/IQuery
  (query [this]
    [:id :user/name {:user/posts (om/get-query Post)}]))

(defui Post
  static om/Ident
  (ident [this {:keys [id]}]
    [:post/by-id id])
  static om/IQuery
  (query [this]
    [:id :post/title :post/content {:post/authors (om/get-query User)}]))

anmonteiro20:05:28

as in the circular reference between users and posts

anmonteiro20:05:34

probably got to define some other component which doesn’t have the circular reference. something like Author or something

cmcfarlen20:05:20

@anmonteiro: I've run into this and ended up making a 3rd component. It worked out because it turned I needed a bit different query the other way. Still its probably common.

cmcfarlen20:05:57

I wonder if you could use the back reference syntax from datomic to resolve (or detect) these circular references. So use {:users/_posts (om/get-query User)} instead

jasonjckn21:05:00

@iwankaramazow: just reading your answer now, thanks!!

jasonjckn21:05:21

@dnolen: thanks for new release

dnolen21:05:31

@anmonteiro: pretty sure that never worked

dnolen21:05:17

currently not sure how it would since there’s no way to control the depth of that kind of recursion

jasonjckn21:05:52

is om.next ready for production usage?

jasonjckn21:05:03

(battle tested by anyone)

dnolen21:05:18

@jasonjckn: some people are building production stuff with it yes

dnolen21:05:43

there are still edge cases here and there but it’s slowly coming together

ag21:05:55

@dnolen: Om Next is amazing! You guys are awesome! I just convinced my team to use it for our next project.

ag21:05:46

basically I bet my career on it - team agreed, now I have to become an expert in very short time and build something tangible and evangelize everyone in my team. @dnolen - no pressure 🙂

jasonjckn21:05:24

@dnolen: do you offer consulting services for om.next?

jasonjckn21:05:33

@ag cool, i'm in the process of evaluating various stacks for the v2 of our product

jasonjckn21:05:17

does your team already know CLJS?

ag21:05:18

we are Clojure shop and yes, a few people know CLJS, but we have few front-end engineers that still hanging around Rails realm

jasonjckn21:05:21

our frontend team is only familiar with react/redux/js atm

jasonjckn21:05:27

trying to get them up to speed on cljs

ag21:05:15

for the sake of a few people (including myself) who think that Clojurescript is the best way to target front-end I have to succeed with Om Next. or Product may decide otherwise (bitter reality)

dnolen21:05:42

@jasonjckn: not currently no, pretty busy at Cognitect

jasonjckn21:05:09

@dnolen: oh ok, and I guess we can't hire you via cognitect either?

dnolen21:05:45

@jasonjckn: I don’t work on consulting stuff, that said a few people have been playing around with Om Next and quite a few people are familiar with Om from other projects

jasonjckn22:05:43

dnolen: do you work on datomic?

jasonjckn22:05:06

i would love to know how much cognitect invests in datomic

jasonjckn22:05:24

if it's a small fraction of their revenue/future, or a big deal

ag22:05:34

sorry for breaking the conversation: I’m struggling with something here, can someone guide me please. so I need to render 2 components that differ only by their IQueryParam, so what's the best way of doing something like that? my initial thought was to create one component and then use set-query! but I couldn’t make it work

ag22:05:10

@jasonjckn: I assume some-component should be a factory, right?

jasonjckn22:05:50

some-component is what the factory returns when called afaik

jasonjckn22:05:03

i think in the examples they call set-query! on this

jasonjckn22:05:07

within the component itself

jasonjckn22:05:01

(om/set-query! 
  (om/class->any reconciler AnimalsList)
  {:params {:start 0 :end 5}})

ag22:05:03

still unclear how to get 2 components (factories derriving from same component) with different params and render them in another component

ag22:05:24

how do I use a query (as a subquery) from a component that has a parametrized query?

ag22:05:06

guys, please someone help me. here. I have a component with a query that looks like this:

static om/IQuery
  (query [this]
    '[(:ledger/data {:account-type ?account-type})])
now I need to render 2 instances of this component in another component, where: 1st would have :account-type :checking 2nd would have :account-type :saving Seemingly trivial task and yet I can’t find the right way of doing this.

selfsame23:05:08

@ag: well you would add a read method that checks the params to return specialized data. I don't use params much, maybe there is a simpler way to do this in your use?

ag23:05:53

yeah I understand that if I set params I would probably have to have 2 different read methods. that dispatch on something like [{data/fruits {:kind :apples}}] and [{data/fruits {:kind :oranges}}]

ag23:05:37

but I still don’t know how to set params for instances from parent component

ag23:05:02

I can’t find a single example where same component is reused with different parameters