This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-01
Channels
- # aatree (1)
- # admin-announcements (11)
- # beginners (77)
- # boot (73)
- # braid-chat (29)
- # cbus (3)
- # clara (3)
- # cljs-dev (16)
- # cljsjs (2)
- # cljsrn (68)
- # clojure (149)
- # clojure-austin (1)
- # clojure-czech (2)
- # clojure-miami (8)
- # clojure-poland (28)
- # clojure-russia (165)
- # clojure-ukraine (1)
- # clojurebridge (3)
- # clojurescript (64)
- # community-development (1)
- # core-async (27)
- # core-matrix (2)
- # cursive (38)
- # data-science (2)
- # datavis (4)
- # datomic (3)
- # dirac (78)
- # emacs (10)
- # events (1)
- # funcool (6)
- # hoplon (25)
- # immutant (2)
- # jobs (3)
- # ldnclj (34)
- # luminus (4)
- # mount (23)
- # off-topic (26)
- # om (121)
- # onyx (320)
- # other-lisps (1)
- # proton (13)
- # re-frame (33)
- # yada (3)
@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.
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?
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.
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 ;-))
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
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.
this was fantastic : https://awkay.github.io/om-tutorial/#!/om_tutorial.E_State_Reads_and_Parsing
how to get the root component from the read function ? In mutate we can (:root @(:state reconciler))
@geraldodev: there's a function for that
(om/app-root reconciler)
Thank you @anmonteiro. Now I got it, a function for (:root @(:state reconciler)). Sweet
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 ident
s for each item.
@denik: it's the same as making 'normal' idents
@iwankaramazow: yep works thanks!
@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?
@anmonteiro: yes maybe - it’s the case where you can control the behavior
@dnolen: makes sense, thx
is it an anti-pattern to create a component just with om/Ident
and om/IQuery
methods for normalization, no rendering?
@jlongster: is not
there may be more support for that later since you might want normalization support server side
do often, when I don’t need additional components for deeply nested data I find myself normalizing into the app state manually
@denik: I tried something like this with the pattern @jlongster described above
Just make components with it's sole purpose Ident
@iwankaramazow: can you link it?
@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
wohoo thanks @jlongster
feels like there might be a more elegant solution at some point, but this isn't that bad for now
I get the same feeling
this might be a use case for datascript
wouldn’t switch frontend db just for that. Also the om.next datascript story is not ready yet
@denik I agree, though nested idents seems complicated to implement (how would you, the user, specify idents for arbitrary data?)
@jlongster: it seems to me that since they match the structure of the query you could express them as functions in a map
(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]}]}]
@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
ok think I'm on the right track here - https://gist.github.com/selfsame/0e34dbad168f345118f2#gistcomment-1685878
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?
@iwankaramazow: I think the idea is that link lookups are not for remote querying
@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..
@iwankaramazow: I’m curious: what triggers the query?
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.
In my parser I delay the load, so I can use om/db->tree
moral of the gist, I just added a redundant query somewhere higher in the tree
how should one approach learning om next if coming over from react and redux with es2015 js?
about a week of it, just reading living clojure, brave and true, various code snippets, and watching a bunch of talks
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
I think I’ll walk through the github as you’ve said, i started and no reason why I shouldn’t continue
tony has an amazing interactive tutorial here: https://github.com/awkay/om-tutorial
@iwankaramazow: in Relay each component specifies fragments vs query, so something like
relay/IFragment
(fragments [this]
{:user [:user/name]
:overview [:overview/count]})
the most common case I used in Relay was an active
item … current user
, selected channel
, etc, which seemed like links capture well
@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...
set-query!
?
both with om/set-query!
and om/update-query!
you can modify queries at runtime
without breaking time travel
my understand is that you accomplish this doing [:overview/count {[:current-user _] [:user/name]}]
to pull queries from a child, you should use (om/get-query subcomponent)
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))))))
so the childs query is [:user/name :overview/count]
, the parents [{[:overview/by-id 2] (om/get-query child)}]
[{[:overview/by-id 2] (om/get-query child :but-only-fields-for-overview)} {[:current-user _] (om/get-query child :but-only-fields-for-user)}]
a query is just data, i.e. a vector/list/map
I’m not sure if they are necessary or if children can always accomplish the same thing with links
you can use functions to filter/modify queries to the result you want
[{{:overview/by-id 2] (into [] (filter #(anonymous-function-which-filters-overview-fields) (om/get-query child))}]
Has anyone seen "Uncaught TypeError: Cannot read property 'render' of undefined” Thrown from the reconciler before? I am using alpha26
@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
my parser is returning {:value :loading :remote true}
but its never being called with a remote target
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
@hueyp: correct me if I’m wrong, but doesn’t the reconciler :send fn get called when parser returns :remote?
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
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
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.
Thinking about this one, https://github.com/omcljs/om/wiki/Basic-Tutorial
As when I transact the old value, it will not cause a re-render. Same with set-state with the same value again.