http://23.km,M mbNNbjv

cat on keyboard detected ^

lol

FYI, my tutorial is becoming a full-blown application dev tutorial, not just remotes, so I’ve renamed it. I updated the link earlier, but just noting: https://github.com/awkay/om-tutorial

'When writing a backend parser you will usually supply env yourself.' is he talking about a server-side parser or a client side parser that talks to a remote backend?

When he says backend parser he means the server-side parser. For instance, you might provide a database connection in your server-sider parsers env.

got ya, thanks

i translated the simple List-Tutorial to datascript. In my apps, the root gets the :db/id 0 (as far as i know, this is not possible in datomic, but in datascript it is a nice solution). https://gist.github.com/ThomasDeutsch/0080e4ec0a0a21bec943

@tony.kay: you're awesome ^^ thanks for the tutorials!

can anyone give me some tips on keeping datascript/datomic in sync between server and client?

im trying to work out how to update my client state with data returned from a remote, i see the api call returning the data but the default send cb doesnt seem to do anything with it

@nowprovision: but that is also true if you want a client parser that acts as a remote, for example, if you use a cloud service (like http://Parse.com, Firebase, ...), you can write a full parser on the client side that translates the calls to the cloud service, on this case you probably would like to provide some env too (like the cloud service connection)

I'm ready to try out path optimization as well, same issues as @jdubie. If path optimization has Ident use as a prerequisite, is there a solution for datascript?

seems like i need to implement either merge or merge-tree as the default implementation work for atoms?

does anyone have an example?

@danielstockton: Yeah, cb has no idea about Datascript. You will have to write merge algorithms yourself. Plug in your own merge-tree that dumps to the console, and go from there.

If you’re careful with what you send, (d/transact) will make it pretty easy I think

Oh, make sure you have schema for reference attributes in Datascript

and then you can transact in pull results.

(assuming they have :db/id)

@jethroksy: well there ya go encouraging me to do even more work 😉

thanks

thanks for the tips, just started doing that, it does look like i can just d/transact the vector response

so looks like the return value from merge-tree replaces the reconciler :state?

so it should return the datascript conn

not understanding you….I believe merge-tree is called with the reconciler config

which has the state atom in it, which IS your datascript connection, isn’t it?

I’m not using Datascript, so some of this is from vague memory

you’re also going to need migrate (to rewrite tempids)

and I may not be exactly correct on any of this…you can plug in an override for merge, merge-tree, merge-ref, and migrate. I’d have to read the source to remember how they all connect; however, you will need to handle anything they do to the DB when using DS.

at the moment im getting assertion failures (conn? conn)

merge-tree isd/transact!ing the conn and returning conn

presumably the assertion error is due to subsequent reads and my state is no longer a datascript conn

line 1173 (or so) in next.cljs

state is always an atom (which is what DS uses as conn)…nothing changes that (nor can it) in reconciler. Immutable data and all. That is why it is an atom.

so, state cannot be “unbecoming” an atom

but it’s held value could change in a way that DS does not like

note, merge-ref is called, too…you might want to stub that and make sure it isn’t corrupting things

Hi! What would be the proper way to set the query parameters of a dynamically created (om.next) component? Do I need to use om/set-query! for that, or is there an argument that I can pass to the factory function?

yep, the default implementation looks like it would

@hans: Yes, it is set-query! now

just don’t pass the query

only parameters

is there a simple explanation for the purpose of merge, merge-tree and merge-ref?

tony.kay: ok. thanks! would that be done in the WillMount interface?

To any lurkers that like making SVG graphs from code: I’m working on that tutorial, and it would be awesome to have a devcard that could graph the Om AST so we can have a card where you can play with queries and see the resulting tree. Message me directly if you like playing with vizgraph-like stuff and would like to give it a try.

no need to know Om

(well, know enough to write a stateless render method…so very little)

@hans: set query should be done on a component, so anywhere you have a reference to the component is fine

(e.g. don’t pass it a Class)

@tony.kay: ah, ok, so i'll just set it right after i've created the component, in the caller. thanks!

you typically change a query in response to some event. You can get components from the indexer if you need to find one

or use “this” in the render of the component that owns the query

(in response to an event, e.g.)

render should be side-effect free, so obviously you don’t call it inline

maybe i'm doing things backward. i'm writing a (scrabble) game and i was thinking that each of the places on the board would be one component, that'd know its coordinate so that its query function would find the state of the place.

In general, some sub-component will fire off something, and you’ll want a parent to modify some upper query. Use callbacks for that.

what is dynamic about that query?

OH. I see.you’re trying to change the query of each tile as you put it on the Dom???

no, that isn’t how you want to do it

hm. ok, any advice what to do instead?

In fact, I would make tiles stateless…no query at all.

.... and the board would just return its fully rendered representation?

or a static query for just the properties at any cell, like [:tile/content]

then you’d join on board, and assume your response would be an ordered vector that you treat as a 2d array represented in 1d.

{:board (om/get-query Tile)} -> {:board [tiles…]}

the board is represented as a hash with [x y] as keys.

your code to write, I’m answering the Om-specific bits

the query language can give you a vector back…translating 1d -> 2d is trivial from there

of course. what i'm struggling with is how the board place view is connected to the place that it is viewing, but if I understand you well, having a view per place would not necessarily make sense. the thing is that i want to be able to detect clicks to places, which makes me think that a component instance for each of the places would make sense?

i'm sorry if i'm sounding dumb. i sure feel so

um, the vector response from your query would return maps. The maps themselves could contain the coords (what I’m calling tiles above).

{ :x 3 :y 5 :letter “A” :value 1 }

that kind of thing

yeah, that is basically what i have.

hmm, my assertion error (conn? conn) is actually happening somewhere between merge-tree and merge-ref (when reading another key)

i can't get merge-ref to run to try and debug that

so in your board renderer, just render that vector of things as a grid

tony.kay: ok. then, how do i connect the clicks on a tile to the tile that was clicked?

@danielstockton: probably because there are no refs in the response?

not really sure what refs means in this case

@hans: you would pass a callback INTO the tile component from board. Call that callback with the tile’s data

through om/computed and get-computed

but if merge-ref is never called, it can't be what's messing things up

@danielstockton: sounds right to me 😄

tony.kay: okay, i'll try that, thanks!

welcome

ahaaaaaa

so merge-tree had to return @conn (de-refed atom)

not conn

seems like the internals are swapping the state

so i was swapping my atom for another atom

(what my atom was holding, that is)

is there supposed to be a transact! here: https://github.com/swannodette/om-next-demo/blob/master/todomvc/src/cljs/todomvc/core.cljs#L69

@pat: That demo is not complete

I think he mainly wrote it for a talk, and has not had time to flesh it out completely

very simplistic but also promising https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/autocomplete.cljs

demonstrates many non-obvious things - how to conditionally remote, how to use core.async, how to use send etc.

the coolest part IMO is how dead simple the autocomplete ui is now that the asynchrony is removed

To anyone using my parsing helpers…quick note: I remembered during lucid dreaming last night that the AST has the type of the node…e.g. :join. This means you can make read be almost totally automatic on the default db format by switching on type and just calling the join parsing helper. See the sample version at: https://github.com/awkay/om-tutorial/blob/c2c1a2637d1d47c7bbe23a2b32c6add07dc8610b/src/main/om_tutorial/local_read.cljs#L16

oh wait…type is :prop…that’s unfortunate. OK, a little more work to detect the join, but hopefully you get the point.

you know you have a join if :query is present

yeah, I know…just saying it isn’t in type.

right we only distinguish :prop and :call

was writing the code to test it out…also, if you’re doing a recursive query, the query from the parent’s ast sticks around unless you remember to clear it

Yeah, that collapses the entire read function for the Om default database format to about two lines of code unless you’re using unions or …

hrm thinking about the selector issue … looking

ah real quick

thinking about renaming

:query/root to :om.query/root

the former just seems weird

:om.query/root is probably more accurate to what it represents

it only appears in the AST, right?

and nothing else in there is namespaced…I’d actually vote the other way: :query-root

I was thinking it was in the state for a second, I'd agree with that.

@tony.kay: good point it always appears in the AST

:query-root is better

So, I’ve been writing helper functions, like I mentioned above…I just tested out the generalized form, and it seems like it will work for reading the default database format (not supporting union yet). Also has support for decomplecting client-local data from stuff that came from a server by storing it in separate tables in app state, and “merging” them back in during query processing.

very alpha, but also stands to eliminate lots of code. Also has support for recursive queries with … (including those that loop on themselves!)

e.g. Joe is married to Sally is married to Joe is married to Sally...

(though the loop support isn’t really “true” loop support, it is depth limiting that you can specify)

sounds cool!

I’m pretty happy with it so far. I was working on a SAX-style of local read that let you change read functions during recursion instead of multimethods (easier to trace), then the other stuff started falling out. I think I can make most of the common use-cases for local read automatic. I’m only using it with a very small toy app at the moment, but I’m not seeing big holes.

I’m probably more excited about the auto separation of client-local state…decomplects a whole mess of stuff: you write a query like [:ui/checked :person/name] and it scans for the UI bit in a top-level table.

@tony.kay: yeah, I definitely didn’t expect multimethods to be the only approach to parsing

in fact was somewhat concerned that the top level being implicit would create too many issues for alternative approaches

so interested in feedback about that

auto separation of client local / server sounds neat, but does your approach generalize to DataScript?

have not thought about that…was trying to make a plug-in for the default db format

yeah this is why things ended up the way they did to a large degree

concern for other stores

yeah, I know…but for those using the “default”, it would be nice not to have to write much of the read stuff.

yep automating stuff for people using the default is a good thing

pushed :query/root -> :query-root to master

also :query should never be stale now, we always get it from the AST

This is what I have for a datascript parser

nice, thanks. If you have two clicks, look at this: https://github.com/awkay/om-tutorial/blob/master/src/main/om_tutorial/local_read.cljs Very short. Three different read implementations using the support functions. read-local is hand-combined. generic-read-local is one that should mostly work everywhere, and split-read-local is like the first one, but split SAX style.

looking

oops…that last line should be calling split-read-widget

UI is in https://github.com/awkay/om-tutorial/blob/master/src/main/om_tutorial/ui.cljs, so you can see the queries

very short as well

@tony.kay: so I’ve made the changes to make :join a AST :type

all tests passing over here

sound good?

ok by me

done!

Hey, any clues as to how I’d get cljs.repl/source to work on cljs that has #js reader tags?

devcards can’t render my example code because it has those

I traced it to that function, which traces down into the clj reader stuff, tried adding a js data reader to my clj runtime, but no luck

hrm

@tony.kay: that’s definitely a #C07UQ678E bug

I would file an issue in JIRA and I can take a look

you might try it in your own devcard. Just use bhauman’s (dc/mkdn-pprint-source some-fn-var)

ok, I can do that

no need

I know it won’t work

I don’t think we setup the reader correctly there for this

(I wrote that code)

oh, ok. Yeah, I traced through the analyzer and such, but yeah, it got complicated

http://dev.clojure.org/jira/browse/CLJS-1488

wow, there are a lot of open issues…tried to search for an existing one..

fortunately not more than most projects this mature

no existing issue for that one (I know pretty much all the open ones)

just pushed to master

exported ast->expr and expr->ast from parser namespace

also expr->ast is now fully recursive

fixed up the AST bits some more, the AST is now walkable via :children a la ClojureScript AST

should open the door to generic transforms

yeah the combination of multiple remotes, core.async looks like it will be a super slick way to manage the async complexity while keeping the UI declarative and highly testable

https://github.com/omcljs/om/commit/5e32eb20e4ce0bf1bbf2f272b2c28663e9e9bc94

autocomplete example updated to the new query->ast helper

Awesome. I didn’t realize you had devcard examples, I need to check those out.

@noonian: yep there’s been a lot of fixes to make devcards usage simpler

yeah mock-root looks really nice