Fork me on GitHub
#om
<
2016-01-12
>
anmonteiro00:01:07

@dnolen: I've opened an issue with a minimal case

anmonteiro01:01:29

@dnolen: I might have found a solution to that last issue, but it might be WIP. Submitting a PR so I can get your feedback, is that OK?

anmonteiro02:01:42

this one was a doozy

jannis02:01:46

In case people are looking for a quick way to play with the Om Next query expression grammar: https://twitter.com/jannispohlmann/status/686743384082481152 simple_smile

anmonteiro02:01:21

@jannis: aren't you in Germany too?

anmonteiro02:01:35

guess I'm not the only one who's awake at 4AM

jannis02:01:08

Where do you live?

anmonteiro03:01:02

it's a cool place, very calm and lots of history

jannis03:01:19

Yeah, it's not know as the hottest, trendiest place (compared to Berlin and Leipzig) but it's beautiful and historic.

jannis03:01:55

I'm about to move to a place about which you could say similar things - Lübeck. 😉

anmonteiro03:01:21

ah, I'm not that familiarized with German geography yet simple_smile

jannis03:01:12

Dresden is also known for being a tech area (traditionally with AMD being located there etc.) - is that how you got there?

anmonteiro03:01:41

I got here to study at the TU Dresden

jannis03:01:10

Neat. Makes sense simple_smile

jannis03:01:18

Are you coming to ClojureD?

anmonteiro03:01:54

haven't thought about it

jannis03:01:42

Could be fun! I'm definitely considering it. We should hang out if you do simple_smile

anmonteiro03:01:00

I'll see about that

anmonteiro03:01:37

and let you know

anmonteiro03:01:40

off to bed now

jannis03:01:46

Yep, same here simple_smile

denik04:01:29

Is there a way to set default props in om.next?

krchia06:01:00

when should i put everything in one master om/component vs several (om/root ..)?

mudphone08:01:30

Is it still necessary to use an externs file for advanced mode compilation of Om Next apps?

mudphone08:01:01

but, that’s not for Om

juhoteperi08:01:57

@mudphone: Om doesn't change how ClojureScript compiler or Closure works, so yes, externs are required when using non-closure JavaScript libraries like React. But Cljsjs packages take care of that.

mudphone08:01:12

@juhoteperi: ah, okay, so I need to understand what’s going on with CLJSJS

meow08:01:59

#C0E66E1H7

jimmy10:01:36

hi guys, I have data returned from remote fetch but it doesn't seem to change the ui. After debugging I see that the application state in om next does change. What would be the problem here ?

danielstockton10:01:40

did you implement merge-tree to update your state?

jimmy10:01:46

@danielstockton: I didn't . But I assume that the default one would work just fine ?

jimmy10:01:02

my query is pretty simple

danielstockton10:01:47

it might but that's what is updating your application state so i guess start debugging around there

jimmy10:01:37

it's a good idea.

jimmy10:01:13

@danielstockton: hmm, I think there is something wrong here. I guess the app should be rerender after application state being merged. but it doesn't seem so .

danielstockton10:01:32

you need to pass keywords after the mutation to say what needs re-rendering

jimmy10:01:42

I guess that should be the case too. But how do i ? Is it the default-merge function you are talking about ? It returns keys next and tempids as well.

nano11:01:08

Humm.. mucking around with routing. Pretty much cargo culting. I do transact to change the route, the data passed includes both the child target, and the query params. I then, in the root component's willUpdate pick up the target from the next props, and then extract the query and query->ast, dig into the dst and replace the params with the requested ones, transform back, and apply the set-query. When I navigate my UI I can click the link targets and the second page is loaded, but the data is not there the first time (it's being fetched via reconciler :send), but if I go back to the main view and then dive down again into the intended target, the data is there. So it seems like componentWillUpdate is not such a nice place to set the query if it involves remote fetching, but I haven't got the data to load at all in any other way. Would appreciate some pointers.

anmonteiro11:01:11

@nxqd: pass the keywords you wanna re-read in the transact! vector

anmonteiro11:01:10

e.g. (transact! '[(do/stuff!) :key/foo]

anmonteiro11:01:02

If the app state is updating with the remote data, then you can rule out merge-tree

jimmy11:01:11

@anmonteiro: actually it's not the mutation. It's a remote fetch

anmonteiro11:01:04

@nxqd can you put together a minimal case?

jimmy11:01:31

let's see : the query in page component :

;; query in component page
[({:project/page [:project/name :project/description {:project/developer [:developer/name]}]} {:project/name "Erica"})]

;; response 
(defmethod read :dom-com/props
  [{:keys [parser query ast target] :as env} k params]
  {:value (parser env query target)})

(defmethod read :project/page
  [{:keys [state parser query ast target] :as env} k params]
  {:value {:project/page [{:project/name "Erica", :project/description "One is sure to enhance the dimensions of one’s desires, thoughts and spirits, while staying at Erica. It’s a classic mix of all that you were longing for in your dream house. It has meticulously designed spacious apartments with all the modern amenities in the thick of plush greenery which makes it a comfortable and cozy home. The residential apartments in Erica lets you reload unconditional bliss that leads to momentous way of living. Erica has lavish yet thoughtfully designed residences that carts comfort, content and care. Settle amidst life changing ambiance of this complex that gives you a chance to elevate your lifestyle for a lifetime. ", :project/developer {:developer/name "Eisha Group"}}]}) 
the setup can be the default one from your template

anmonteiro11:01:18

Not quite sure what you want me to look at there

jimmy11:01:49

the problem I'm looking into for now is

jimmy11:01:18

I can see the keys for om next to check what if they should re render for a component is sent

jimmy11:01:29

delta from server is correctly sent as well

jimmy11:01:39

so I guess the problem might be at the function where om next calculate computed props. So I assume that there might be some thing wrong with the data response ( not in proper format ). https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1566-L1571

anmonteiro11:01:31

@nxqd: I'd try to check one thing at a time

anmonteiro11:01:54

1. Check if the remote data is correctly merged into the app state

anmonteiro11:01:25

2. Check if you're passing down the props correctly (no computed!)

anmonteiro11:01:25

3. Add computed props

anmonteiro11:01:04

There doesn't seem to be anything wrong in the code you just linked

anmonteiro11:01:36

People have been trying this out a lot lately so I'd check if there's something wrong in your code

jimmy11:01:12

ah, no I didn't point it out because it's wrong. I point out the part of code that I think my input can be wrong there . I will create a minimal case then send out the repo here.

jimmy11:01:47

I think I would do a bit of debugging to understand the reconcile! part first

nano12:01:08

The weird thing is that when the root component renders the selected component, the data that component needs is available in the app-state if I inspect it in the repl, even if the page is rendered empty. So the reconciler :send xmlhttprequest is dispatched as expected, but render is called before the data arrives, and not rerendered after the data arrives.

anmonteiro13:01:52

@dnolen: FWIW the PR 573 description is now outdated; I've found a cleaner way to solve the issue without actually modifying query-template; editing the description now

anmonteiro14:01:01

@dnolen: still not sure about one thing; ping me whenever you get to look at it so I can tell what it is

tmorten18:01:44

I've still been doing some experimenting with Om next...is it "ok" when building a master/detail component with normalized db to have a root query as such (all components have implemented Ident): `[{:company [{:employees ~(om/get-query Employee)} :employee/by-id]? This way the top level query contains the :employee/by-id map to do the lookup for an employee?

anmonteiro19:01:21

@tmorten: not sure why you need to do that; if you have implemented Ident then :employee/by-id is already at the top level of your app state and you can access it in your read method

geraldodev19:01:41

The normalization is awesome when you update the data on the app and you don't want it to be out of sync. If your use case is a database on a intranet, you can let it normalize for you and to me it's perfectly acceptable if the :company read function were :remote true and it fetches all the data directly from the database, and pass locally to the childreen via (a-nested-compent (:employee (om/props this :company)). Beware I'm a newbie wishing to learn.

a.espolov19:01:07

I understand that if the read method on the backend returns a map, then on the client in the State list of vectors is written?

tmorten19:01:10

@geraldodev: It is as you say...working from a db on a remote

tmorten19:01:10

If that is the case, how do you pass a parameter when quoting and including a subquery: i.e `[(:company [{:employees ~(om/get-query Employee)} {:id ?company-id)]?

tmorten19:01:52

looks like it is trying to bring in the ns of ?company-id ...do I need to escape that some how. I am a macro noob simple_smile

anmonteiro19:01:00

~' should work

tmorten20:01:06

Thanks @anmonteiro. I'll give that a try...I think I was stretching the limits of db->tree

anmonteiro20:01:23

@zalky: after hours of digging into your issue, and even submitting a PR

anmonteiro20:01:35

I think I was mistaken and that was actually a non-issue

anmonteiro20:01:05

yep, just verified with your original example

anmonteiro20:01:51

if you simply supply the key to be re-read after the transact! call, the problem goes away (try this: #(om/transact! this _BACKTICK_HERE_[(comp/inc ~{:id id :type type}) :value]) )

anmonteiro20:01:22

@dnolen: so #572 is actually a non-issue, it can't be made to work as I was expecting it to work because of path focussing and full-query; closing the issue and the PR

anmonteiro20:01:43

@zalky: and there's also a way to make it work without supplying the value to be re-read, using path optimization. I'll put together a variation of this example if you're interested

zalky20:01:21

@anmonteiro: I'm certainly grateful, and I think it speaks volumes of this project that it has people like you contributing. I'm definitely interested; it seems counter-intuitive that the read would receive a different query second time, so I must be missing something conceptually that I'd love to clear up.

anmonteiro20:01:54

@zalky: it has to do with the recursion stuff

anmonteiro20:01:06

and the path into the query

anmonteiro20:01:32

because when you're recursing into, say, id #1

anmonteiro20:01:49

your path is then [:composite/item :children]

anmonteiro20:01:03

so the query gets to be [{:composite/item {:children [_the query of the component you clicked_]}}]

anmonteiro20:01:12

this only occurs after a mutation

anmonteiro20:01:36

thus if you pass a key to be re-read, you get the original query and everything just works

zalky20:01:44

@anmonteiro: is specifying a value to be re-read inside the read

{:value {:keys [:value]}
:action ...}
functionally equivalent to doing it in the mutation specification?

anmonteiro20:01:44

@zalky: it's not. the :keys stuff inside a mutation's :value is merely informational

dnolen20:01:33

@anmonteiro: just for my own edification what was happening when a read key wasn’t supplied?

anmonteiro20:01:58

@dnolen: the components deep in the recursion didn't re-render

zalky20:01:40

@anmonteiro: okay, so in the tutorial where it says "the :keys vector is a convenience that communicates what read operations should follow a mutation", I took this to mean it communicates to the reconciler that a read should be queued. In fact it just serves as documentation?

anmonteiro21:01:56

only lines added were 136-142 and 162

anmonteiro21:01:50

keep in mind that those read keys are only called after the mutation

zalky21:01:37

@anmonteiro: ah yes, interesting. It does seem to work with path optimization as well. Does every union entry in the union require a separate read function like that?

anmonteiro21:01:05

@zalky: only the ones that transact!

anmonteiro21:01:33

(there could be a union's branch that is read-only)

zalky21:01:19

@anmonteiro: Interesting. It seems that with path optimization the reads are now always called with the right queries, and way fewer reads than before. Without path optimization, providing the :value key just calls the reads an extra time on-top of all the previous reads that didn't work. I really appreciate all the work you put in to sort through all this. Could you maybe direct me to where the majority of the path optimization/processing is happening in the source so that I could try and wrap my head around it better?

anmonteiro21:01:28

@zalky: sure, it's really concise

anmonteiro21:01:52

and some bits in the parser as well

anmonteiro21:01:48

@zalky: you can also specify just the ident key to be re-read after the transact! call

anmonteiro21:01:58

then it won't perform as many reads

zalky22:01:05

@anmonteiro: you mean providing [type id] instead of :value? #(om/transact! this _[(comp/inc ~{:id id :type type}) [type id]])

anmonteiro22:01:03

#(om/transact! this _[(comp/inc ~{:id id :type type}) ~(om/ident this)])