This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-30
Channels
- # arachne (1)
- # beginners (1)
- # boot (13)
- # cljs-dev (35)
- # cljsjs (12)
- # cljsrn (11)
- # clojure (77)
- # clojure-austin (14)
- # clojure-brasil (3)
- # clojure-france (1)
- # clojure-poland (4)
- # clojure-russia (23)
- # clojure-spec (39)
- # clojure-uk (14)
- # clojurescript (17)
- # cursive (16)
- # datascript (10)
- # devcards (1)
- # dirac (3)
- # editors (1)
- # emacs (4)
- # jobs (1)
- # jobs-rus (2)
- # luminus (5)
- # off-topic (1)
- # om (85)
- # parinfer (1)
- # perun (12)
- # re-frame (20)
- # reagent (4)
- # spacemacs (1)
- # specter (9)
- # yada (6)
I think I'm missing something conceptual here: The initial query composes to the root, but that composition doesn't take query changes into effect. If a subcomponent changes its query, the root query becomes incorrect. I understand that Om still feeds that subcomponent params by reading its new query, but it does mean that the root is still reading data it doesn't need to read anymore. Is that not a problem?
@peeja: it only works for “single children"
you can’t expect to change the query of a single component in a list
@peeja: if you’re seeing that’s not the case, I’d love to see a minimal case
granted you’re on a Om version that supports that behavior
the list case just isn’t supported because it doesn’t make sense
for a single component to have a query different that its siblings
just use a union query for that
¯\(ツ)/¯
It doesn't make sense because of the query syntax, but it totally makes sense as a use case, no?
@peeja: this would be the commit: https://github.com/omcljs/om/commit/8b5ba6df5e32bae90ebbd58f45dbadcbc34d6685
minimum version is alpha33
for that to work
@peeja: doesn’t make sense because of the query syntax, and one more thing
how could you have an updated view from the root in that case? which of the children’s queries would you choose to compose?
at least one of the children would always be reported wrongly
I just mean that it's a reasonable thing to want to do, even if it doesn't fit the query model
@peeja: I’m happy to answer your questions relating to this, I’ve done the work to support that and it was not trivial at all to reach an understanding (even in my head 🙂 )
Is it possible to "convert" one of the items into a different branch of a union on the fly?
Like, you click "show more details" and it starts being served by the "more details" branch
something like that, yeah
imagine you have posts and photos
suddenly a photo becomes a post (that shows a photo)
just change the field that the union query dispatches on
no need to mess with queries, just with your data
But I guess I'm just pushing further into a case that the query syntax has no way to represent
@peeja: hrm, would it really be that complicated? a transaction that changes the type, and marks that ident as “dirty"
the remote transaction (which is guaranteed to run after the local) would just need to check for dirty stuff and send them to the server?
@peeja: I don’t mean changing the server’s state at all
just remote re-reading that piece of data which is now stale on your frontend
I feel like the whole point is that a transaction shouldn't be necessary. I'd like to be able to change my query and therefore be fed the data I asked for
I think we’re talking about the same thing, with different implementations
I mean, even in this case, the root query isn't fetching data I don't need, it's just not fetching all the data I need.
To put this another way: if the root query contains a join query for a collection, but the component rendering one of the items in that collection has changed its query, is that a problem?
It means the root query will ask for data I may not need, and may not ask for all the data I need. But the list item component will also be reading its own query.
@peeja: depends. the new query won’t be viewed from the top
that’s the only problem
the parser will still dispatch on the updated query when you set-query!
If I then set-query!
on the root component to change something unrelated to the list, causing it to re-read and re-render, will it cause my list item to have incomplete data, because it's rendering only the data that the root query knows to ask for?
@peeja: when you re-render from the top, that component will not have the updated query visible
Meaning that when that component asks for stuff out of its params that only its updated query knows about, it'll find nil
?
I’m not sure if that’s what it means
Could you help me with my problem?
I'm clueless about the reasons for that behavior
@marcin.cylke: Does people
return a vector of multiple people sucessfully?
hmm.. didn't think of that
I'll check this - I've always search for the problem with om