Fork me on GitHub
#om
<
2016-01-05
>
tony.kay00:01:08

to you as well

tony.kay00:01:37

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

dnolen00:01:55

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

dnolen00:01:07

it’s nice that your solution was so simple

tony.kay00:01:24

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

tony.kay00:01:26

just not optimized

dnolen00:01:18

yeah not sweating that yet simple_smile

dnolen00:01:42

@anmonteiro: merged does that actually close 550?

dnolen00:01:01

this is awesome stuff simple_smile

tony.kay00:01:43

nice when algorithms have such easy expansions

adammiller00:01:34

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.

anmonteiro00:01:07

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

dnolen00:01:43

@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)

dnolen00:01:49

@anmonteiro: thanks for the confirm

anmonteiro00:01:55

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

anmonteiro00:01:12

nvm, you're ahead of me

dnolen00:01:13

I closed the dupe

anmonteiro00:01:42

I wasn't getting the emails

anmonteiro00:01:52

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

tony.kay00:01:12

thanks for the assist

anmonteiro00:01:14

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

adammiller00:01:33

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

krchia02:01:17

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

krchia02:01:41

sorry i got it

jimmy07:01:55

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"}}]}}

jimmy07:01:31

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

simonb08:01:21

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

simonb08:01:23

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

jimmy08:01:47

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

taylor.sando09:01:27

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

#om/id [44].

anmonteiro10:01:55

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

djebbz10:01:13

Hello everyone

djebbz10:01:17

Happy 2016

djebbz12:01:41

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 ?

djebbz13:01:04

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

djebbz13:01:32

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

djebbz13:01:55

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.

djebbz13:01:37

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

hugod13:01:02

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

denik13:01:38

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

djebbz13:01:52

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

hmadelaine14:01:47

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]))}
                "+”)

djebbz14:01:16

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

djebbz14:01:01

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.

anmonteiro14:01:20

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

denik14:01:57

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

anmonteiro14:01:14

@denik: recursive queries are supported in Om Next

denik14:01:35

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

denik14:01:24

using datascript

anmonteiro14:01:04

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

anmonteiro14:01:50

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

denik14:01:01

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

djebbz14:01:21

Thanks @anmonteiro ! Lots to study simple_smile

geraldodev16:01:41

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 ?

anmonteiro17:01:21

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

anmonteiro17:01:52

working on a patch

anmonteiro17:01:05

@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 ?

anmonteiro17:01:22

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

anmonteiro17:01:17

just like tree->db calls normalize*

dnolen17:01:24

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

hugobessaa17:01:57

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

tony.kay18:01:47

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

adammiller18:01:05

@hugobessaa: what are you wanting to test?

anmonteiro18:01:40

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

anmonteiro18:01:01

so the result was actually valid

anmonteiro18:01:18

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

tony.kay18:01:33

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

tony.kay18:01:44

be interested to see it

anmonteiro18:01:57

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

tony.kay18:01:59

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

hugobessaa18:01:26

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

bplatz18:01:15

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.

bplatz18:01:50

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

bplatz18:01:08

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

bplatz18:01:59

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

bplatz18:01:27

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.

adammiller18:01:14

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

bplatz19:01:08

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.

peeja21:01:24

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

peeja21:01:30

Anyone remember what changed there?

dnolen21:01:05

@peeja: state has to be a map

peeja21:01:25

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

peeja21:01:38

Is there more I should be doing?

dnolen21:01:00

@peeja: don’t think so

tony.kay21:01:19

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

tmorten21:01:17

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...

tmorten21:01:10

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

dnolen21:01:59

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

tmorten21:01:22

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...

peeja21:01:26

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

tmorten21:01:46

@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

settinghead21:01:54

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.

peeja21:01:36

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

peeja21:01:02

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

tmorten21:01:03

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

peeja21:01:48

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.

tmorten21:01:48

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})?

dnolen21:01:42

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

peeja21:01:56

@tmorten: Yeah, that would be pretty weird.

peeja21:01:25

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

peeja21:01:42

Isn't it somewhere in your app state db?

peeja22:01:07

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

tmorten22:01:04

@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...

tmorten22:01:07

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

peeja22:01:03

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

tmorten22:01:46

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

tmorten22:01:18

@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?

anmonteiro22:01:03

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

tony.kay22:01:16

I am just reading over the code

tony.kay22:01:20

oh right...the to-many case

tony.kay22:01:28

hetero collections

tony.kay22:01:42

I keep thinking about just the to-one case

tony.kay22:01:19

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

dnolen22:01:14

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

dnolen22:01:26

let’s just wire in an “entity” cache

anmonteiro22:01:26

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

dnolen22:01:54

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

dnolen22:01:16

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

dnolen22:01:28

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

anmonteiro22:01:27

@dnolen: that would definitely be cool

anmonteiro22:01:50

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

anmonteiro22:01:04

or you meant to be included in this same pR?

dnolen22:01:30

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

dnolen22:01:33

lets just fix it in one go

anmonteiro22:01:57

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

anmonteiro22:01:22

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

anmonteiro22:01:34

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

dnolen22:01:11

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

dnolen22:01:19

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

anmonteiro22:01:14

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

anmonteiro22:01:24

from where I see it

anmonteiro22:01:57

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

jannis23:01:43

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.

jannis23:01:18

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.