This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-12
Channels
- # admin-announcements (8)
- # alda (11)
- # announcements (53)
- # architecture (2)
- # aws (10)
- # beginners (69)
- # boot (403)
- # braid-chat (160)
- # cider (10)
- # cljs-dev (14)
- # cljsjs (26)
- # cljsrn (34)
- # clojure (223)
- # clojure-art (1)
- # clojure-brasil (4)
- # clojure-dev (10)
- # clojure-france (1)
- # clojure-gamedev (1)
- # clojure-nl (14)
- # clojure-russia (20)
- # clojure-seattle (8)
- # clojure-sg (1)
- # clojurebridge (2)
- # clojurescript (156)
- # code-reviews (2)
- # community-development (305)
- # cursive (5)
- # datavis (33)
- # datomic (38)
- # devcards (4)
- # dirac (39)
- # dunaj (3)
- # emacs (5)
- # events (2)
- # funcool (45)
- # hoplon (3)
- # instaparse (24)
- # jobs (2)
- # ldnclj (77)
- # lein-figwheel (4)
- # leiningen (1)
- # mount (49)
- # nyc (14)
- # off-topic (52)
- # om (125)
- # omnext (4)
- # onyx (13)
- # other-lisps (1)
- # overtone (8)
- # parinfer (31)
- # plastic (6)
- # portland-or (3)
- # quil (4)
- # re-frame (6)
- # reading-clojure (16)
- # reagent (212)
- # ring-swagger (11)
- # robots (5)
- # spacemacs (4)
- # specter (1)
- # yada (26)
@dnolen: I've opened an issue with a minimal case
@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?
@dnolen: just submitted the PR (https://github.com/omcljs/om/pull/573)
this one was a doozy
In case people are looking for a quick way to play with the Om Next query expression grammar: https://twitter.com/jannispohlmann/status/686743384082481152
@jannis: aren't you in Germany too?
guess I'm not the only one who's awake at 4AM
@anmonteiro: You're not
Dresden
it's a cool place, very calm and lots of history
Yeah, it's not know as the hottest, trendiest place (compared to Berlin and Leipzig) but it's beautiful and historic.
ah, I'm not that familiarized with German geography yet
Dresden is also known for being a tech area (traditionally with AMD being located there etc.) - is that how you got there?
I got here to study at the TU Dresden
haven't thought about it
I'll see about that
and let you know
off to bed now
night
Is it still necessary to use an externs file for advanced mode compilation of Om Next apps?
I’m looking at this which seems to imply that it is… https://github.com/clojure/clojurescript/wiki/Packaging-Foreign-Dependencies
@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.
@juhoteperi: ah, okay, so I need to understand what’s going on with CLJSJS
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 ?
did you implement merge-tree to update your state?
@danielstockton: I didn't . But I assume that the default one would work just fine ?
it might but that's what is updating your application state so i guess start debugging around there
@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 .
you need to pass keywords after the mutation to say what needs re-rendering
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.
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.
@nxqd: pass the keywords you wanna re-read in the transact!
vector
e.g. (transact! '[(do/stuff!) :key/foo]
If the app state is updating with the remote data, then you can rule out merge-tree
@anmonteiro: actually it's not the mutation. It's a remote fetch
@nxqd can you put together a minimal case?
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 templateNot quite sure what you want me to look at there
I can see the keys for om next to check what if they should re render for a component is sent
My current attempt: https://github.com/dsvensson/svtplay-tizen/blob/master/src/svtplay/core.cljs
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
@nxqd: I'd try to check one thing at a time
1. Check if the remote data is correctly merged into the app state
2. Check if you're passing down the props correctly (no computed!)
3. Add computed props
There doesn't seem to be anything wrong in the code you just linked
People have been trying this out a lot lately so I'd check if there's something wrong in your code
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.
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.
@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
edited
@anmonteiro: k thanks
@dnolen: still not sure about one thing; ping me whenever you get to look at it so I can tell what it is
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?
@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
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.
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?
@geraldodev: It is as you say...working from a db on a remote
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)]?
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
~'
should work
Thanks @anmonteiro. I'll give that a try...I think I was stretching the limits of db->tree
@zalky: after hours of digging into your issue, and even submitting a PR
I think I was mistaken and that was actually a non-issue
yep, just verified with your original example
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])
)
@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
@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
@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.
@zalky: it has to do with the recursion stuff
and the path into the query
because when you're recursing into, say, id #1
your path is then [:composite/item :children]
so the query gets to be [{:composite/item {:children [_the query of the component you clicked_]}}]
this only occurs after a mutation
thus if you pass a key to be re-read, you get the original query and everything just works
@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?@zalky: it's not. the :keys
stuff inside a mutation's :value
is merely informational
@anmonteiro: just for my own edification what was happening when a read key wasn’t supplied?
@dnolen: the components deep in the recursion didn't re-render
@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?
@zalky: correct
only lines added were 136-142 and 162
keep in mind that those read keys are only called after the mutation
@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?
@zalky: only the ones that transact!
(there could be a union's branch that is read-only)
@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?
@zalky: sure, it's really concise
right here: https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1587-L1589
and some bits in the parser as well
parser part: https://github.com/omcljs/om/blob/master/src/main/om/next/impl/parser.cljc#L188
@zalky: you can also specify just the ident key to be re-read after the transact!
call
then it won't perform as many reads
@anmonteiro: you mean providing [type id]
instead of :value
? #(om/transact! this _[(comp/inc ~{:id id :type type}) [type id]])
#(om/transact! this _[(comp/inc ~{:id id :type type}) ~(om/ident this)])
@zalky: like that ^^