This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-14
Channels
- # aws-lambda (5)
- # beginners (38)
- # boot (197)
- # carry (7)
- # clara (3)
- # cljs-dev (7)
- # cljsjs (6)
- # cljsrn (24)
- # clojure (39)
- # clojure-art (10)
- # clojure-austin (7)
- # clojure-dusseldorf (1)
- # clojure-italy (8)
- # clojure-russia (89)
- # clojure-spec (119)
- # clojure-taiwan (1)
- # clojure-uk (19)
- # clojurescript (104)
- # community-development (2)
- # conf-proposals (22)
- # copenhagen-clojurians (8)
- # cursive (2)
- # datomic (35)
- # devcards (4)
- # dirac (79)
- # euroclojure (2)
- # immutant (35)
- # om (138)
- # om-next (2)
- # onyx (172)
- # proton (4)
- # protorepl (1)
- # re-frame (36)
- # reagent (34)
- # spacemacs (1)
- # specter (7)
- # untangled (89)
- # yada (2)
Just trying to formalize my knowledge of om.next:
Is it true that all read
s are performed only against queries of the top level component, and that the queries of subcomponents only serve to help the top level component build a “master query”?
If the above is true, then does it also mean that all query params must reside in top level components?
@levitanong you could say that for most cases
but what really shines about Om Next is that the query of each subcomponent is also valid by itself
But that would only be relevant for repl-based testing, yeah?
not really
also for incremental rendering, for example
where you can start computing queries at an arbitrary subtree
or for recursive parsing, where you call the parser on a subquery
Is there any reading material for that? 😁
I’d like to find out more
@levitanong I don’t think there is
there are a few code samples here and there
let me try and find some
Also, I ask my original question because I’ve been working on a problem, you see:
I have a :current-something-id
I’d like many components to have access to. This is an indication that the value should be in app-state so the components can query it.
However, :current-something-id
is also needed information for a remote. i.e. When :current-something-id
is selected, additional information about it should be pulled from the server, so that should be part of my ajax request. The problem with this is, the send
fn that is passed to the reconciler doesn’t have access to state. Only params.
If I make :current-something-id
a query-param, then the other components that want to know its value have to go through a more indirect route. This is the path I’m currently taking, and it feels a little ugly. Do you have any suggestions?
@levitanong it looks like the AST would be the way to help you there
in your parser function you have access to the state, so you can modify the AST that gets sent to the server
e.g. instead of returning :remote true
, return :remote the-modified-ast
but where would the modified ast show up?
for recursive parsing, this should have some examples: https://github.com/awkay/om-tutorial
path optimization + incremental rendering: https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/core.cljs#L311-L397
in my experience, I’ve found that when I get the remotes
from the send-fn, they’re in the form of queries, and not ASTs, which is why one calls (om/query->ast query)
unless the modified ASTs somehow get turned into queries?
@levitanong that’s right, but if you return a modified AST in the parser, Om will convert that to a query
when the parser sends to send-fn?
ahhhhhhh
^ what you said 🙂
okay, it’s all coming together now!
I’ve always felt a little uneasy about using query params because I like keeping as much of state in application state as possible
but could never do so because of the remotes thing
Thanks, @anmonteiro! You are a gift to the clojure/script community 😄
np, and I wouldn’t go that far 🙂
@levitanong anyways your questions gave me an idea for a blog post
I’ll write up something on path optimization soon
Well, you do work on clojurescript. 😛 big thing in my book
Looking forward to reading your post! Will also read the devcards!
if anyone wonders why om.core
and om.next
live in the same repo ^
also if you want to help keeping the Wiki up-to-date!
I have a send fn that's passing a result like {'sym {:result {:tempids {#om/id["-1"] 123}}}}
to the callback, but default-migrate
is getting {}
as its tempids
argument
@jfntn I think you need to pull :tempids
out of the result
such that it becomes e.g. {'sym {:result {} :tempids {#om/id["-1"] 123}}}
@anmonteiro ok cool, now default-migrate
is getting {[:db/id <#C06DT2YSY|om>/id["-1"]] [:db/id 123]}
but the default-merge gives me something unexpected, replacing the app state with the result...
@jfntn your app state is normalized right?
@anmonteiro ah indeed my optimistic update was assoc’ing into the denormalized path, I changed it to {:denorm [:db/id <#C06DT2YSY|om>/id["-1"]] :db/id {#om/id["-1"] ...denorm-data…}
but I’m still getting nothing but the remote result in the app-state after it's migrated
@anmonteiro I think I've misunderstood how idents work in Compassus routes. I assumed that that [:item/by-id 0]
and [:item/by-id 1]
would use the same route, but I understand now that {[:item/by-id 0] Item}
literally means that when the route is that ident, the selected component should be Item
.
What would you use that for? Wouldn't it be more useful to have a route that applied to all idents of a particular "type"? I can't list every Item that's in the database in my routes map.
@peeja yep, that was definitely your misunderstanding 🙂
for now you cant’ do that programmatically
@peeja at the moment just static things as you can see
I may be just missing something about how Om Next is meant to work, but why would you have idents for static things?
@peeja hrm. I think the answer that most applies is “why wouldn’t you?"
probably not the most common case, but still 😛
yeah, probably not a very common use case, as I said
still for the bounded case might be useful [:tab/type :related]
, etc.
FYI: Updating om from alpha37 to alpha44, I'm getting core.cljs:5428 Uncaught Error: Index out of bounds
in cljs.core/subvec
used from
https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1832
After doing some printing, I found that (let [update-path (path c)]
on line 1829, return update-path
as nil
.
I suspect this is because my c
does not implement om/IQuery
.
@petterik that might need a little tweaking, thanks for reporting
did you succeed at producing a minimal case? it isn’t obvious to me how a component that doesn’t implement IQuery
would end up in reconcile!
yep, that’s one way it would end up there 🙂
there’s probably no test for that
@petterik probably worth opening an issue and I’ll get to it today
@anmonteiro not sure I'll get to creating a minimal case today. Working on updating a bunch of dependencies. Do you think you need one?
@petterik nope, your set-state!
suggestion will probably work for reproducing that
@petterik hrm actually I don’t know about that
that means we only go into that for props changes
weird
@anmonteiro that is weird. I'm currently passing {}
as props
hah. I might know what’s wrong
that probably results in (om.next/t {})
being a weird value
@petterik is {}
the root props?
@anmonteiro Not sure what you mean?
The root component's props are not {}
and the component c
's parent is not the root component
because what I said about t
might not apply
So hang on a minute. I think I'm seeing this error only after a merge? Would that make sense?
could be, repro would be ideal
pull syntax taking over the world, one tech conglomerate at a time
interesting timing?
definitely arranged
@anmonteiro Created issue om-766 and reproduced it here: https://github.com/petterik/om/commit/a989b8691ff4d35d814bc4c6babe003106111da3
@petterik awesome!
@anmonteiro need to rebase the server side rendering commit
@dnolen gotcha, doing it now
@dnolen rebased, want me to squash the 2 commits?
@anmonteiro yes preferred
@dnolen wow awesome!
note that now there are Clojure and ClojureScript tests
you can run them with boot test
it’ll run both
not sure how you’ll be doing that with your preferred build tool
I can probably make it work with Lein too
@dnolen wondering at this point we should maybe set up CircleCI for running tests in PRs and stuff?
that would be cool, I don’t have time to work on that myself but I would be happy to see it done
@dnolen happy to do it, but would need access to the org
👍 thanks
@dnolen going to be pushing 1 or 2 commits with the circle config then
@dnolen any chance you could release one more alpha to give the latest stuff a go?
awesome
thanks
is omcljs$parent any different between simple optimized builds and none optimized builds
@jasonjckn might be due to Closure Compiler munging
@anmonteiro i'm only using simple mode
I copied over some of om.next internal code into my own project, but I thought closure compiler would be fine with this
(defn parent
"Returns the parent Om component."
[component]
(get-prop component "omcljs$parent"))
Simple optimizations also perform munging
and that should be OK