Fork me on GitHub
#om
<
2015-10-07
>
dnolen01:10:40

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

dnolen02:10:03

@rburns: thanks will fix

tyler02:10:31

@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

dnolen02:10:54

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

dnolen04:10:01

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

dnolen12:10:13

found a bug, updated, DataScript integration is pretty clean simple_smile

ivern14:10:13

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

ivern14:10:08

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.

dnolen14:10:30

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

mcgivernsa16:10:38

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

mcgivernsa16:10:51

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

mcgivernsa16:10:51

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

dnolen16:10:28

@mcgivernsa: glad you’re enjoying it simple_smile

jannis19:10:30

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

jannis19:10:22

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

tyler19:10:29

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

jannis19:10:06

@tyler: Not yet but I will now simple_smile

jannis20:10:17

@tyler: Perfect, problem solved, thanks

jannis21:10:42

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

jannis21:10:41

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.

dnolen21:10:58

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

jannis21:10:39

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

dnolen21:10:56

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

dnolen21:10:13

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

dnolen21:10:39

feedback welcome now though of course!

dnolen21:10:45

that’ll help decide where we go simple_smile

jannis21:10:31

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

jannis22:10:54

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

jannis22:10:21

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

dnolen22:10:07

@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

dnolen22:10:43

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

jannis22:10:52

Ah, of course!

jannis22:10:08

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

dnolen22:10:30

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

dnolen22:10:40

query exists only to get data to components nothing more

dnolen22:10:03

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

dnolen22:10:30

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

jannis22:10:32

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

dnolen22:10:16

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

dnolen22:10:37

just transactions and access to the indexer

dnolen22:10:49

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

jannis22:10:56

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.

dnolen22:10:40

again the pieces are there

dnolen22:10:56

just don’t see a use case at all

dnolen22:10:16

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

dnolen22:10:38

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

dnolen22:10:12

and you have to construct the parser anyway

jannis22:10:15

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

dnolen22:10:16

all the query power is right there

dnolen22:10:52

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

dnolen22:10:53

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

jannis22:10:57

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

dnolen22:10:08

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

jannis22:10:14

Ok, fair enough

jannis22:10:09

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

paulb22:10:57

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?