This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-16
Channels
- # admin-announcements (44)
- # adventofcode (2)
- # avi (1)
- # beginners (22)
- # boot (328)
- # cider (1)
- # cljs-dev (6)
- # cljsrn (29)
- # clojure (164)
- # clojure-chicago (1)
- # clojure-dev (7)
- # clojure-nl (5)
- # clojure-russia (73)
- # clojure-seattle (1)
- # clojure-turkiye (2)
- # clojured (1)
- # clojurescript (98)
- # core-async (6)
- # cursive (26)
- # datomic (9)
- # editors (5)
- # emacs (41)
- # events (3)
- # garden (2)
- # hoplon (125)
- # ldnclj (18)
- # om (178)
- # omnext (8)
- # onyx (5)
- # parinfer (1)
- # proton (5)
- # re-frame (20)
@wilkerlucio: nice poster đ He looks like a legendary in a movie xD
@nxqd: hehe, I found it very cool too, I believe it was made by the cognicast team
it reminds me of final fantasy, like an old FF 7 poster
I am trying to use om.next with a remote. My initial data is an empty atom and I am using datomic on the backend. I have a root component, a list component and a item component. When I pass normalize = true
to the reconciler my item component is just passed the identity, not the full object. I know I am missing a key concept but I just canât figure it out
here is my code, https://gist.github.com/iwillig/dd07668352df3035ad82
Hi everyone ! Is it me or the tutorial âThinking with Links!â is broken ? I remember it was working weeks ago. I have the impression that om/tree->db
ignores the :current-user key in the init-data
@hmadelaine: Seems ok for me on 28/29-snapshot - the only thing I had to fix was a missing nil -> " (dom/div (dom/h2 nil "A List!â)â. But that is cosmetic. đ
:thinking_face: thanks @griffio. I will investigate further then
@hmadelaine: I take it you meant âdb->treeâ and not âtree->dbâ, the âThinking with Links!â uses "db->treeâ. Just in case you have it reversed đ
@griffio: I was referring to the implicit tree->db in the add-root!
@hmadelaine: Ok - let me know if want me to confirm anything that you may be seeing. Happy to check đ
@griffio: Ok thanks
When playing with an om.next parser by hand, I'm struggling to find the best way to express a query for a specific item
To be a bit more clear, supposing i'm working with the denormalization tutorial at https://github.com/omcljs/om/wiki/Components,-Identity-&-Normalization
@dnolen: playing with the parser i can easily get a list of entries as described in the tutorial:
but if I query (parser {:state st} '[[:person/by-name "foo"]]) i cannot access that entry
my understanding was that by querying an "ident" i would get back the results of what I expose in om/IQuery as component fields
I understood om/IQuery (query [this]) as "this is what I need", and om/IIdent (ident [this]) as "this is how to get to it"
this is not expressed in this way anywhere in the documentation around queries or ident
@a.espolov: I donât know what you are asking
so based on that ident, the parser is able to return the full props for the corresponding item, right?
@pvr: The ident states which data a component represents but the parser only processes the query (of the root component).
You can have idents in your query but it's up to you to implement :read
in the parser so it resolves them into the actual data they represent, e.g. by normalizing your data with db->tree
or by using things like (let [st @state] (get-in st (:some-ident params)))
.
@jannis: (by I have this, I mean, i have read implems for mhy idents to go look-up the needed data)
It turns out I have to specify the root components all queries that will be used in the child components?
@dnolen: I haven't followed the news closely - did anything happen on the path optimization front yet? I'm using db->tree
on an app state with about 40 linked entities, with up to 4-5 levels of recursion via '...
and the query takes about 150ms. Even with memoized db->tree
it takes about the same. I wonder how I can optimize this and where the majority of query time is most likely spent.
@a.espolov: in the sense that the root component has the total query only
@dnolen: It turns out even if I need a list of cities. Data will still be sought by the parser?
@a.espolov: you should re-read what Iâve been saying
If a component uses :db/id
as its key-fn, where and how should I look for it? I assume in the indexer?
Right, with :pathopt true
it complains if there is no read :node/by-id
implementation. Makes sense.
@jannis right but this goes back to my point about parse which people really need to think about
Also, the fact that it was complaining that read :node/by-id
was not implemented is just a result of using defmulti
, which obviously has nothing to do with Om itself.
yes and also the questions that @thomasdeutsch and @tony.kay have are really addressed by this
@dnolen: hmm Iâm not sure this helps. I want to lookup a component based on db/id
and call an instance-method on it.
Ok, already got pathopt working with an ident-based read in parallel to this discussion and it is blazingly fast.
Funny. At the top level, the ident-based "shortcut" is still slow but one level further down it's near instant. But I guess that makes sense - the further at the top you read, the more work db->tree
still has to do (if you use it, that is).
I think i got to the bottom of what I was after. If using a parser built from om/parser and dispatching with a defmulti based on om/dispatch, when querying for '[:entity/by-foo "entityid"] I wasn't able to figure out where "entityid" was fed. apparently it's in the :query-root field of env.
@dnolen: is there a top-level way to lookup the component based on its db/id
from props?
@dnolen: thanks! I think that will do! Using datascript and was under the impression Ident would not be necessary
@griffio: I have cleaned my repository, pull a fresh copy of Om 29-SNAPSHOT but still did not managed to make tutorial âThinking with Links!â to work. I tried with 28 it does not work. But with 27 it is OK @dnolen : any obvious reason why it is broken since 28 ? Thanks
@hmadelaine: hrm no idea
ah, never saw that one, thanks @hmadelaine
@dnolen: the current-user email does not show up
@hmadelaine: ok, will have to take a look later
@dnolen: I have the impression that om/tree->db
ignores the :current-user key in the init-data
@hmadelaine: there were some other fixes so that support may have regressed, will make sure there is a test to cover this regression when I fix it.
@dnolen: Ok, thanks. I have done this tutorial again after listening to the excellent http://blog.cognitect.com/cognicast/093
Hi @pyr ! You enjoy doing some Om.Next đ
Yes, Michael Parenteau is a great artist !
Iâm seeing correct normalization in (om/tree->db RootView init-data true)
, but incorrect on read (`@state` is wrong). It must be that a mutation Iâm doing messes up the tree, yeah?
@dnolen: Could you please have a look on issue that we have with React Native + Om-Next ? https://clojurians.slack.com/archives/cljsrn/p1450276969001160
TL;DR: Om-Next using React
global in 3 places. RN doesnât use any globals, but works though modules require. If we would be able to configure those 3 places and pass RN functions we would eliminate any hacks with global creation and advanced compilation
@artemyarulin: OK but this doesnât seem very important or hard to work around
Got it, thanks
just pushed a lein template for Om & Om Next based on the architecture I've been using, hope it's helpful for others
Should it be possible to transact!
against the reconciler and provide an Ident
that needs to be re-read, and have all components with that Ident
re-render?
@chris-andrews: that should work yes
@dnolen: Awesome, thanks. I am currently trying and failing, but I think my read functions are to blame. Just wanted to make sure I wasnât after something that isnât intended to work
is the Thinking With Links tutorial out of date? the example code doesnât seem to read [:current-user _]
at all
@joshfrench: issue already been reported
@dnolen: db->tree
seems ok with respect to [:k _]
idents. Just ran (and even embellished) tests on tip of master
@joshfrench: I copied and pasted the tutorial into master - works fine