@tony.kay Ah ok, thanks! I'll posy a pull request sometime today. Except, regarding InitialAppState, I didn't use it because the devguide hasn't yet covered it at that chapter.

@tony.kay Don't know if the suggestion is any good. But thought I should share https://github.com/awkay/untangled/issues/15

@claudiu you should be able to make your own :config component that will override the default... I think, have you tried that?

@adambros For now I'm pretty happy with config-path, think it's a nice feature to have out of the box, in the future as my project grows will probably want my code to do the reading and just send the config to untangled. Just thought it would be nice to be as straightforward as possible.

I am running into a very weird issue.. And I am really breaking my head around this one. If i trigger a certain load a component will get the root-query result all of a sudden

No really sure how to explain this one

So it goes from loading state to the root query result.. while I am running a very simple load it is basically:

(df/load (:reconciler @app) [:sale.issue/by-id 17592186046693] atlas-crm.sales.components.issues/LinkedIssue)

@mitchelkuijpers . Might be wrong. But think in remembering from om-next that loading with reconciler is not really that recommended. And it will trigger a full app refresh.

That still does not explain why I get the root app-state 8 components deep when I am not asking for it

This is a example that I am running to reproduce the bug normally I use the component instance. But I think that a component without a query basically does the same as just using the reconciler. It only triggers a full app refresh when you don't add read keys after a mutation

sounds like a interesting issue. Have you tried running the query from inside of a component using this ?

Not that interested anymore trying to get something done this has cost me about 6 hours already 😞

But good idea @claudiu will try that out

I nested something with a query in some components without queries and that seems to break it

Without this it seems to work

So I at least know the fix now don't nest components with query in intermediate components, which might explain why I get the root query after a certain operaion

ahh yep 🙂 think they have to compose all the way down.

It does compose but we render it with some intermedia components, not sure if that makes sense

So we have a query of {:issues [(om/get-query IssueItem)]} on component Tab and we render it by Tab->Table->IssueItem where Table is a component without a query. This works fine untill you try to do a load on a single IssueItem component

I'll try to make a reproduction of this

But now first try to fix my application

ok interesting gotcha , thanks for sharing 🙂

Yeah maybe this helps someone else who runs into this case 🙂

Not sure if I have to report this as a bug in Om or Untangled

agh found it 🙂

https://awkay.github.io/om-tutorial/#!/om_tutorial.E_UI_Queries_and_State -> there's a section "Failing to Reach the UI Root"

@claudiu Oh thank you will read that

I have to run will report back

@mitchelkuijpers so, I'm on the road at the moment, but that does seem very odd. As long as things compose to root An intermediate stateless should not hurt. Remember that the db is not deep. It is flat. All tables are at the root. But it is very strange. It's almost as if you're destructuring of props is wrong and you're passing things through render wrong.

Did you examine app state. That would isolate it to load. Also, what version? Path-opt on?

I can't see how load could screw up in that manner, but a bad query or more likely props passing. Could also be a problem with the new read local in beta2 snapshot, if you're using that, but I'm not sure how

The app-state seems correct and re-render from root after it went wrong fixes it

You are correct I have the same problem without the intermediate components

@tony.kay Sorry, I'm still not quite getting it 😕 I mean it's almost right, but something's not quite clear: