This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-21
Channels
- # beginners (201)
- # boot (125)
- # cider (3)
- # cljs-dev (21)
- # cljsrn (165)
- # clojars (8)
- # clojure (332)
- # clojure-belgium (1)
- # clojure-gamedev (8)
- # clojure-russia (75)
- # clojure-spec (25)
- # clojure-uk (96)
- # clojurebridge (2)
- # clojurescript (130)
- # code-reviews (16)
- # cursive (26)
- # datomic (20)
- # devops (6)
- # emacs (6)
- # hoplon (90)
- # jobs (9)
- # luminus (2)
- # off-topic (4)
- # om (65)
- # onyx (5)
- # pedestal (4)
- # protorepl (6)
- # re-frame (34)
- # reagent (12)
- # ring (4)
- # ring-swagger (7)
- # specter (2)
- # test-check (8)
- # untangled (2)
- # vim (1)
- # yada (6)
what's the generic way to limit things in data based on query, e.g. if I have a query [:records [:title]]
, back-end returns whole thing e.g.: {:records [{:title "one" :id 1 :amount 3][:title "two" :id 2 :amount 4]}
, how in read
method I would limit things so it would return records only with titles?
@ag to return only specific fields of a record in the reader:
1. Grab parser
and query
out of the environment in the record reader
2. Instead of returning the record as the value for the reader, return (parser (assoc env :record record) query)
3. Write additional readers for each field of the record
Basically, the reader for the record has access to the query, but OmNext doesn't provide any "magic" for pulling the exact fields, instead you do this explicitly as described in the steps above, which will trigger recursive parsing of the children.
BTW, it's probably a good idea to name your fields :record/title
and :record/amount
etc to make it easier to write the additional readers (it's probably "best practices" these days anyway to use namespaced keywords in most situations)
However does (om/component? (om/factory HomeTab))
return true? My understanding of a component is an object that can be displayed on the screen.
Above @anmonteiro suggests to @jannis it can come from:
>the result of parsing might be empty
I'll post another minimal example which also still returns false for the component?
function call where I believe the parsing is not empty.
MyComponent is something like from the 'factory method' in OO design patterns. om/factory
is a function that takes this MyComponent factory and produces a component.
@dzannotti for your rest API wrapper you could borrow from here http://hueypetersen.com/posts/2015/02/22/thin-and-graphy/
Something I'm struggling with: How do you avoid writing a fully-recursive parser?
Each component's query is parsed in the context of its parent.
I don't see a way to "back out" of that context, i.e. to say "This component's query should be evaluated from the root of the application state."
But maybe I'm still missing something.
@stuartsierra if you want to read something in the context of the root of the app state you can use links
i.e. '[:current-user _]
^ assuming you have a normalized app state
Ahh, so idents are special.
My app state is normalized, but not by Om.next.
Thanks @anmonteiro, that at least gives me something more to try.
@stuartsierra there's a links tutorial in the wiki: https://github.com/omcljs/om/wiki/Thinking-With-Links%21
yes, looking at that now
they are resolved automatically when passed to om.next/db->tree
if you're rolling your own normalization you may want to make a special case for them too
@anmonteiro getting a bit confused about how to trigger route changes in compassus with pushy. Using set-route!
(compassus) does not update the token and using set-token!
(pushy) does not trigger a route change
Is there an example anywhere with this stuff working?
@danielstockton I'm not aware of any example but by the looks of it you just need to guarantee the other is called when you call one of those functions?
yeah, a hook into set-route! to trigger a set-token! would be all i needed
don't need a hook, i can just write my own function which does both
which is what I'm suggesting 🙂
yep, sorry, typing too quickly 🙂 i'll give it a go
the examples in Compassus's README just showcase the behavior when clicking an anchor for example
yeah, that works perfectly 👍
@anmonteiro I've been having fun playing with Compassus. The Oriens template was a great entry point 😀
awesome, great to hear
I was wondering about the setting params. Currently the handler is stored under :compassus.core/route key, but the params get merged into the route which was a little unexpected for me.
What happens if a component grabs data directly out of app-state, instead of receiving that data as 'props'?
@stuartsierra I suppose you'd lose the uni-directional flow of data. The app-state could change and your component wouldn't know.
@tmulvaney right, that's because Compassus manages the :compassus.core/route
key for you, but it delegates the route param management to the user
you can put it under whatever key you want, and add queries for that in your components
did you expect it would be more opinionated?
The tricky thing about making a wrapper for the set-token/set-route stuff is structuring things so there are no missing/circular imports. I need the history, app, reconciler to all be available and everything is quite intertwined
I have this function:
(defn set-route!
[reconciler route]
(let [current-route (compassus/current-route reconciler)]
(when (not= route current-route)
(compassus/set-route! reconciler route)
(pushy/set-token! history (bidi/path-for bidi-routes route)))))
trouble is it's missing history
which is defined in the core namespace...But I can't define this function in the core namespace because then I won't be able to require it anywhere (core requiring a namespace requiring core..)
ah, i may have seen a way 🙂
@anmonteiro I just didnt expect to see them merged in to the top level of the root state but having wrapped them in {:app/params my-map-of-params} I am now happy.
@tmulvaney PR welcome to make the README clearer
Is there a hook for post-merge? The merge fn has to return a map with {:keys .. :next .. :tempid} and I want to trigger a route change after doing the merge, not before
root component willUpdate?
Use case: login -> receive token -> merge token into state -> trigger root change to wherever the user is going
I can make it work in merge using a setTimeout but that's way too hacky
it actually works ok with a setTimeout of 0 ms but still might be a better way?
damn, i lost my a href click handling actually
@danielstockton I'm finally looking at your Compassus issue with Links
I don't think it's an issue after all
you didn't change the parser to account for the link
Link resolution only works when you use db->tree
if I change the parser in your example accordingly, then the title is displayed again
Oh, I see. I thought it would work with '_, thought it might call the parser with just the key for example
Didn't realise it was hooked into db->tree
@danielstockton It would if the '[:some/key _]
were at the root of the query going into the parser. The parser only calls read
with the keys at the root of the query; it's up to read
to decide what to do with the query that's joined at that key, if there is one. It could decide to call the parser recursively, for instance, in which case '[:some/key _]
would be at the root of the query passed into the parser at some point, and it would dispatch on :some/key
. Or it could choose to use db->tree
, which is essentially an optimized algorithm to accomplish the same thing for the most common cases. (Or it could choose to do something more interesting, if it needed to.)
Hey guys, I have a dilemma. Let's say I need a table-view component. Does it need to have query? If you say no, then whatever needs to be rendered in the component need to be passed via props, right? But then all that stuff need to travel down the ui-tree -> table-header, table-footer, header-cols, table rows, every single cell (let's say some cells may become components as well). Is that the right way, or table-view has to have a query? Then if I have multiple tableviews on the page, how do should I handle that?