Fork me on GitHub
#om-next
<
2016-06-16
>
alberto.portilla09:06:29

Is there a way to force a remote read even if there's already a value for that query in the local state? can't find a way to do it

hlolli10:06:24

You could probably set up your read method to choose from remote or local state depending on some conditions. The behaviour I've noticed so far is that for read with remote, the value fetched from remote will overwrite the app-state for that key. But om.next keeps surprising me, and I do have from time to time similar diffuculties.

alberto.portilla10:06:00

Yes, om.next merges the state on a successful read. The issue here is picking the right condition to force a remote and the return value when using the remote

alberto.portilla10:06:16

I mean, usually a remote call looks like

(defmethod read :query
  [{:keys [state]} k _]
  {:remote true :value (get @state k)})

alberto.portilla10:06:37

but if i already have the key on my state, it will be returned while the remote call is being fetched

alberto.portilla10:06:21

and after that, of course, the state gets updated, meaning that while the result is fetched, the app is being rendered with an old state

hlolli10:06:56

Just thinking out loud, wouldn't this be possible

(defmethod read :query
  [{:keys [state]} k params]
  {:remote (:remote? params) :value (get @state k)})
and in the defui you would query with parameters '[(:query {:remote? ?some-query})]

hlolli10:06:28

where ?some-query is a boolean.

alberto.portilla10:06:11

Wouldnt that cause the effect that ive mentioned before?

alberto.portilla10:06:33

the :value key is always returned when the read occurs, meaning that in first instance it will return the current state

alberto.portilla10:06:48

and after the remote merge, itll return the new state, with the remote values fetched

hlolli10:06:09

yes that is right. But if remote is true, I would assume it would first try getting data over the wire before looking at local state. But I may be wrong, curious to know if that is the case.

alberto.portilla10:06:20

Actually it doesnt, the first render shows the current state data, maybe im doing something wrong with it, but thats whats happening

hlolli10:06:23

ah ok I see. I am also these days having diffuculties with remote read. Your problem could be connected to the problems I am having, well I think it's quite likely when I think about it.

alberto.portilla10:06:16

My first guess was clearing the query value on componentWillMount, but sometimes a race condition is produced

alberto.portilla10:06:30

ill try to get a better approach

alberto.portilla10:06:19

best way to check this is delay the remote response like x seconds, and you will see the old state rendering, and after x sec the remote state

hlolli10:06:11

ok, there must be a good way to handle these cases. So I hope to see someone else here commenting on this. If I find out a solution I let you know, and vice versa in that case.