Thanks, I'll update the gist and post it here tomorrow.

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

100 lines is the length of a freaking empty ViewController template in Swift lol

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)

doesn’t redux try a similar approach to state management?

not that familiar with it to compare

me neither, they just mentioned it heh

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

those are some compelling arguments

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

mostly FUD

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

I know let’s see if some demo / workshop works for them

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}}

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

Heh, I found it on your github repo.

@bmaddy: You can just do (clean-builds) in the repl - otherwise you will have to setup lein-build

(clean-builds) fixed everything up for me--Thanks @griffio!

I’m not sure I understand what this error message means: No queries exist for component path (ui.core/RootView ui.poi/PoiView)

I’ve gotten similar errors and fixed them somehow but I always forget how

what does it mean exactly?

https://clojurians.slack.com/archives/om/p1449530282005088

https://clojurians.slack.com/archives/om/p1449530303005089

@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

having subcomponents with subqueries

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.

@tomc: sure

@anmonteiro: PoiView is a component rendered by RootView

@txus: right

so

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

sure

there, hope it helps

@txus: ^

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!

it makes a lot of sense now

@tomc: ^^

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 😉

this is the ‘click’ that I was missing in om.next

I'm not understanding why the original way was wrong. The 'stolen' query was still a grammatically correct query, no?

@tomc yes but it cannot work

I’ve already pinned stuff like this to the channel … but

Om Next doesn’t have syntax so we can’t control user errors like this

people assume they can freely build up queries however they like - but of course that isn’t true

Query <-> Component is a one to one thing

you cannot steal queries

if you think about it a little more it’s obvious doing so is a modularity fubar

you just took an opaque thing somebody needs and messed it up

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.

@tomc: be sure not to conflate issues here

of course the root component is going to get everything

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

transformation of data in components is a BIG nono

the whole point of having a declarative query is - GET IT RIGHT

render, done

so nice!!

it’s in this sense that Om Next is decomplected

all the data manipulation stuff happens in parse, or in send

components are just about rendering, life cycle, animation, and host events

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

@dnolen: I don’t quite get the “read hints” on mutations. They seem to have no effect?

{:value {:keys [:foo :bar]} :action #(…)}

@txus yes no effect

it’s just to communicate the set of things you can read

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).

I’m not using :query-root yet, so my re-written query should be the same

for this query:

[{:app/pages
  {:page/home
   [{:user/rooms [:id :roomname]} {:app/rooms [:id :roomname]}]}}]

[{:app/pages
  [[:page/home
    [{:user/rooms [:id :roomname]} {:app/rooms [:id :roomname]}]]]}]

@noonian: thanks for the report, file a bug with this information, thanks

Cool, I’ll open an issue.

thanks

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

@maackle: you should always ask first here for clarification

and no PRs or issues for docs

gotcha

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)

namely it doesn’t seem to work with korks before the update function

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

I had no luck getting it to take a key or a vector of keys

I’m looking at the source and it definitely doesn’t heh

(om.next/update-state! some-component update-in [:some/key :other/key] inc)

that vector of keys is an argument to update-in

i know

I would expect (om/update-state! some-component [:foo :bar] (fn [] …)) to work

from the docs

ah I get your confusion now

ah right

it should be fixed to say update

go for it

but yeah, using update/`update-in` makes that functionality pretty unnecessary

@dnolen: I don't think it's even similar to update

more like swap!

yeah, you’re right

right

ah heh, right

yeah should just fix update-state! to actually take k-or-ks like it did before

patch welcome, it’s quite trivial

I have the time to do it

was going to ask if you'd take the patch

if nobody else wants to tackle that

hrm actually

how do you run the tests for om btw?

I think that’s probably a bit awkard

may be we should just say it’s like swap!

@anmonteiro: yeah I think we should ^

we don’t actually have anything like update-in anywhere else

@dnolen: get-state can work like get-in

maybe @maackle was confused because that's how it used to work in om.core

thats the only thing that might make someone expect it I think

and the existing documentation heh

@noonian: but it really is just awkard

since the first argument is not a free thing like update-in

@anmonteiro: I’m not that familiar with om at all, it was just that statement in the docs about update-in

even get-state is not like get-in due to k-or-ks

and pairing update-state! with update-in is simple enough

yeah, I’m fine with having it like swap!

we should definitely update the docs though

yep

I like how get-state works now btw 😛

I prefer the atom analogy for component local state

only submitting a patch for the docstring if David really wants or has more things to do

since it's only changing one line

I can fix the docstring here

anyone can feel free to fix up the wiki

that's what I thought 😛

docstring fixed

updating the wiki

thanks

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.

there isn’t a nice way, but you can do [(~‘add-person …)]

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.

@codonnell: np!

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.

@bplatz: it’s not a problem if that’s what you mean

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

other than they’ve gotten it to work

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.

yes

@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

I just saw the union issue...you're seeing others?

other issues just in the sense that the test on around line 1250 isn’t right

I should have read more closely but you cannot the union? predicate like htat

the test on 1250???

you mean the impl at 1250

I had to do that because join? is mis-identifying unions AS joins

actually the problem is that union? is just wrong

e.g. returning true on unions

no it’s just completely wrong

a union is map with one entry whose value part is a map

if you could point to what behavior is wrong in the tests, that would help

but that’s not what union? tests

oh

I see what you mean

but the code is : its a map and has more than one k-v pair

that is syntactically a union

we're talking about 2 things

So, you're saying that a union has to be inside of a join

yes

it can never appear on it’s own

agreed

the AST already reflects that

but the fact that the union? predicate is wrong has rippling effects

Oh, so I bet I mis-wrote a test

and then wrote the impl to that test

yeah I need to poke around at this since a bunch of tests fail if I fix union?

OK, I can tell you that in this algorithm I was using that function to deal with the following ambiguity:

{:j {:uk1 [] :uk2 []} vs. {:j {:j2 [sel]}

oh sorry

one more deep

so, when you see the latter, it COULD be a join, or it could be a map for a union

since join? returns true on both (internal things), it can cause problems

so this stuff just needs to be cleaned up

but there’s another thing that concerns me somewhat with respect to process-roots

in that it actually doesn’t really handle traversal into unions - trying to think whether this is a problem in practice or not

My take was that unions should not be traversed

you are processing a query outside of the context of data

so how could you chose the right path?

I guess you could evaluate all possible paths, if you find no roots there is nothing to do

pass it through without mods

otherwise pass the first sub-branch that has a root to top...I guess you could technically promote any branch to the top

if it is marked

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

@noonian: process-roots is about not sending UI-local path prefixes to a server

that's all

nothing to do with routing

(of the HTML5 sense)

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

ah, I see your point

@tony.kay: yeah union queries are a natural way to describe choice

that said no I don’t think that process roots will ever need to deal with all choices

I think in general nested union queries will be layered into some kind of “focus"

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.

so I don’t think making process-roots understand them will be particularly challenging

it’s just another thing to track (we already do this everywhere else)

right, so all we need to do is traverse the query to the marked root and promote it

first things first let me try to fix the union? predicate and its uses

since that’s at the bottom

ok. Be glad to lend a hand in a couple of hours. Let me know