This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-28
Channels
- # admin-announcements (4)
- # beginners (11)
- # boot (148)
- # cider (74)
- # cljs-dev (31)
- # cljsrn (30)
- # clojure (55)
- # clojure-berlin (15)
- # clojure-greece (1)
- # clojure-japan (18)
- # clojure-poland (35)
- # clojure-russia (72)
- # clojure-spec (35)
- # clojure-uk (34)
- # clojurescript (134)
- # cursive (26)
- # datomic (42)
- # dirac (7)
- # editors-rus (1)
- # emacs (17)
- # hoplon (29)
- # jobs-rus (3)
- # juxt (1)
- # luminus (11)
- # off-topic (9)
- # om (66)
- # onyx (49)
- # pedestal (1)
- # perun (19)
- # proton (13)
- # protorepl (5)
- # re-frame (31)
- # reagent (13)
- # ring (2)
- # spacemacs (1)
- # specter (40)
- # spirituality-ethics (2)
- # test-check (41)
- # untangled (7)
- # yada (17)
I think I got it, one last thing though I’m curious how you did it what dom-node
would be here?
@ag: sorry I don’t understand what you’re asking
@ag: ah right
that’s devcards.core/dom-node
it’s a macro
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!
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.
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?
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.
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.
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.
And then this morning I realized that maybe people usually don't, and just fetch everything all over again. 🙂
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.
@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 🙂
this is to say that you have some options to achieve just that
one of the benefits of the query language is that it’s just data
as such, you can manipulate it as you please
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.
I think it exists already
om.next/process-roots
is a thing
leveraging the power of the AST is another option
@peeja: Right, pretty much everything does!
no argument from me there
that would be awesome
@peeja: one more thing, and kind of a shameless plug
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
re: sending only the queries for a particular application route
perhaps I should explicitly document that, I didn’t realize I hadn’t written anything about it
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?
you annotate your query with a ^:query-root
metadata
(you can also (assoc :query-root true)
to the AST)
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
.
@peeja: probably something that you need to implement yourself
I can see that being useful in some cases
Implementing something on the order of db->tree
terrifies me, but I think you're right.
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.
@peeja: happy to provide feedback along the way
IIRC, db->tree
predates the AST
I also think there would be a performance hit
depends on the query
but query->AST
is a bunch of recursive calls for sure
db->tree
some more
ofc I’m just empirically saying that, I haven’t measured
so take my words with a grain of salt
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
Just stumbled upon this, thought I would share it here: https://github.com/acdlite/react-fiber-architecture
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/
Haven't seen any similar conversation in my om stumblings though.. Wondering if any prescribed solutions exist that i'm missing.