hi guys I have a tap channel as a state in initialState, would it have any problem while data sending through the channel ( for example: triggering rerendering ? )

Any strategies for returning errors after submission of a form ?

@tawus: you can check the function default-extract-errors from om next.

if there is an error, regarding invalid input or such you can return with the format {:error << IIRC, then use that function to extract the error ( nested support ) in parser

Cool! Thanks @nxqd

glad it helps

@tawus: https://github.com/omcljs/om/blob/93e007fb72327ea35c3ad106f090f1209d442a7c/src/test/om/next/tests.cljs#L1482-L1494 it's actually {::om/error}

I think if it works for you so be it. I use om/set-query! method it works just fine.

Sorry, I am also using set-query not sub-query

have you managed to make it work with a routing lib ( like secretary ) and html5 history ?

Yes, I use pushy and bidi

oh nice

hi guys how do we create our own statics stuff in om next. React has statics in createClass to store statics ( for shared function and attributes ... )

@nxqd put static at the front of the method ?

like this static (myFn [this] ) ?

@nxqd i've used static in front of my own protocols. it worked. Like that i've never tried

@geraldodev: yeah, it seems the only way to do it. The reason I ask is because I see that React has the statics stuff, I don't know if there is a built one in om we can use.

https://facebook.github.io/react/docs/component-specs.html#statics

::om/errors gets hold of the exception but om/transit can’t serialize it. This is what i get java.lang.Exception: Not supported: class clojure.lang.ExceptionInfo

@tawus: you need to write a transit handler for it if you want that to be something that can go across the wire.

Has anyone done any work around translating Om Next queries to DataScript queries?

Would this be possible?

Ignoring unions and parameterization for the moment, the only real challenge are links/idents. E.g. a query for {:projects <subquery>} can easily be translated to a query like [:find [(pull ?e <subquery>)] :where [?e :project/name]]. However, links/idents in <subquery> are invalid pull query syntax. My first idea was to extract the links, remember the "path" they came from, query them separately and then merge them into the props of all entities returned for the query at the corresponding path. Is this realistic?

Ok, I mean, it is realistic. A better question would be if there isn't a better way of doing it.

For the record/logs: Pedestal interceptors to handle om.next tempids: https://gist.github.com/rauhs/c137c0518cb7067f58ee May it help somebody. Took me too long due to the weird bracket necessary around the :handlers map.

@rauh: cheers. how's your experience with pedestal been?

@grzm: I love it, especially the flexibility with interceptors. I wish there was a real documentation page though.

@rauh: Cool. What I've read and heard about really appeals to me, but I haven't really spent any time with it. Any experience hosting on AWS?

@dnolen: In my gist 2 lines above: I need to recreate the om/id transit handler with the reify. I think it'd be helpful to have get-handlers helper function in om.transit namespace.

@grzm: Nope, never done AWS.

@rauh you can pass additional handlers

@dnolen: What I mean is to just move that handler map out of the reader function so people can use it.

@rauh: or just make your own transit reader/writer

I might expose some convenience thing later - but this not a priority

Yeah def. also not a priority for me It'd just be convenient for pedestal users. Now I have to watch out I keep in sync with the implementation.

unlikely to do anything else around transit

so I don’t forsee many problems if you go your own way

is it wrong to reference the reconciler directly within a component? I have a transient drop-down that lists all the items that currently exist in a table in the app state. the component doesn't exist until you start typing in a field, so I can't query it up front. and besides, I want the latest data from the app state, so I'd have to make sure that whenever an item is mutated that the it gets the new list, but I don't want to tell the whole system to re-read the whole list (everything else uses pathopt and just directly updates an individual item). The only thing I can think of is to manually query the reconciler when the drop down appears

@jlongster: yes that’s pretty weird

I think I figured out a solution: create a new key that returns all the items

but it may be there’s something missing to make that cleaner, we’ve been brain storming about the dynamic query cases.

and whenever an item is mutated I include that key to be read afterwards

@jlongster: yes that’s better

yeah, I'm not sure dynamic queries are even what I want, it's such an extreme case of just wanting the latest data. a simple key is pretty easy

if you ever feel like you need to talk directly to the reconciler or indexer I want to know about it

I'll let you know if this doesn't work!

guaranteed to make something brittle if you go that route

yeah I figured

the only downside is the growing number of keys to remember when mutating

right, but then there's maybe something around that which is worth considering

yeah, we'll see. trying get a v1 done and then I'll think about all this

my experience has been good but there may be a few things we can improve

yes happy to see a writeup from you somewhere when you get a chance

@dnolen: there is one main problem I've hit that might require changes: any chance we could use React's context to pass the *reconciler* and other variables across components? The problem is that I'm using an existing React component (https://github.com/bvaughn/react-virtualized) which creates components. It will create components outside of the Om render cycle, so those variables are null. Using context should fix this. I temporarily introduced a function copy-bindings which copies the internal omcljs$... references to the reconciler/indexer/etc

or we could just add that function that I made

@jlongster: yes I’ve been thinking about that

would even take a pull request for that since it’s a pretty boring change

ok cool, was planning on doing that, thanks

would make React interop A+! so far it's already pretty good, that's the only thing I've hit

cool, that’s good to hear!

I have a question, why should state be store in one place, not two?

The state from server should never be changed directly, I think. this state should not be merged into app-state that used for browser local state.

@doglooksgood: because maintaining state in two places is harder

just completely uninterested in the implementation complexity

!!!! Meet David Nolen! Thanks for the reply But when I ask server for data, I actually don't want to care about how this data be saved in my app-state, and I will never modify it.

@doglooksgood: that may be fine for your application

but it is not fine for other kinds of applications other people want to build

definitely not the ones I have in mind

Okay

@dnolen: I'm finishing up on writing some tests for the dynamic query stuff

I think this is the way forward

@anmonteiro: cool!

Just leverage the indexer in get-query as well

even better!

it’s nice to see the hunch getting confirmed

when re-indexing, look for queries that are in to-one joins

and cascade them up the classpath

sounds right

then the root has the notion of things

it took time

haha, no doubt

but, man, did I learn

😄

@dnolen: should I submit it in relation to an existing issue (the routing one?) or create a new one

@dnolen: fwiw, creating a new key did not work because I can't easily map any key arbitrarily across the query structure because I use db->tree. So the structure might be [{:tab/home [{:table [:all-items]}]}] and I run db->tree on that. The only time I recurse into the query is when remoting. Anyway, now I'm using a link to the table, like [:accounts/by-id _] deep in the query, and that actually seems to work alright. Not sure if there's a better pattern, but I'll think about it

@anmonteiro: that's exciting, can't wait to try it out

@jlongster: it is exciting stuff and brings new possibilities with it

yeah, this will make it a lot easier to make dynamic UIs. I saw your subquery example in your routing post and I've always wanted something like that even (not sure what else your work exposes)

@jlongster: well, subquery was always there

and will continue to be for the one->many cases

yeah, I assume what you're doing makes a bunch more dynamic use cases easier

yep, like routing "from below"

which basically renders subquery unnecessary for the 1->1 case

is this the right way to use refs? (om/computed table {:ref :table}) when rendering and then use (om/react-ref this "table") to get it?

@anmonteiro: make a new one since the idea is really more general please … thanks

@jlongster: I think you need to assoc the ref into the props directly

@dnolen: will do, thanks

@anmonteiro: cool thanks, that worked

screenshots of the 3 om.next projects I've been juggling: https://s3.amazonaws.com/screenularity/om.html

haha amazing

is there an event-handling queue in om.next? I have two events firing in rapid succession with a crucial om/transact! triggered by the first event which the second event should build on. Since they’re only milliseconds apart, new props are not yet available.

@denik I run a second animation frame that clears out any accumulated input handlers

hmm. I don’t want to lose the event. But I want to make sure that new state (from the previous event’s transact) is available

@selfsame: ^

in other words I’d like to block until the transact happened and we rerender

you can make the event status (complete or not) explicit in your state

@denik: can't you take advantage of the lifecycle stuff in React?

or is it being triggered between events or something

@anmonteiro: A sincere note of thanks and appreciation for stepping up on the dynamic queries (and all of the help you're giving on this channel)!

@anmonteiro: I don’t think I can. If the second event came a second later later everything would be fine.

@hueyp: what do you mean?

if the result of the event was in your state, you could use the react life cycle to watch for deltas

e.g not-complete -> complete

@hueyp: that's true. That seems hacky though. If one event triggers a transact!, then that transact should complete before the next event is processed.

otherwise the previous event transacts on the old state, eventually overwriting the first event, where it could be aware of it and run a different transact.

@denik this have something to do with a mouse drag?

@selfsame: haha nope not this time

but it could in the future

where a drag-start and drag event are called almost simultaniously

I keep react and non discrete input events as far away from each other as possible.

@selfsame: using core.async?

in general it just sounds like a bug to me that two om/transacts can run on the same state where one non-discrete event could overwrite the other

and there is no way to run a check in-between

yeah I have a async state machine for the mouse and window/UI resizing events are handled by a reagent in the head that renders css sheetts

@denik is event 2 assuming om state has been affected by event 1? You probably just need to swap your own an atom or something

@selfsame: yes

event 2 depends on the changes of event 1 - contextually event 2 makes no sense without event one

@anmonteiro: I'll block out some time to dig into your PR tomorrow

@denik yeah transact is happening once per frame your events will have to have their own system

@dnolen: cool, thanks. Looking forward to hearing feedback

@selfsame: thanks. Since transacts are queued I could have my conditionals in the mutate function. Will try that next

This may sound really ignorant but is om-next the clojure equivalent of relay/graphql/react. I realize that the om-next page says it borrows heavily from graphql/falcor but it also seems to have the relay concept of declaring queries in components.

@7h3kk1d: perfectly valid question - yes heavily inspired by Relay

@dnolen: is there a reason it’s one library in om and not 3 or so like in the graphql space or was it just easier to create that way?

I’m just getting started in cljs and am trying to understand what tools to use and where.

not interested in maintaining multiple libraries

no other real reason than that

Thanks a lot!

Really appreciate the response firsthand

Hello all! Does anyone have experience using the Om.next default merge to merge response coming back from a mutation remotely? i.e. using the :value key in the response of a mutation? It seems like my top-level idents will not merge...I was under the impression that if I put a key/value pair into the :value key of the response the default merge will merge it into the app state

@dnolen: looking at the default-migrate, it reset!s the app-state by running (tree->db (db->tree))

it seems to me that there's a bug here

since we store component queries in the state, they'll get blown away

@anmonteiro: there might be, but that’s a “GC” step

right so we should preserve anything that needs to be preserved

@dnolen: atm I think it's just the ::queries key. anything else I'm forgetting?

there might be non-normalized data in the state that users might want to preserve, but I wouldn't worry too much about that since people can always write their own migrate function