feedback welcome on this now - https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29

please do not edit, ask me questions here or suggest enhancements via issues

@dnolen: https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29#checkpoint the println call there failed with no print-fn defined

@rburns: thanks will fix

@dnolen: not a fix but a suggestion. You had a slide about the different query and mutation forms in your recent om.next talk. I think it would be useful to see that diagram when you introduce the parser. Also, don’t know if you have any drawings for the indexer concept but since its a somewhat new concept (at least for me), it would be nice to have something to help visualize it. I imagine it as a hash map lookup with several different indexes but I’m not sure if thats the right way to think about it. The content felt well thought out and was easy to follow without any large logical jumps

@tyler: thanks for the feedback, very helpful! Will incorporate

needs more explication but rough DataScript integration bits up https://github.com/omcljs/om/wiki/DataScript-Integration-Tutorial

found a bug, updated, DataScript integration is pretty clean

@dnolen What's the expected CLJS fluency for the target audience for OM-Next quick start?

If you want this to be beginner friendly you may want to make sure the REPL snippets can be run as-is, for example by adding the necessary requires.

@ivern good point in this case you don’t need requires when using Figwheel, just some (in-ns …) stuff

https://github.com/omcljs/om/issues/391

> The reconciler will do this on our behalf as it may need request data from an endpoint first.

I'm not clear if 'request data' is a noun there, or it should be 'to request data'

@mcgivernsa: thanks fixed

that tutorial is really good, the first moment when you reset the state to a previous UUID is pretty special

@mcgivernsa: glad you’re enjoying it

@dnolen: I'm trying to play with om.next in a boot project. Since boot can't handle git dependencies, I've included om from master as a git submodule. Anyway, it seems the "static" in "static om/IQuery breaks my app. Do I need a specific CLJS version or something else for it?

Right. I think somehow I'm not including om in my sources correctly because it's not pushing next.cljc to my boot build results in target/.

@jannis have you tried installing om to your local maven repo and then including [org.omcljs/om “0.9.0-SNAPSHOT”]?

@tyler: Not yet but I will now

@tyler: Perfect, problem solved, thanks

@jannis no problem

@dnolen: I read that om/transact! is intended for components and only works against the reconciler for "development convenience". If a non-UI part of the app (e.g. something that polls a server for data in the background) wants to update the application state, is it still a good idea to use om/transact! or would you recommend something else?

Another example would be a secretary-based routing solution that parses the new location into path segments and sets something like :app/route so that a UI routing component can query the route and decide which child to render.

@jannis there’s really nothing wrong with calling transact on the reconciler

Ok, cool

I was just wary because of how doing that was phrased in the tutorial. 😉

it is mostly there for development convenience but I’m sure people will have lots of ideas that I haven’t thought about

and we’ll suss out what should be better supported as we transition to alpha and then beta

Ok

feedback welcome now though of course!

that’ll help decide where we go

@dnolen: I'll be playing with it more over the next couple of days and see how I like it.

@dnolen: Is it possible to query outside of components?

Something like (om/query reconciler [:app/counter :app/something-else]) that returns the results of the query?

@jannis this is what om.next/parser let’s you do, create a parser you can pass that to the reconciler and hold onto it as well

but you would need to supply the env parameter yourself, normally the reconciler does this

Ah, of course!

Thanks

Wouldn't a query counterpart to om/transact! make sense that can operate against the reconciler, so the reconciler would provide the env (since it already knows about it anyway)?

this is less clear - this just sounds like a convenience for something that doesn’t have a rationale yet

query exists only to get data to components nothing more

transact is very different since many actors will want to transition the application state

but outsiders wanting to know what something read … not sure about that

Right. I might be incorrectly looking at parts of the reconciler as an API to access and modify the app state. Coming from the old om world...

yeah reconciler is not about reading the app state at the moment

just transactions and access to the indexer

mostly because I don’t know yet if the indexer should be exposed in anyway

It feels asymmetric to have a powerful interface to mutate the application state but having to use something else (e.g. a bare atom) for getting state information out.

again the pieces are there

just don’t see a use case at all

in a real application you can just a) look at the atom b) query DataScript c) query Datomic or your end point directly

also you can grab any component and get it’s props

and you have to construct the parser anyway

Ok. I am only familiar with a). Perhaps I should move on to b) at the least.

all the query power is right there

(parse {:state apps-state} ‘[…])

so less convenient, but I haven’t found myself wanting this convenience yet

I'll see how far this can take me for the moment.

not saying we won’t get there, but again - not seeing the value of it yet

Ok, fair enough

I'm new to this (ClojureScript, Om, DataScript, everything really), you know this world much better

been reading the Om Next wiki and it's filled with cool ideas. one thing I didn't understand is for a query expression like [{:app/counter [:db/id :app/title :app/count]}] after evaluating what is the advantage of the value for :app/counter being a vector containing a map rather than just a map?