Question: Suppose I have a root component that has tabs, and each tab has another, structurally unique component in it. What is the "best practice" for loading the data for the child components only when a tab is brought into the foreground? Since the om/IQuery function is static, I can't use that to accomplish my goal... do I need to use some kind of query parameterization trick? (This question seems super basic, I fear I'll slap my forehead when I hear the answer)

I'm not too experienced, but to me it seems you could do it either by updating the query params, or by updating the query itself, when the tab changes. om/set-query! can do both.

@maackle: That sounds like the right answer- Thanks! I need to read the code involving om/set-query! more closely- it seems like a potentially dangerous function

Yeah the function name ends with a bang, be careful

@tony.kay: thanks again for all your help

Answering my own question on lazy loading of child components: Instead of going the "set-query!" route, I decided instead to simply check if child components are visible in my parser "read" functions, by referencing the state- If not, I simply short circuit the recursion into that child's query during parsing- This prevents any "remotes" from triggering on hidden components, causing the component to only load lazily when it reaches visibility.

@yenda: I wasn't trying to say everyone should switch to om.next -I'm glad that people like reagent - just wish they wouldn't go on about it so much in the comments to om posts

https://news.ycombinator.com/item?id=10946721 I don't know if this was already linked here

very interesting article and discussion

@dnolen: is focus-query meant to be public? I'm asking because it is indeed public atm but not in the Wiki docs. Happy to add it if it's supposed to be

@anmonteiro: still on the fence about that one since I haven’t actually heard that people are using it

a few things are public just so that more adventurous people who want to play around with custom query resolution don’t hit annoyances

@dnolen: it seems like a useful utility to me

@anmonteiro: are you using it for something?

although I haven't used it as well 😄

heh

I imagine it could be using for routing?

at least to some extent

right maybe, in anycase no need to doc right now

gotcha

I think we already have a lot of stuff and weirder things will be misleading

but if you find yourself using it, let me know!

will do

@dnolen: on another note, I'm quite satisfied with the invariant patch; it seems to me that it could also be used in people's code, not only in Om!

@anmonteiro: ok will take a look later today

but I might have missed something there; yep, let me know

@dnolen: I've also spent some time trying to figure out where to use it in Om. I wanted the patch to include at least one example for people to see it but at this point I couldn't make any error on purpose

was also going through the channel's most recent history but didn't find anything of help

well there’s actually a few things

validating query grammer

validating ident value

so we would want helpers for that stuff and call that

basically anything that is in the class of typical mistakes that newcomers make we should put invariants around

the strategy that React uses is a good one - a little bit annoying for people who know what they are doing

but a good way to control overwhelming confusion for people starting out

@dnolen: by strategy, do you mean using a large number of invariants?

less so the number of invariants

but looking for places where people would make typical mistakes that lead to cryptic errors

bad query grammar is a huge source of this

we don’t want to pollute our fns w/ this logic

we just want to know it’s going to work before we start

gotcha. I'll start by the ident validation later, definitely seems to be easier than query grammar validation

sounds good, I can probably knock out the query grammar thing later

@dnolen: How's the blizzard looking in Williamsburg?

@stuartsierra: blizzard-y!

Is it me or there's no way to perform a join and get all the joined attributes?

this is my data and query attempts: http://stackoverflow.com/questions/34841197/how-do-i-query-with-a-join-getting-all-the-data-in-om-next

@dnolen: I'm thinking that a good place to validate idents is in the indexer, specifically index-component!; do you have a better suggestion?

@anmonteiro: seems like an OK idea, since components must mount

@dnolen: exactly. it's something that's common to every component, it's going to mount. that was my line of thinking

@pupeno: [{:foo [*]}] should work

there may be edge cases where it doesn’t but that’s just a bug and issues should be filed

@dnolen: excuse me if this is just nagging, but I'm finding quite a few stray variables called ref; I remember you doing some ref-> ident refactoring; should I fix these where I'm finding them?

@anmonteiro: happy to take a PR that just fixes that

OK will do

@dnolen: there's also a ref->components function which is public. not quite sure what you want me to do there

@anmonteiro: that one should be left alone

since that works with things which are not idents

ah, right

keywords, components, and idents all work

@dnolen: awesome. Thanks.

@anmonteiro: I have a question regarding mutation, I can see that the {:value returned from remote is assigned to mutation dispatch key. Is it our work that we have to get the data out of it and merge to the application state. I mean in this example : todo/update << return new props to 'todo/update in state then we have to get it out and merge to todo/by-id. Is it normal to do this or there is a better workflow to do the same thing ? ( Does keys in mutation help ?

@nxqd: in short, yes. you can also override :merge-tree to your own liking

specifically, and if it suits your use case, I can imagine it being a multimethod as well (if you need different behavior according to the dispatch key)

@dnolen: I haven't submitted a corresponding issue for the ref->ident patch. Let me know if you'd like one to be filed

what is the difference of querying with a reference like [[:people/by-id 0]] and just using a parameter like [(:people/by-id {:id 0})] ? (assuming you implement the same lookup behavior in your read function)

@jlongster: given that assumption, I'd say there's no difference

depending where you use it, idents might be more helpful, though

ok, thanks. are references used anywhere else than a simple lookup query like that?

@jlongster: yes. denormalization uses them, so does path optimization

just 2 examples from the top of my head, there are more

@anmonteiro: I see what you mean, thanks

still working on my query expression -> SQL "compiler", trying to figure out the right way to interpret everything

@jlongster: would love to see how that turns out

@anmonteiro: it's a fun exercise, and helpful for learning the query syntax! I'll definitely put it up somewhere when I get it mostly working

cool stuff, will be on the lookout. I can imagine it being a standalone thing if it interprets the whole grammar

yeah, could be, we'll see if other wants to help maintain I'm at my max for OSS maintenance, heh, but definitely worth putting it up

@anmonteiro: now I can see the benefits of merge tree. Thanks again

@jlongster: it's a great idea. I can see there are many people want to do this as well, hopefully they will support the project

@anmonteiro @dnolen I can see that we are having default-extract-errors, is it for general errors ( both local and remote ) as well ?

@nxqd: haven't looked into it

@nxqd: agreed

@nxqd: it’s not for local errors, remote errors only

and not really for network level errors - you need to sort that out yourself in send

but for the very hard problem of remote errors we need a sensible way to propagate that information in a relatively declarative way

that’s what default-extract-errors is about

I’m pretty happy so far with the direction it’s going - it rounds out the whole story

totally agree

I have a question, let's see I can explain this. let's say I have this data:

{:items [{:id 0 :name "foo" :group [[:groups 1]]}
         {:id 1 :name "bar" :group [[:groups 1]]}]
 :groups {0 {:id 0 :name "group1"}
          1 {:id 1 :name "group2"}}}

I can query it with [:items [:group]] and will get back a map with :items and an array of group entities

is there a way to query the opposite way? get back data like this:

{:groups
 [{:id 0 :name "group1" :items []}
  {:id 1 :name "group2" :items [{:id 0 :name "foo"
                                 :id 1 :name "bar"}]}]}

I'm currently trying to do the same thing

datomic supports "reverse lookups" which seems like it's similar to this

]=\[a (18m old daughter typed that)

I'm manually writing a read function

does datascript support "reverse lookups"?

@jlongster: there’ s no specific support for that for the default DB

I don’t recall whether DataScript supports or not

@dnolen: ok, is that what reverse lookups would do? just trying to figure out what I should support in the SQL translation layer

yes

doubt I'll support this, just thinking about it

ok

@jlongster: why are you venturing into SQL territory, why don't you use datomic?

because I'm writing an app as a single bundle to distribute without any need to connect to a server. internally it stores data as a simple sqlite db because I need something as a simple db

*without any need

might be able to distribute datomic, I dunno, but I just need something simple and this is fun anyway

💪