to you as well

actually was good we did those at the same time, so it was fresh in our respective memories.

agreed

@tony.kay: so that PR is ready to go

it is

it’s nice that your solution was so simple

agreed...i don't love the ast transforms in the middle, but it is clean

just not optimized

yeah not sweating that yet

@dnolen: fix for #550 https://github.com/omcljs/om/pull/563

@anmonteiro: merged does that actually close 550?

the issue

@tony.kay: merged!

this is awesome stuff

nice when algorithms have such easy expansions

removes any reason for target to be nil too right? I was thinking there was some other code that could be removed because of that.

@dnolen: it does fix it, just confirmed by running the example in the issue

@adammiller: yeah there's probably some detail cleaning up stuff we’ll get to when I’m a little more confident about what we currently have (getting close)

@anmonteiro: thanks for the confirm

@dnolen: I think @tony.kay 's PR #560 should not be merged then. it tackled the issue in an opposite way. Right?

right

@anmonteiro: you mean 550?

nvm, you're ahead of me

I closed the dupe

I wasn't getting the emails

@tony.kay: I guess you don't need me anymore since the PR is merged ye?

correct

thanks for the assist

np, I'm off to bed then, getting late in Germany

night

maybe i’m misreading something but it seems like the first condition here is all that would ever execute: https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1419

any way to fit something like (def img (new js/image)) and (set! (.-src img) "img-src-name") inside an om component?

sorry i got it

hi guys, when I got the result from om next backend, the props is like this

{:project/page {:project/page [{:project/name "Project 1", :project/developer {:db/id 17592186045424, :developer/name "Phu My Hung 1"}}]}}

my question is, do I do something wrong ( it looks a bit messy ) ? Or it's normal that I have to dig in this map to get what I want which is project/name and project/developer

@anmonteiro: In your blog post I think the Union at the front of the node names should not be there

{:node/foo (om/get-query UnionFooNode) :node/bar (om/get-query UnionBarNode)}

can anyone explain to me what do transit reader and transit writer in om next server do ?

They help serialize/deseralize the om next tempid, such as

#om/id [44].

@simonb: hah! Thanks, damn copy paste; will update

Hello everyone

Happy 2016

I have a (beginner?) question about Om.next. I followed the tutorial Components, Identity and Normalisation successfully, and I want to toy with it in a certain manner but can't find how. Namely, I want to display people grouped by their :points, and be able to update all people with the same score. I don't know how to proceed. Is it the responsibility of another component to provide another view on the normalised data ?

I tried the following : (showing only code added to original tutorial)

clojure
(defmethod read :person/by-points
  [{:keys [state] :as env} key params]
  {:value (->> (get @state :person/by-name)
               ((fn [st]
                  (println st)
                  st))
               vals
               (group-by :points)
               (map (fn [[score persons]]
                      (let [names       (map :name persons)
                            mapped-name (into [] (map #(vector :person/by-name %) names))]
                        [score mapped-name])))
               (into {}))})

(defui Points
  static om/Ident
  (ident [this {:keys [points]}]
    [:person/by-points points])

  static om/IQuery
  (query [this]
    '[:name :points])

  Object
  (render [this]
    (dom/div nil (str (om/props this)))))

(def points (om/factory Points))

;; modified RootView

(defui RootView
  static om/IQuery
  (query [this]
    (let [person-query (om/get-query Person)
          points-query (om/get-query Points)] ;; <------ NEW
      `[{:list/one ~person-query} {:list/two ~person-query} {:person/by-points ~points-query}])) ;; <------ CHANGED

  Object
  (render [this]
    (println "Render RootView")
    (let [{:keys [list/one list/two person/by-points]} (om/props this)] ;; <------ CHANGED
      (apply dom/div nil
             [(dom/h2 nil "List One")
              (list-view one)
              (dom/h2 nil "List Two") 
              (list-view two)
              (points by-points)])))) ;; <------ NEW

The function in the :value of the read method for :person/by-points successfully group people by score, based on normalized data

But the "grouped-by" data is not part of the state atom. Also I have no idea how to make it so that everytime some data is changed, this "grouped-by" list is updated.

Feel free to point me to some direction, pretty sure I did nonsense everywhere.

@djebbz: You might take a look at https://github.com/omcljs/om/wiki/Queries-With-Unions if you haven’t already seen it.

how does thinking with links work in regards to datascript? https://github.com/omcljs/om/wiki/Thinking-With-Links%21

Indeed, haven't read those pages yet (as they're kinda unordered). Thanks !

Hi @djebbz: if you want to re render your group-by component you should add the key to the transact! function. Have a look at Why is my component not rerendered after transact!? in the FAQ https://github.com/omcljs/om/wiki/Om-Next-FAQ In Person you can try :

(dom/button
                #js {:onClick
                     (fn [e]
                       (om/transact! this
                                     `[(points/increment ~props) :person/by-points]))}
                "+”)

Thx @hmadelaine, indeed I forgot to add the key to transact. Will try and tell you

BTW, I stumbled upon this page with links to articles related to Om.next http://www.martinklepsch.org/posts/om-next-reading-list.html Pretty sure you know this already, but sharing anyway just in case.

@djebbz: I wrote a follow-up to that article which you can check here https://twitter.com/anmonteiro90/status/675051435512504320

does om.next make any sense to use with datascript though recursive queries don’t seem to be supported yet?

@denik: recursive queries are supported in Om Next

how?

or how do I get a top level query 20 levels into my component tree?

using datascript

@denik: see Om devcards from here https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/core.cljs#L242

@denik: I've written about query syntax yesterday here as well: https://twitter.com/anmonteiro90/status/684148857547165697

@denik: haven't tried it with datascript though so can't help there

@anmonteiro: I think what I’m really looking for is the top level part

Thanks @anmonteiro ! Lots to study

I want to capture the return of the messages sent to server. I know the transit-post (https://github.com/omcljs/om/wiki/Om-Next-FAQ) can be a place for that. I've been watching https://github.com/swannodette/om-next-demo/blob/master/todomvc/src/cljs/todomvc/parser.cljs and saw that all mutations were paired with a :value something, to force a re-read by the client. Do you think that transit-post is a good place to listen from return of the server ?

@dnolen: @tony.kay: managed to create a case where recursion limits don't work with unions; submitted https://github.com/omcljs/om/issues/565

working on a patch

@dnolen: db->tree's signature is accumulating arguments, some of which that are not meant to be used by people; do you agree that I move the behavior to a denormalize* private function and only keep the public sigs in db->tree ?

this would be part of the patch I'm working on for #565

just like tree->db calls normalize*

@anmonteiro: yes internal arguments should not appear in the public signature if possible

anybody knows how I can test an om component without rendering it?

@anmonteiro: what is the use-case? It worked with the case you had in tests

@hugobessaa: what are you wanting to test?

@tony.kay: it worked because whatever value you specified in my tests, it only had 1-recursion

so the result was actually valid

my patch is almost ready, you can tinker with my test cases in some minutes

Interesting: I tried zero (which did not recurse) and 1 (which did), which indicated the reduction of recusion levels was ok.

be interested to see it

this one was a mind bender, specially in what concerns different recursion limits in a union

😁

Yes, as I said. Interested to see the required patch

@adammiller: this: https://gist.github.com/hugobessaa/6a5b7dbbaa5658fc5a98

Basically what react shallow rendering gives to you: an object you can assert upon, instead of having to render the component to the dom

@tony.kay: https://github.com/omcljs/om/pull/566

Before I create a minimal case for this issues I'm having, I want to make sure I'm not doing something wrong as it seems others would have come up with the issue before I.

When merging results back from a remote, I'm using an ident as a key. This is resulting in the following error:

Uncaught Error: Invalid key [:any-ident "foo"], key must be ref or keyword

This error is thrown from the indexer at the protocol function: key->components after the queue is processing...

I'm just not seeing why this is an invalid key... so I'm not sure if the function itself should be getting the dispatch-key part out of the ident and not throwing this error.

sorry @hugobessaa i’m not sure of anything…maybe someone else could chime in and help

@adammiller: thanks

OK, please disregard... somehow a cached version of next.cljs kept making it into the build, even after lein clean. It explains several issues I was having.

Hmm. I'm working on upgrading from Om 0.8.8 to Om 0.9.0, and all of my calls to set-state! are complaining that the result of (get-state owner) doesn't satisfy IAssociative

Anyone remember what changed there?

@peeja: state has to be a map

The component has om/IInitState (init-state [_] {})…

Is there more I should be doing?

@peeja: don’t think so

@anmonteiro: Thanks, I'll have a look.

Hello All! I'm still learning me some Om.next and was wondering if anyone had a best practice to pass in initial state to a component. For instance, if I have a id to filter the component by? The tutorial shows how to use IQueryParams "inside" the component, but what about setting the initial values of those parameters outside of the component via make-root!? Maybe I'm coming at this completely wrong...

Om.prev I would set init-state when calling root to mount the component

@tmorten: there’s no way to do that neither for state nor queries

Just curious how people are approaching this ...perhaps dumping client side routing? Which is where I am trying to grab the ":id" to filter from...

@tmorten: Maybe what you're looking for is an ident query? Have the component look up the filter itself?

@peeja: From what I understand that would work inside my component if the component already knows what the ID is I'm looking for...either setting it manually in the query [:by-id 1]...what I want is to pass in the "1" from the routing library

is it possible to make the query/mutation/reconciliation part of om.next a thing of its own? the reason i’m asking is i’m writing a super lightweight javascript plugin, and React/UI component isn’t needed at this point, however i do need the ability to run graphql-like queries and mutations and send a batch to the server. i’ve been looking for alternatives. i haven’t found a graphql implementation in cljs (there are a few graphql-inspired ones, but mostly in clj only and are not well-maintained), but it seems that om.next already has most pieces of what i need built in, they are just not independent components.

@tmorten: I'm imagining a singleton ident, maybe referring to routing info, or maybe just to some standalone filter info. Something like [:filters _]

That will look up :filters at the root of the app state

@peeja: is there a way to do that even though I am using datascript as my global app state?

Oh, I haven't used it with datascript, so I don't know what happens there. But the parser will read the :filters key, so it's whatever the datascript integration does with that.

Would it be completely out of line to store another global atom of state and in the om/IQueryParameter (params [_] (let [id (:id @global-routing-atom)] {:id id})?

@settinghead: might be possible in the future but we’re not going to spend any time or effort on that now

@tmorten: Yeah, that would be pretty weird.

I'm not following why it's not something you can query for

Isn't it somewhere in your app state db?

Where would the parent component have gotten it from in your earlier implementation, to pass it in as an initial state?

@peeja: Well, yes. Ultimately, I'm trying to render another RootView that has it's own query into datascript state via the url routing. (defroutes persons "/persons/:id" [id] (om/make-root reconciller Person) What I need is the ID from the routing into the person component to render the right person...? That's why I'm thinking I might be needing to dump the client side routing...

So essentially every new route gets its "own" view of global state

Hmm. This may be an impedance mismatch between datascript and using routing this way

Really the route from browser is its own form of global state

@peeja: I think, perhaps the way to go is to mutate an entity inside of datascript that tracks the current route. Are there any examples of using a singleton ident?

@tony.kay: I answered your comment in the PR

I am just reading over the code

oh right...the to-many case

hetero collections

I keep thinking about just the to-one case

sweet, I get it now, thanks for all the work in the PR comment

@anmonteiro: so one thing we might as well get in there now since it will break people who memoized it before

let’s just wire in an “entity” cache

@tony.kay: np, it is out there now also for other people which might be interested

that is a atom wrapping a hash-map from ident to cached result

we only look in it if we have an ident in hand

should be a huge performance win for people using recursive queries as reported by @jannis

@dnolen: that would definitely be cool

but that makes up for a separate issue, don't you think?

or you meant to be included in this same pR?

PR *

@anmonteiro: normally would be separate but since this PR breaks the old memoizability

lets just fix it in one go

@dnolen: alright. other than that, does it look OK? I assume you have looked over it since you're providing feedback

@anmonteiro: yes

@dnolen: cool. probably won't get around to finish this today, but I don't think we're in a hurry

@dnolen: where would this entity cache live in your opinion?

@anmonteiro: sorry busy for a second and the idea may need some more thought because of changing recursion depth

let’s leave it be for now and I will gather my thoughts for tomorrow

@dnolen: gotcha. agreed wrt. changing recursion depth: I think it would make invalidation less trivial

from where I see it

actually I might have misinterpreted what you meant, after re-reading it again. I'll take some time to think about this

I've only used memoization with the [query data refs] arity so far, which would still be available. But it makes sense to allow all uses to memoized.

An entity cache would need to consider the current state during caching and lookups as well, not just an ident, since idents are links to "transient" data.