Fork me on GitHub
#om
<
2016-02-25
>
jimmy02:02:50

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

tawus02:02:10

Any strategies for returning errors after submission of a form ?

jimmy03:02:02

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

jimmy03:02:44

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

tawus03:02:22

Cool! Thanks @nxqd

jimmy03:02:32

glad it helps

jimmy03:02:47

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

tawus03:02:47

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

jimmy03:02:52

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

tawus03:02:46

Yes, I use pushy and bidi

jimmy05:02:38

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

geraldodev05:02:05

@nxqd put static at the front of the method ?

jimmy05:02:26

like this static (myFn [this] ) ?

geraldodev07:02:44

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

jimmy07:02:18

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

tawus07:02:39

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

dnolen13:02:45

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

jannis14:02:27

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

thiagofm14:02:36

Would this be possible?

jannis14:02:53

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?

jannis14:02:47

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

rauh14:02:06

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.

grzm14:02:18

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

rauh15:02:03

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

grzm15:02:26

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

rauh15:02:33

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

rauh15:02:54

@grzm: Nope, never done AWS.

dnolen15:02:41

@rauh you can pass additional handlers

rauh15:02:29

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

dnolen15:02:02

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

dnolen15:02:14

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

rauh15:02:59

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

dnolen15:02:56

unlikely to do anything else around transit

dnolen15:02:10

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

jlongster15:02:59

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

dnolen16:02:13

@jlongster: yes that’s pretty weird

jlongster16:02:38

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

dnolen16:02:52

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

jlongster16:02:00

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

dnolen16:02:06

@jlongster: yes that’s better

jlongster16:02:44

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

dnolen16:02:46

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

jlongster16:02:05

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

dnolen16:02:05

guaranteed to make something brittle if you go that route

jlongster16:02:14

yeah I figured

jlongster16:02:31

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

dnolen16:02:02

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

jlongster16:02:33

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

jlongster16:02:51

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

dnolen16:02:19

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

jlongster16:02:53

@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

jlongster16:02:18

or we could just add that function that I made

dnolen16:02:26

@jlongster: yes I’ve been thinking about that

dnolen16:02:37

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

jlongster16:02:48

ok cool, was planning on doing that, thanks

jlongster16:02:03

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

dnolen16:02:12

cool, that’s good to hear!

tianshu16:02:29

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

tianshu16:02:24

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.

dnolen16:02:46

@doglooksgood: because maintaining state in two places is harder

dnolen16:02:00

just completely uninterested in the implementation complexity

tianshu16:02:05

!!!! Meet David Nolen! Thanks for the reply simple_smile 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.

dnolen16:02:24

@doglooksgood: that may be fine for your application

dnolen16:02:37

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

dnolen16:02:09

definitely not the ones I have in mind

anmonteiro16:02:54

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

anmonteiro16:02:04

I think this is the way forward

anmonteiro16:02:21

Just leverage the indexer in get-query as well

dnolen16:02:29

even better!

dnolen16:02:41

it’s nice to see the hunch getting confirmed

anmonteiro16:02:49

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

anmonteiro16:02:58

and cascade them up the classpath

dnolen16:02:06

sounds right

anmonteiro16:02:13

then the root has the notion of things

anmonteiro16:02:21

it took time

dnolen16:02:29

haha, no doubt simple_smile

anmonteiro16:02:31

but, man, did I learn

anmonteiro16:02:51

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

jlongster16:02:35

@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

jlongster16:02:19

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

anmonteiro16:02:06

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

jlongster16:02:40

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)

anmonteiro16:02:24

@jlongster: well, subquery was always there simple_smile

anmonteiro16:02:46

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

jlongster16:02:02

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

anmonteiro16:02:18

yep, like routing "from below"

anmonteiro16:02:40

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

jlongster17:02:03

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?

dnolen17:02:19

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

anmonteiro17:02:36

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

anmonteiro17:02:09

@dnolen: will do, thanks

jlongster17:02:35

@anmonteiro: cool thanks, that worked

selfsame17:02:20

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

dnolen17:02:12

haha amazing

denik17:02:29

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.

selfsame17:02:14

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

denik17:02:14

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

denik17:02:29

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

hueyp17:02:17

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

anmonteiro17:02:31

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

anmonteiro17:02:40

or is it being triggered between events or something

tony.kay17:02:05

@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)!

denik17:02:08

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

denik17:02:34

@hueyp: what do you mean?

hueyp17:02:18

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

hueyp17:02:23

e.g not-complete -> complete

denik17:02:18

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

denik17:02:53

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.

selfsame17:02:53

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

denik17:02:04

@selfsame: haha nope not this time

denik17:02:13

but it could in the future

denik17:02:36

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

selfsame17:02:15

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

denik17:02:57

@selfsame: using core.async?

denik17:02:21

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

denik17:02:54

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

selfsame17:02:14

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

selfsame18:02:32

@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

denik18:02:24

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

dnolen18:02:47

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

selfsame18:02:22

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

anmonteiro18:02:28

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

denik19:02:15

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

7h3kk1d20:02:14

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.

dnolen20:02:43

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

7h3kk1d20:02:16

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

7h3kk1d20:02:45

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

dnolen20:02:46

not interested in maintaining multiple libraries

dnolen20:02:19

no other real reason than that

7h3kk1d20:02:14

Thanks a lot!

7h3kk1d20:02:29

Really appreciate the response firsthand

tmorten22:02:51

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

anmonteiro22:02:54

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

anmonteiro22:02:14

it seems to me that there's a bug here

anmonteiro22:02:28

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

dnolen22:02:28

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

dnolen22:02:45

right so we should preserve anything that needs to be preserved

anmonteiro22:02:21

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

anmonteiro22:02:19

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