Fork me on GitHub
#om
<
2017-04-23
>
peeja17:04:39

Is there a good way to get the reconciler to queue a send of the entire root query to a particular remote every time the state changes?

peeja17:04:01

(I'm still trying to work out a good way to implement live queries.)

petterik17:04:52

@peeja Everytime the state changes on the client or on the server? On the client, could you use TxListen? On the server, I push some change notifications of a read that's changed along with datomic's basis-t. Using basis-t (or something similiar) I can avoid sending requests I've already read data for when there are frequent updates. I use (om/transform-reads reconciler [:key-to-read]) to queue the reads locally and remotely. Lastly, to find all reads for a specific remote, could you maybe call (and memoize) (keys (parser env (om/query (om/app-root reconciler)) remote))?

peeja17:04:13

On the client. :tx-listen might do it…

peeja17:04:57

Maybe the parser already runs as I need it?

peeja17:04:19

I tried swap!ing the state and didn't see it, but perhaps transact! will always do what I need

peeja17:04:25

and that's what I'd be using in real life anyhow

peeja17:04:02

Oh, no, transact! will only read what I tell it to read…

petterik17:04:03

Yeah. Firing off another transact! in :tx-listen depending on what was transacted or what's being transacted maybe?

peeja17:04:15

Doesn't that recurse infinitely?

peeja17:04:59

I guess it feels like I'm doing extra work to undo things that Om's doing "for me".

petterik17:04:00

Depends on how you examine what is being and what was transacted

peeja17:04:17

I don't want to transform-reads a specific set of keys, I want the whole query

peeja17:04:26

(as processed by the parser for the given remote)

peeja17:04:12

My plan is to have something stateful stay informed of changes to the query, and adjust the live data it listens for appropriately

peeja17:04:38

which means it always needs a new copy of entire root query any time it (may) change, to run a diff

petterik17:04:04

What if you put this stateful thing in :shared and call it either from your root component everytime it updates, or via :tx-listen depending on what you need

peeja17:04:32

I feel like the components shouldn't know this thing exists

peeja17:04:45

:tx-listen may work

peeja17:04:14

How do I transact! to read the entire root query from a remote?

petterik17:04:54

I don't think you can do it out of the box, but I can think of two ways of doing it

petterik17:04:07

1. call the parser, then call transact! with some result

peeja17:04:40

How would I "call the parser" other than through transact!?

petterik17:04:23

2 (the way I'm doing it), wrap your parser in a function which looks for a dynamic var, for example *allowed-remotes*, and returns nil if the env's :target is not in *allowed-remotes*. Binding it using binding

petterik17:04:49

You'd get the parser from (:parser (:config reconciler))

petterik17:04:04

and call (#'om/to-env reconciler)

peeja17:04:13

Ew… 🙂

petterik17:04:29

Solution to all om.next problems is another parser middleware

peeja17:04:50

I've got middleware out the wazoo as it is, but it's not fixing this one yet 🙂

peeja17:04:35

How does *allowed-remotes* help?

peeja17:04:10

I believe I'm not getting the parser call I want in the first place

petterik17:04:01

(binding [*allowed-remotes* #{:the-remote-you-want}] (om/transact! reconciler (om/get-query (om/app-root reconciler)))) would get the full query with only the remote you want

peeja17:04:46

Oh, I see. Sure, that'll work.

petterik17:04:22

Oh sorry, I apparently left that bit out

peeja17:04:48

Can I accomplish the same thing by forceing the remote? I'm not entirely clear on what that does.

petterik17:04:06

I don't know. Maybe. I'm not clear either of how to use it

petterik17:04:12

I've never used it

peeja17:04:27

Yeah, I can't get that to do anything useful. Oh well. *allowed-remotes* may be what I'm stuck with, as hacky as it is. 🙂

peeja17:04:31

Thanks for the help!