Clojurians
#om
<
2016-01-23
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

drcode01:01:56

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)

maackle01:01:47

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.

drcode01:01:24

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

maackle01:01:02

Yeah the function name ends with a bang, be careful simple_smile

tmorten01:01:43

@tony.kay: thanks again for all your help

drcode05:01:24

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.

danielstockton11:01:36

@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

kauko11:01:03

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

kauko11:01:17

very interesting article and discussion

anmonteiro14:01:42

@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

dnolen14:01:53

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

dnolen14:01:36

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

anmonteiro14:01:40

@dnolen: it seems like a useful utility to me

dnolen14:01:49

@anmonteiro: are you using it for something?

anmonteiro14:01:51

although I haven't used it as well 😄

anmonteiro14:01:20

I imagine it could be using for routing?

anmonteiro14:01:24

at least to some extent

dnolen14:01:40

right maybe, in anycase no need to doc right now

dnolen14:01:57

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

dnolen14:01:30

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

anmonteiro14:01:53

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

dnolen14:01:05

@anmonteiro: ok will take a look later today

anmonteiro14:01:13

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

anmonteiro14:01:34

@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

anmonteiro14:01:05

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

dnolen14:01:43

well there’s actually a few things

dnolen14:01:48

validating query grammer

dnolen14:01:55

validating ident value

dnolen14:01:12

so we would want helpers for that stuff and call that

dnolen14:01:35

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

dnolen14:01:59

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

dnolen14:01:17

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

anmonteiro14:01:46

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

dnolen14:01:57

less so the number of invariants

dnolen14:01:11

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

dnolen14:01:28

bad query grammar is a huge source of this

dnolen14:01:36

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

dnolen14:01:45

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

anmonteiro14:01:25

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

dnolen14:01:40

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

stuartsierra15:01:43

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

dnolen15:01:11

@stuartsierra: blizzard-y!

pupeno15:01:52

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

anmonteiro16:01:10

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

dnolen16:01:45

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

anmonteiro16:01:13

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

dnolen16:01:24

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

dnolen16:01:53

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

anmonteiro16:01:30

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

dnolen16:01:51

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

anmonteiro16:01:07

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

dnolen16:01:23

@anmonteiro: that one should be left alone

dnolen16:01:31

since that works with things which are not idents

dnolen16:01:46

keywords, components, and idents all work

pupeno17:01:33

@dnolen: awesome. Thanks.

nxqd18:01:08

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

anmonteiro19:01:22

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

anmonteiro19:01:30

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)

anmonteiro19:01:20

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

jlongster19:01:44

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)

anmonteiro19:01:12

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

anmonteiro19:01:58

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

jlongster19:01:59

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

anmonteiro19:01:46

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

anmonteiro19:01:03

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

jlongster19:01:25

@anmonteiro: I see what you mean, thanks

jlongster19:01:25

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

anmonteiro19:01:02

@jlongster: would love to see how that turns out

jlongster19:01:46

@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

anmonteiro20:01:06

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

jlongster20:01:28

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

nxqd20:01:38

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

nxqd20:01:41

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

nxqd20:01:08

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

anmonteiro20:01:48

@nxqd: haven't looked into it

jlongster20:01:40

@nxqd: agreed

dnolen20:01:33

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

dnolen20:01:45

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

dnolen20:01:23

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

dnolen20:01:32

that’s what default-extract-errors is about

dnolen20:01:25

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

nxqd20:01:58

totally agree simple_smile

jlongster21:01:26

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

jlongster21:01:30

{: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"}}}

jlongster21:01:20

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

jlongster21:01:08

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

jlongster21:01:22

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

iwankaramazow21:01:59

I'm currently trying to do the same thing

jlongster21:01:41

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

jlongster21:01:58

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

iwankaramazow21:01:19

I'm manually writing a read function

iwankaramazow21:01:20

does datascript support "reverse lookups"?

dnolen21:01:47

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

dnolen21:01:54

I don’t recall whether DataScript supports or not

jlongster21:01:11

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

jlongster21:01:21

doubt I'll support this, just thinking about it

iwankaramazow21:01:25

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

jlongster21:01:43

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

jlongster21:01:57

*without any need

jlongster21:01:21

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