Fork me on GitHub
#om
<
2016-07-28
>
ag00:07:11

I think I got it, one last thing though I’m curious how you did it what dom-node would be here?

anmonteiro00:07:00

@ag: sorry I don’t understand what you’re asking

ag00:07:28

in the snippet there’s a function dom-node what’s that?

anmonteiro00:07:56

@ag: ah right

anmonteiro00:07:01

that’s devcards.core/dom-node

ag00:07:11

oh… ok…

anmonteiro00:07:12

it’s a macro

ag00:07:39

Once again… thanks a ton!

hlolli08:07:49

Anyone had problem with two transaction in one event? Because if I do either one of the two transactions everything works fine, but at same time, then I lose all property data. But it pops up back in when I do anything that will rerender, in my case update-state!

peeja14:07:27

Is it typical to send the entire query to a remote, even if part of the query can be satisfied by local data? I don't see an easy way to filter the query to only the parts which the local app state can't satisfy, which seems like it puts a big burden on the server. For instance, if you have routes, when a route changes you'll re-read the root query, and that means asking the server for the entire page's data, even if you already have most of it.

peeja14:07:19

OTOH, you'll also display the local copy immediately, and re-fetching it is a chance to get a fresh copy of possibly-updated data from the server, so maybe that behavior is desired?

hlolli14:07:00

Is it a huge query you are sending. Personally I've chosen to send everything, since the server cant know who is asking for it (no users). I think that this is a question about 10 to 20 kb of json data(max), not sure if that's much difference for a server, depending on the scale of course. But Im just thinking out loud.

peeja14:07:29

Well, what's behind the question is a conversation from yesterday. I'm actually building an app that talks to REST endpoints, and I'm trying to figure out the best way to make that work. A deep query may involve several HTTP requests to fulfill. Trimming that to only the data that's actually missing would mean a lot fewer requests.

peeja14:07:16

But it occurred to me last night that even people with queryable APIs must need to separate the part of the query that can be satisfied locally from the part that can't.

peeja14:07:33

And then this morning I realized that maybe people usually don't, and just fetch everything all over again. 🙂

hlolli15:07:24

Count me in for the latter one. Im building a search front end. And I just send everything, also the empty fields as empty [] or #{}. That way the backend team can't be mistaken for what the user is asking for. But in my case this is penuts of data.

peeja15:07:55

Yeah, for something like that, that makes a lot of sense.

anmonteiro16:07:42

@peeja: I don’t think Om Next would be quite a solution for a lot of stuff if it didn’t allow you to send only certain pieces of the queries to remote endpoints 🙂

anmonteiro16:07:06

this is to say that you have some options to achieve just that

anmonteiro16:07:58

one of the benefits of the query language is that it’s just data

anmonteiro16:07:27

as such, you can manipulate it as you please

peeja16:07:33

I mean, I know that I can filter the query, but I was assuming that was a common enough case that Om would come with something that would do it for me.

peeja16:07:50

Maybe that just has yet to exist. 🙂

anmonteiro16:07:56

I think it exists already

anmonteiro16:07:05

om.next/process-roots is a thing

anmonteiro16:07:14

leveraging the power of the AST is another option

peeja16:07:45

Maybe it just has yet to be documented, then. 😉

anmonteiro16:07:57

@peeja: Right, pretty much everything does!

peeja16:07:01

process-roots looks pretty promising

anmonteiro16:07:06

no argument from me there

peeja16:07:23

I hope to be able to help with that once I have my own head around how things work.

anmonteiro16:07:31

that would be awesome

anmonteiro16:07:49

@peeja: one more thing, and kind of a shameless plug

anmonteiro16:07:20

I understand it might not be desirable for you to change stuff at this point, but even if you don’t use it you can see how I have implemented stuff in Compassus

anmonteiro16:07:43

re: sending only the queries for a particular application route

peeja16:07:56

Oh, interesting, I didn't realize it did that

anmonteiro16:07:30

perhaps I should explicitly document that, I didn’t realize I hadn’t written anything about it

peeja16:07:33

I'm not sure I understand process-roots. How can it take just a query? How does it know what should be local and what should be remote?

anmonteiro16:07:07

you annotate your query with a ^:query-root metadata

peeja16:07:02

Oh, interesting.

anmonteiro16:07:29

(you can also (assoc :query-root true) to the AST)

peeja16:07:46

Ah, that makes sense

peeja16:07:19

I think what I'm really looking for is something like (missing-data-query query data app-state-db) (it takes the same args as db->tree), which returns a query for everything the given query asked for that wasn't found in data & app-state-db.

peeja16:07:43

Then I can pass that on to the remote to get everything I don't have yet.

anmonteiro16:07:58

@peeja: probably something that you need to implement yourself

anmonteiro16:07:05

I can see that being useful in some cases

peeja16:07:29

Implementing something on the order of db->tree terrifies me, but I think you're right.

peeja16:07:21

Is there a reason db->tree runs through its logic using the query data structure instead of converting it to an AST first? That seems like it would be easier to work with.

anmonteiro16:07:24

@peeja: happy to provide feedback along the way

anmonteiro16:07:59

IIRC, db->tree predates the AST

peeja16:07:06

Ah, that would make sense

anmonteiro16:07:07

I also think there would be a performance hit

peeja16:07:16

Oh, is the conversion that bad?

anmonteiro16:07:26

depends on the query

anmonteiro16:07:54

but query->AST is a bunch of recursive calls for sure

anmonteiro16:07:57

db->tree some more

anmonteiro16:07:24

ofc I’m just empirically saying that, I haven’t measured

anmonteiro16:07:36

so take my words with a grain of salt

peeja16:07:59

Yeah, I'll probably at least start with the AST just for my own sanity 🙂

anmonteiro19:07:01

just pushed devcards-om-next 0.3.0 to Clojars. Changes include working server-side rendering for cards and actually supporting devcards options in defcard-om-next https://github.com/anmonteiro/devcards-om-next

nha22:07:17

Just stumbled upon this, thought I would share it here: https://github.com/acdlite/react-fiber-architecture

dankweaver22:07:54

hey folks. wondering if anyone knows of any good examples of integrating Om.Next with existing REST Apis. I imagine the story is similar to doing so with graphql.. mapping 'fields' to resources. http://graphql.org/blog/rest-api-graphql-wrapper/

dankweaver22:07:16

Haven't seen any similar conversation in my om stumblings though.. Wondering if any prescribed solutions exist that i'm missing.