Clojurians
#om
<
2016-10-09
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

molstt19:10:50

It seems like the support for [:foo _] refs is limited when it comes to automatic re-rendering. Maybe someone could confirm this? I currently can't get my components re-render without switching to supplying plain keys instead (which currently doesn't fit my very flat data model)..

anmonteiro20:10:38

@molstt not sure I understand. you want to add :foo to transact!, not [:foo _]

molstt20:10:31

@anmonteiro I wanted to use [:foo _] everywhere, both in component queries and when transacting (if needed to trigger re-render), because I currently have a simplistic model with just a few singletons right under the state root. But if I do that I get no re-renders when data is transacted to these singletons.

anmonteiro20:10:04

@molstt that’s right, because IIRC transact! won’t recognize links

anmonteiro20:10:35

this is for a reason: a [:foo _] link refers to a :foo key at the top-level

anmonteiro20:10:09

so the root component might declare :foo in its query, while another down the tree will query for [:foo _]

molstt20:10:49

does that mean that components querying via links should re-render automatically when these singletons get new values? Otherwise I don't see how links can work at all..

molstt20:10:40

I suppose that when I query for :foo in a transaction, 'this' will be used so that the key is considered component-relative

anmonteiro20:10:08

@molstt yeah the indexer knows which components query for those links

anmonteiro20:10:24

so if :foo changes, every component that queries for [:foo _] will be scheduled to re-render

molstt20:10:31

ok, so it should work, that was what I was expecting.. then I probably have some problem in my code

molstt20:10:57

thanks for info

anmonteiro20:10:31

@molstt happy to look at a minimal repro in case you can’t figure it out

anmonteiro20:10:47

first probably make sure that you’re composing queries correctly

molstt20:10:40

yup, thanks

alex-glv21:10:29

I have been working my way through how om.next works and implementing routing similar to compassus, however I am struggling with what happens after I change the route. Basically, I use first approach in this post -> https://anmonteiro.com/2016/02/routing-in-om-next-a-catalog-of-approaches/ , where my Root component contains queries for all routes. Initial dispatch works well, my :remote is requested and response displayed. However, after change-route! remote is not requested anymore. I assume it’s because change-route! didn’t actually touch buried keys inside. How would I force reconciler to execute query of the chosen corresponding route?

alex-glv21:10:42

I assumed just returning {:remote true} from read would be enough to force data fetching (without :value). Is it correct?

tony.kay22:10:03

If anyone is interested, Ethan and I beefed up the documented story of how Untangled implements Om Next networking and avoids having you write a parser. Even if you don’t want to use Untangled, this covers some of the core realizations and decisions we think make using Om Next much easier. It also gives you a good idea of what the trade-offs are: http://untangled-web.github.io/untangled/tutorial.html#!/untangled_tutorial.H_Server_Interactions