This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-08
Channels
- # admin-announcements (3)
- # beginners (284)
- # boot (179)
- # cider (15)
- # cljs-dev (6)
- # cljsrn (95)
- # clojure (105)
- # clojure-austria (4)
- # clojure-berlin (9)
- # clojure-germany (4)
- # clojure-japan (3)
- # clojure-russia (65)
- # clojurebridge (1)
- # clojurescript (109)
- # code-reviews (16)
- # cursive (27)
- # datavis (19)
- # datomic (68)
- # devcards (7)
- # funcool (31)
- # jobs (1)
- # ldnclj (2)
- # lein-figwheel (3)
- # leiningen (4)
- # off-topic (419)
- # om (255)
- # parinfer (39)
- # portland-or (2)
- # re-frame (28)
- # reagent (14)
- # slack-help (12)
- # spacemacs (1)
I'm struggling a bit with tony kay's om-tutorial. I'm trying to do the UI Queries and State Exercises, and I'm struggling to get my Person
component's props to be what I want. When I do (om/props this)
, I get an entity [:db/id 1]
rather than a map with the attributes I want. If someone could give me an idea of how to resolve the entity into the map I want (with :person/name, :person/mate, etc.), I would much appreciate it.
What you get will be the :value
returned but your parsers read function. If you are using links in your parser you will need to use Om’s db->tree
helper to recursively follow links and build up the data.
given a map :person/by-id {"1" {:name "Tom"} "2" {:name "Jon"}}
and a list with links: :person-list [[:person/by-id "1"] [:person/by-id "2"]]
when i delete one of the persons, the link in my list becomes invalid (nil). In the same transaction, i can search for all links and delete them manually - is this how it should be done?
mfikes’ auto-completion code is beautiful. Can’t believe that’s running on iOS and it’s barely 100 lines of lisp
om-next really shines on mobile
my co-founders are really excited about React / React Native, and I try to sell them om.next for both web & mobile apps but the lisp argument is not enough for them, and I don’t think I fully grasp all the potential of om.next good enough to sell it. What are the main strengths would you say?
it scales
because of single app state and idents it will scale when your UI grows. It scales from the side of backend communication. It scales from the side of your custom requirements (server push, custom app state db, etc)
not that familiar with it to compare
scalability isn't a main strength, i would say
lots of systems scale in different ways
it's really an improvement over REST, you have to have experienced the problems with REST apis to really see the benefits
the lisp argument is orthogonal to om.next, its more an argument for clojurescript
but it shows where the good ideas are coming from, there is nothing much like om.next at the moment
well technically you can achieve about the same if you take redux + relay + graphQL + immutablejs
although I think om-next + CLJS solves problems better
there would be a lot to reimplement in making those all work together in a comparible system
you'd probably end up with much more code to maintain
definitely in fact
and the end result would be still not that good, yep
so om-next is the best thing in the world, what else we need to say?
another strength is completely decoupling the ui from state
and the state model
through queries
so you can change your mind to using datascript instead of atoms, or some other system
and not have to change any of your compenents
just the parser
@txus you mentioned web and mobile apps (plural)
om.next can really shine when you have multiple clients using the same api
your api will be much cleaner
over Christmas I’ll spend some time with them in Barcelona and I plan on having a bit of a workshop on om.next + react.native, something flashy to spark their interest
Show them figwheel + repl and they will buy it the same moment
they already like Clojure from a distance, the workflow and all the jazz, it’s really impressive
but they’re afraid on taking on too much by learning React and cljs, and they’re afraid of the stability of both things combined / om lagging behind or being eventually incompatible with react, etc
As I understand it, om.next is largely decoupled from react.dom and in the future using another virtual dom implementation may be possible
That said, it is still alpha and I understand it being a hard-sell for some people at this stage
Is anyone else having trouble with the "Change the Query!" section of the om.next quick start? https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29#change-the-query
om.set-query!
changes things in a way I wouldn't expect:
cljs.user=> (in-ns 'om-tutorial.core)
nil
om-tutorial.core=> (om/get-query (om/class->any reconciler AnimalsList))
[:app/title (:animals/list {:start 0, :end 10})]
om-tutorial.core=> (om/set-query! (om/class->any reconciler AnimalsList) {:params {:start 0 :end 5}})
nil
om-tutorial.core=> (om/get-query (om/class->any reconciler AnimalsList))
{:params {:start 0, :end 5}}
I would expect get-query
there to return [:app/title (:animals/list {:start 0, :end 5})]
. Is anyone else seeing this?@bmaddy: Just to confirm, I do see [:app/title (:animals/list {:start 0, :end 5})] ,on Alpha24/25.
Weird, there must be something wrong on my end then. I'll try copying in the code again. Thanks @griffilo.
@bmaddy yup, check version, clean build etc. It definitely works as to your expectation!
Do you by chance know how to clean it when running like this? lein run -m clojure.main script/figwheel.clj
lein cljsbuild clean
doesn't seem to work since cljsbuild isn't in the project.clj
.
@bmaddy: You can just do (clean-builds) in the repl - otherwise you will have to setup lein-build
I’m not sure I understand what this error message means: No queries exist for component path (ui.core/RootView ui.poi/PoiView)
@txus: refer to that
hmm yeah, I think I’m doing something like that. But I don’t quite get how else I could do it
is there any code in the wild with deeply nested components / queries? that’d be really cool to study
I'll have a look if you share your components' queries
@txus I'm still looking at the same thing. Mind posting back here if you get a solution? I'll post my gist once I get it updated and we can compare notes.
@anmonteiro: PoiView is a component rendered by RootView
@txus: right
you're stealing PoiView's query
oh I thought that was expected? The root query needs to be a complete tree of everything everyone needs no?
yes, but not like this
give me a second
there, hope it helps
ah!! mann of course read
is mine and it can read custom join names! I’ve always been afraid of using names that don’t specifically mimic the shape of the initial data map
@anmonteiro: thanks so much!
exactly, env
in the parser gives you that degree of freedom
happy to help
@txus hopefully drives the point home yet again, that it’s completely up to you what Om Next does and how it does it 😉
I'm not understanding why the original way was wrong. The 'stolen' query was still a grammatically correct query, no?
people assume they can freely build up queries however they like - but of course that isn’t true
Yeah that actually answers a question I hadn't really formulated well. When doing it my broken way I ended up passing everything from RootView's props into the child component, which is obviously bad. Thanks for the help.
but it should just pass on the keys that children need as expressed in the query and not muck it up
I feel so dumb! that’s really the point of decoupling components from the shape of the tree
with the tiny, tiny bit of loop back permitted by transact!
to transition the app to the next logical state
The gist I posted now shows a working version of the Components, Identity, and Normalization tutorial with routing, in case that's useful to anyone: https://gist.github.com/tomconnors/c1cceaae84fd059e37a3
in a world with diverse clients you don’t want clients to re-read stuff they cannot display
maybe a desktop client is show 4 different views and can accommodate those keys, but iOS client can only show 1
so imposing the same reads on everything is just backtracking on the problem Om Next wants to solve
@dnolen: I think there is a bug in process-roots
where it doesn’t re-create a union correctly (doesn’t convert vector of map entries into a map).
for this query:
[{:app/pages
{:page/home
[{:user/rooms [:id :roomname]} {:app/rooms [:id :roomname]}]}}]
(:query (om/process-roots the-above-query))
returns
[{:app/pages
[[:page/home
[{:user/rooms [:id :roomname]} {:app/rooms [:id :roomname]}]]]}]
Can anyone tell me if it’s constructive at this point to submit issues/PRs on om.next documentation, or is that too nit-picky? Maybe it’s all going to be re-written soon. For instance, I found the doc for om.next/update-state!
misleading
I figured it out, but I think the statement “Similar to Clojure(Script)’s update-in” is incorrect (https://github.com/omcljs/om/wiki/Documentation-(om.next)#update-state)
changing to “Similar to Clojure(Script)’s uptate” would probably make sense, since it doesn’t take a vector of keys like the *-in family of functions
it can take a vector of keys
(om.next/update-state! some-component update-in [:some/key :other/key] inc)
i know
ah I get your confusion now
@dnolen: I don't think it's even similar to update
more like swap!
I have the time to do it
was going to ask if you'd take the patch
if nobody else wants to tackle that
@anmonteiro: yeah I think we should ^
maybe @maackle was confused because that's how it used to work in om.core
@anmonteiro: I’m not that familiar with om at all, it was just that statement in the docs about update-in
only submitting a patch for the docstring if David really wants or has more things to do
since it's only changing one line
that's what I thought 😛
updating the wiki
Is there some nice way of avoiding clojurescript throwing namespaces onto syntax-quoted code? I want \
[(add-person {:name ~(om/get-state this :text)})]` to evaluate to [(add-person {:name "foo"})]
rather than [(om-recipes.core/add-person {:name "foo"})]
.
That \
is supposed to be a backtick.
@codonnell: FYI you can go back and edit your previous messages
Thanks; I did not know that.
or, just use something like app/add-person
so its already namespaced and then syntax quote will leave it alone
@noonian: Thanks! That clears things up.
Is it recommended to use :merge
with datascript? It seems it can be accomplished via :merge-tree
by returning the dereferenced connection... but it seems the connection itself is what should be passed back in.
if there’s some issue that you see then express that - I haven’t heard a ton of feedback from DataScript users on :merge
or :merge-tree
I was trying to think through the mechanics. If you pass the de-ref'd DB, then I guess om will reset! the original atom with it? If so I suppose everything would still be in sync.
My concern was doing it that way the original DB conn might be out of sync, but I suppose because the datascript DB is a standard atom it should work.
@bmaddy Thank you! With regards to posting the weird behavior of set-query!
just got the same thing, and after a clean everything works!
@dnolen: I've got time tonight to look at process-roots
. I also talked to @jannis and it seems like he's discovered a bug in db->tree
around joins combined with recursive queries. I'll look at that as well unless you're already working on either of these.
@tony.kay: yeah the behavior of process-roots
is definitely wrong wrt. to joins and it seems like the tests around it are not actually testing what they should be at the moment
OK, I can tell you that in this algorithm I was using that function to deal with the following ambiguity:
in that it actually doesn’t really handle traversal into unions - trying to think whether this is a problem in practice or not
I guess you could evaluate all possible paths, if you find no roots there is nothing to do
otherwise pass the first sub-branch that has a root to top...I guess you could technically promote any branch to the top
but then the result would need to be evaluated with ident somehow to figure out how to reassemble the prefix
when using unions to achieve routing, you run into exactly the problem that it seems like process-roots
is intended to solve
correct, and if you are using a union to achieve client side routing, then that union query (and outer join) is really just client machinery as well and you don’t want to send that to the server
Yeah, and for the routing case your parser will theoretically only ever return a remote query for one of the union branches at a time.