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.

This component does display on the screen...it just prints "Hello, world!!"

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.

oh, okay. it also returns false as can be seen in my REPL interaction above.

Oh right sorry I missed that.

@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

OK

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

They get merged into the root of the app state rather

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

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?