Fork me on GitHub
#om
<
2016-04-25
>
Stefan Roex07:04:20

I’ve been playing with om.next over the weekend. Still trying to grasp all the ideas, but I think I get the main points simple_smile. However, I cannot find anything about loading-states. When I delegate a mutation or read to a remote, how do I know if its loaded (or errored)? I’d like to show a loading-indicator in the UI when appropriate.

devth15:04:22

is getInitialState not supported in om next? I defined it but it's never called, and my component state is initially empty

anmonteiro15:04:09

@devth: use initLocalState

devth15:04:58

@anmonteiro: perfect, thanks!

drcode17:04:59

@stex: Check out https://github.com/omcljs/om/wiki/Om-Next-FAQ#how-can-i-implement-optimistic-commits. I think what you want to do is "optimistically" set a special flag in the local state that says an item is still loading, which will then be removed when the server response is merged in

iwankaramazow17:04:45

@stex: take a look at the #C0PULSD25 framework built on top of Om Next, if you need inspiration. or you could try to implement the following: (basically what untangled does) -implement a new mutation which places a loading marker at the appropriate place in your state, before sending the mutation of to the remote -make sure you also place the onSuccess or onFailure in your app state. (you could combine that with the previous step) -when a remote comes back with the response, get the onSuccess or onFailure handlers out of your state and run those (you need to have the reconciler available in your send function..)

Stefan Roex18:04:51

@drcode. Thanks, didn’t think about that! I’m not sure what I actually like it, since it feels quite low level. Maybe I need to play with it a bit.

Stefan Roex18:04:01

@iwankaramazow: Thanks! I did have a quick look at the untangled client framework, and I’m not 100% sure how it works yet. Do you have experience with this in production apps? I’m currently working in an app which wraps all remote calls in go-blocks, which enables you to fire requests all at once, or one after another. Doing this with callbacks would result in a mini callback hell.

Stefan Roex18:04:44

But haven’t enough om.next experience yet. A single remote-call is probably enough for most use-cases.

iwankaramazow19:04:26

@stex: define 'production' 😛 I have a small app in 'production' which manages lectures for a chiropractor, more of a glorified todo-list app with routing. I store a bunch of mutation-queries in my app state, whenever a response arrive, I transact those mutations given the new state (w/ response merged back in)

iwankaramazow19:04:28

Ofcourse I remove those mutations whenever they're transacted

iwankaramazow19:04:40

This is pretty basic, but it works

iwankaramazow19:04:31

Example: [(auth/login {:mail ~mail :password ~password}) (post-mutate {:query [(redirect-to-dashboard!})] , the post-mutate part gets run once the response arrives

iwankaramazow19:04:40

stole that shamelessly from untangled 😇

isak20:04:59

@iwankaramazow: if a user is typing in a field, starts a server sync, then keeps typing while it is happening, will this be handled correctly with your strategy?

isak20:04:33

or will the field get the dirty bit cleared when the request comes back

Stefan Roex20:04:06

@iwankaramazow: Thats actually quite nice! Where did you stole it from? Would love to see the rest of the code simple_smile

kendall.buchanan23:04:05

Question: Nothing I’ve seen suggests otherwise, but is it correct to assume an Om component can be rendered within a React.js component (in a pure JS project)?