should I be able to render "top-level" queries in nested components? For example, I have a LoadingIndicator component 3 levels deep that I want to respond to :ui/loading-data. I get/respond to it just fine in the Root component, and it looks like I have :ui/loading-data in the queries at all 3 levels, but it's not finding it at all in the 2nd and 3rd-level components.

any hints for debugging?

@curtosis: I haven't had a chance to use them yet. But if they are all at the top level of your app state (no idents involved) then you should be able to access them as 'links'. The advantage of links is that they can be accessed from any component, no matter how deeply nested it is.

Here's a short article: https://github.com/omcljs/om/wiki/Thinking-With-Links!

thanks! I'll take a look. clearly I've got something muddled, so hopefully getting a dose of theory will help.

well, I thought that made things clearer but now none of my queries work.

or at least, I can make the top-level query in Root work, but none of the nested ones.

Here's a gist, if anyone is willing to take a look: https://gist.github.com/curtosis/3148230f9317455652c29f130db30b5a

hello, I might have found a bug on Untangled, I'm trying to do a remote query that has an union query, and it's failing when trying to normalize

after some inspection I think that some of the query metadata is being lost at some point

the error I'm getting is Uncaught Error: Union components must implement Ident

this is my query

[{:route/data
  [{[:lesson/by-slug "meet-the-metronome"]
    {:lesson.type/video [:lesson/type :lesson/description :youtube/id],
     :lesson.type/playlist [:lesson/type :lesson/description],
     :lesson.type/exercise [:lesson/type :lesson/title]}}]}]

query result:

{:route/data
 {[:lesson/by-slug "meet-the-metronome"]
  {:db/table :lesson,
   :db/id 100,
   :lesson/type :lesson.type/video,
   :lesson/description
   "You've probably seen a metronome before.  There are old ones with a pendulum that swings from side to side and new digital ones that beep.  But all of these devices are designed to help you establish a regular and steady beat.  \r\n\r\nSometimes musicians find it useful to practice their playing along with a metronome to make sure that they aren't rushing ahead or lagging behind the beat.  \r\n\r\nAfter lots of practice musicians tend to develop their own internal sense of time and beat which keeps their playing in time. ",
   :youtube/id "ZYLKuoCeBK0"}}}

I put some logs in Om, when it tries to normalize, the component meta is not present in the query data, that's what makes me think the data is being lost on the way

and just confirming, my parent element has an ident for the union

Also this syntax is strange: ~@(om/get-query TopBar)

@cjmurphy: still doesn't trigger. I'm also concerned that the :ui/app-version query in TopBar also doesn't work.

(which is just one level down)

don't I want to include the query for the child component?

You want to join to other components, not bring the keys in which you seem to want to do.

hmmm. okay... definitely misunderstood something then.

so when I do this for TopBar it still doesn't trigger for :ui/app-version: (query [this] ['[:ui/app-version _] {:indicator (om/get-query LoadingIndicator)}])

and this on Root throws an invalid join error: (query [this] `[:ui/react-key :ui/loading-data :ui/app-version {:top-bar (om/get-query TopBar)}])`

For the first thing, is :ui/app-version in your app state when you check it in the Figwheel REPL?

This one here: [{:keys [:ui/loading-data]} (om/props this)]

argh....

well, I fixed that one at least. didn't change the problem, but still. 😛

my app-state from figwheel: {:ui/react-key "ROOT", :ui/app-version "2016.04", :ui/locale "en-US", :ui/loading-data true}

(I'm manually setting loading-data for testing)

From what I can tell you ought to be able to see :ui/app-version

, from inside your component

right now my TopBar query is (query [this] ['[:ui/app-version _] {:indicator (om/get-query LoadingIndicator)}])

what should my Root query be to pull that in correctly?

Root query just a series of joins. No need to do the links I don't think.

So the :indicator join ought to feature in the root query, just as you have it there.

I have (query [this] [:ui/react-key :ui/loading-data :ui/app-version ~@(om/get-query TopBar)])` for Root.

Take out :ui/loading-data from the root query, or make it a link.

I honestly don't know if links need to be in the root query. I have them in in my code, but as links.

well, I'm using :ui/loading-data in the root query as well. (that one works, unless I write it as a link.)

but that's probably because my escape quoting is a little wonky and it ends up as [:ui/loading-data client.ui/_]

yeah, doesn't work at all as a link in Root.

(top-bar) - it is not being given any props. You need to have the join keyword and be feeding that to top-bar.

You definitely don't want ~@ - you should have join keywords.

I realize I'm being quite general rather than specific 😜

d'oh. okay, I think it's making sense slowly. I got in a weird rabbit hole thinking the queries did the magic... which they kind of do, but still need to pass the info down into the components in render, right?

Yes - joins often indicate going to a different component.

Really you are passing down another list of hashmaps. You could just debug what is coming into root (pprint props), to see what is coming in.

well, I fixed all those joins and component calls. still no :ui/app-version or loading data.

Can you do another gist that has all the fixes?

The :ui/app-version is a separate problem. You could do a gist with just that in it.

and now app-version is mysteriously working... ok. gist coming up.

https://gist.github.com/curtosis/395a2406ed07c81304aeefcb77eaf333

Is loading-data always false? Is that a problem or is that expected?

it's not always false, no.

Its usually set by Untangled right? And I can't see that you are setting it anywhere.

right. I'm setting it manually for testing.

(swap! (om/app-state (:reconciler @client.core/app)) assoc :ui/loading-data true)

What's a specific problem we can look at?

so... (om/get-query Root) looks right... [:ui/react-key :ui/loading-data :ui/app-version {:topbar [[:ui/app-version _] {:indicator [[:ui/loading-data _]]}]}]

but props inside TopBar has :ui/app-version but not :ui/loading-data

I would want to see a ' before every link.

I don't know why so perhaps it doesn't matter.

they're there in the query methods; I think they're just getting dropped by the pretty-print

(if they aren't quoted, the _ gets namespaced)

Your root query looks okay then. Oh yes thanks.

revised: the props in Root don't have the subsubprops: {:ui/react-key "foo" :ui/loading-data true, :topbar {:ui/app-version "2016.04"}} (no {:topbar {:indicator ...}})

That's to be expected I believe/think.

I suppose, but then how does :indicator ever get its props?

When you go to the next components it brings out more data. I'm not 100% sure about this. But I don't think it is a problem that you don't get to see the data all the way to the bottom./

hm, ok. so focusing then on the fact that TopBar doesn't have :indicator either.

Not sure - but it would be a problem if you were not seeing the prop data in the lower level component where you need to see it.

right. which is, in fact, the current problem. 😕

LoadingIndicator does seem like a pointless component. All it has in it is a link. Seems odd to be joining to a component that does not have leaf keys.

the idea was that it's a reusable block that I can put anywhere, and it just trips state depending on :ui/loading-data

(leaf keys and or joins as well)

so in the data tree it's (conceptually) at the top level, but in the component tree it could be anywhere, even multiple places

It doesn't need to be passed prop data, or be joined to. It doesn't have to be in a tree.

Maybe you could just pass it {} as props.

hm.. then where does it get :ui/loading-data from?

Also you can't join to components that don't have idents.

that seems more likely to be causing the problem.

what should the ident be of a component that doesn't have its own data?

Yes 😛

(TopBar doesn't have an ident either, but that seems to be working so far)

But it only has links in it.

There's conflation of a lot of ideas here.

The whole thing is links, so no need for joins or idents.

but... without joins it doesn't work either?

joins got :app-version working

So my yes now a no.

in the root?

in TopBar.

(I call it out separately in Root, and it works there as well)

If you call (topbar {}) does that work?

nope

If get rid of join to LoadingIdicator as well?

also nope

You shouldn't need joins for links to work. That's the purpose of them really.

that's what I thought as well.

I'm fairly confused at this point.

I'm not sure about links being in initial state either.

Initial state is for that component. Whereas links are not tied to any component.

right

@wilkerlucio: Did you figure out your problem?

@tony.kay: yes, I found a bug into Om ast->query, it doesn't add the component meta back on unions, I'm going to issue a PR with a fix

great!

I'm only using initial-state to stuff :ui/react-key and :ui/app-version into app-state for me.

(initial-state on Root)

Fair enough - if you can see app state as it should be then I guess there's no issue there.

but I agree... links don't seem like they should need props passed down. sort of the point.

@curtosis: I'm jumping in without reading everything...but links are not magic...they don't put things in props in arbitrary places

The initial query in Om always runs from the Root component as a single query

so things have to join together, and you have to pick the bits apart and pass them through

I've seen cases where if you have no app state path to a component, then you won't get the state of a component (having only a link query) because db->tree will stop looking deeper when it runs out of state

This is an Om-ism. Not certain if it should be considered a bug. There is an easy workaround: make sure the path to the component exists in the graph of the db

even if the map itself for the component state is empty

I see (I think). Via each component having an Ident?

(if it helps, the gist we're talking to is here: https://gist.github.com/curtosis/395a2406ed07c81304aeefcb77eaf333)

ok...just a sec....ident it an orthogonal thing to what I'm saying

well, not exactly ortho

np

but not identical 🙂

hehe

Yeah, in Root, you've composed in top bar, but it has no initial state. Give it initial state that composes in state from TopBar, which in turn should have initial state that has :indicator, which in turn composes in an empty map

the jumping-off point is more or less how to make a component that only depends on top-level (link) query data.

ok, I'll give that a go...

right, at the moment, the way queries work, it has to compose to root and have matching state, even if the real data you want to access comes from root via a link

the db->tree algorithm stops running the query if it cannot follow a join in the graph db

so it never reaches your component with the link

This is probably a bug in Om, but the workaround is trivial

You could also make TopBar and LoadingIndicator stateless (no queries) and pass the data down to them.

That is why I'm not sure it should be considered a "bug" per se. They don't really have data of "their own"...but then the query makes logical sense. Something to discuss on Om channel

good point

LoadingIndicator at least is probably legitimately stateless

I've been bitten by the same thing, of course. which is why the sol'n was "obvious" to me 😉

naturally. 😉

Haven't finished arguing the pros/cons with myself. So I'm not pushing the point.

fair enough.

so far not working, but I'm not sure I have initial-state wired correctly yet...

you still have to pick apart the state and pass it through in the body of the render

and in fact I did not. 🙂

oh, I guess you were

oh

maybe I missed it

(TopBar was setting {:topbar ...} in its initial-state, so I got {:topbar {:topbar {:indicator ...}}}

and now I have spin!

sweet

thanks @cjmurphy and @tony.kay for the extended help! very hard to sort through.

I should make a tutorial video on links and mention this particular problem

almost everyone is going to hit it

is there an example in the tutorial code for the stateless version?

The video tutorials are a real help by the way.

don't remember 😄

just drop the queries (move them to the root) and pass the data by hand

I second that - the video tutorials are fantastic. And I hate the video-ification of documentation.

that's how helpful they are. 😉

@curtosis: wow, I'm flattered. (I'm not much of a video fan myself, but I know others like them...so I'm doing my best to make them useful)

My opinion is the trick is to keep them simple, clear, and short

I'm shooting for 10-20 mins each

yeah. one concept = one video helps a lot to maintain mental models of locality.

And the working out where things went wrong is good too. Things like I never would have thought to inspect what's going across the wire using dev console. Can only get that sort of thing from videos.

Right...making mistakes on video. I don't edit those out for exactly that reason

though I did have to pause one cause I got stuck for like 10 mins 😜

(the union one)

yes. that is especially helpful.

confused the crap out of myself with the rename

@cjmurphy: now if we just had a "transit viewer" for chrome

hehe

the de-duping in transit makes that stuff kinda hard to read

just tried making LoadingIndicator stateless, fwiw. Works fine (I put '[:ui/loading-data _] in TopBar's query, then just passed its value in a straight map. LoadingIndicator now has no initial state or query of its own.)

pro: LoadingIndicator is simpler; parent doesn't need to compose in initial-state and query. con: its parent needs to know that it needs :ui/loading-data, rather than just composing in the query and initial-state.

Sounds good - not a part of Om Next at all.

all of which is pretty obvious, but still worth calling out explicitly. there's a reason the composability of component queries is helpful. 😛

the deeper reason for trying to sort all this out, of course, is that NavBar (which I've elided here) needs to drive the "tab" switching and reflect the switched-in tab state, so it's all related.

does untangled eschew component-local state? thinking here of things like click-to-expand submenus.

Its eschewed I guess but makes sense sometimes - like a transact for every single keypress seems to much to me. You can do it if you want to of course.

if you really need to do per-keypress undo, for example

not sure it makes sense to replay/undo expand/collapse actions 😛

but in some contexts, maybe.

(now I have to go back to the om docs and try to remember how to do local state... 😉 )

I only do component local state for form entry of text field...and then not always then. Support viewer is much more usable if you can see the user navigating the app

I've toyed with making it possible to elide transactions from history with some kind of metadata marker.

some kind of marker like ":unimportant" and then any adjacent unimportant history entry simply overwrites it. Automatically compressing adjacent unimportant entries down to one. That way you could do everything the same way, and choose what to elide from recorded history

I also want to start hanging network results (and errors) onto history entries so they can be shown in support viewer

lots to do still 😉

Also need to compress (with something like data differ) the history so that support requests with history are reasonable on bandwidth.

heh... that makes sense. I may switch them to full transactions later.

I've just pushed an update to the Untangled tutorial: Section F-Untangled-Initial-App-State covers the new initial app state, including union support.

online version:

http://untangled-web.github.io/untangled/tutorial.html#!/untangled_tutorial.F_Untangled_Initial_App_State

Online version has a couple of fixes, too. 3 SVG files were missing in the old version

BTW: online tutorial is using advanced optimizations on closure with Om and D3. Does a nice job of making a relatively small SPA: 1.4MB

nice!

Yeah, and that includes 200k of raw text content that cannot be "compressed" through renaming or elision

any tips for debugging tab switching? I'm seeing the new value show up in app-state under :tabs but the Switcher itself isn't re-rendering the new panel

Only tip I have is to A-B compare with the getting-started video code (tabs-union tag)

sigh. I was afraid of that. 😉

can't see a diff in the relevant code.

make sure you didn't make the same mistake as I did: naming idents using keywords that are also top-level keys

should both tabs show up in :om.next/tables ?

e.g. :tabs as your top-level state key, but also as an ident key...causes the table to overwrite the state

I think the om.next/tables thing is an unused vestige

ignore it

ok

The good news is the pattern is well established in code. It is a little tricky to understand at first, but the only real mistakes you can easily make have to do with naming things. Make sure your ident uses the keyword first (and that the keyword in the ident matches the table name of the table holding the thing you're trying to point to)...that keyword is also what you switch the UI on

other than that, accidental name collisions can bite you

so far doesn't look like a name collision... if I put in some dom/buttons at the Root level to transact the tab switch, it works fine. so it must be something in how I'm calling the transact from the nav menu? maybe?

it almost looks like calling transact! from anywhere outside root isn't triggering Switcher to re-render.

(gist here: https://gist.github.com/curtosis/dabc9f7634909d577ffc763ecbba2f32)

the only thing I can think of is maybe something in the way I'm setting initial-state to include my work from earlier today.

Ah, have you not read/watched stuff on UI refresh?

somehow react/om isn't getting the wiring

I have ... but apparently I'm missing something? 😉

UI refresh is not completely automatic

it's been a bit of a firehose this weekend 🙂

If you're trying to get a sibling to refresh on a transact, you'll have to use follow-on reads. If you want a parent to refresh,you should use transact in the parent, and pass a callback of that into the child for triggering

Om automatically refreshes the subtree of the transact

aaah.... that's vaguely ringing a bell

other components require follow-on reads

(transact takes this, after all)

right...and that is what is guaranteed to refresh

everything else is an index lookup of keywords in the follow-on reads

dangit. it's so close to magic I expect it to magically work. 😉

so it can be abstract on the data

this seems to be the one video I didn't watch

aaand solved. thanks!

there is much value in "oh, I recognize that problem." and again, very much additional value in ".. and here's a video addressing specifically what causes that problem."

the one sort of unintuitive bit is that I have it do a follow-on read of :tabs, which is what the thunk changes... but Switcher doesn't query for :tabs

Switcher isn't a real UI component

it is an artifact needed for union to work

what makes it "not real" - the union query?

just a proxy decision maker...it uses the queries of the children, and the renderers of the children

to-one unions like this are a bit of an oddity

but a very useful oddity

I suppose :tabs works to trigger the refresh because in root it gets the Switcher's query, which in turns gets the tabs' queries, which themselves get :type, which is what Switcher renders based on. Do I have that chain reasonably correct?

It isn't quite that complicated. When you say :tabs as a follow-on read: Om looks up every component that mentions :tabs in a query, and re-renders them all.

Those components explicitly try to re-render their children

ah, so it's re-rendering Root &children.

Om short-circuits the rendering of any whose data has not changed

yep

When your UI goes on the screen, Om indexes every on-screen component by the keywords in its query

and it keeps that index up-to-date on refreshes

"follow-on reads" are just index lookups

the nice thing is you don't have to care which components need refresh...you just need to name the bits of the graph that are affected

in this case, conceptually, the :tabs bit of the graph now points elsewhere

gotcha

We all want to know "how it works", so it is nice to know the index bits and such...but the real power is that it frees you from having to think about the UI structure. Everything you do (mutation and refresh) is based on reasoning in the graph

right. In this case, we're changing :tabs so we probably do want to re-render all the children; it wouldn't make sense necessarily to just flag :type as having changed (or so it seems to me)

right, type is something you needed to query, but it isn't the part of the graph that changed

makes sense. (tentatively. 😉 )

The before and after of the graph is that the ident under :tabs changed

re my comment/question about "what makes Switcher 'not real'" => I realized it was a question for me b/c my Switcher is a real component; it renders some html divs around the tab. There's no magic that makes a Switcher "not real" other than not doing its own rendering/queries.

there's some tricky stuff to wrap your head around initially, but I think I'm finally getting to the point where I'm seeing the clarity of reasoning it enables.

=> broad thanks for the superb framework and outstanding documentation videos.

So if I wanted to use xhr requests for most of my remote mutations and reads but also supplement them with some server side pushes using sente, any recommendations?

It looks like the untantled-websockets library makes me pick xhr XOR websockets?

the websockets library handles both remote mutation, reads, and push when you use it. Since it reduces the total number of connections needed, I'd use it. @mahinshaw wrote that library, so perhaps he can comment.

As far as I rmember, it does take over the network plumbing on the client

The server will respond to either (since both pipelines are still installed).

But if you already have a websocket, why open additonal XHR connections?

untangled websockets uses websockets only

@mahinshaw: reading your code now, looks really nice!

there are no xhr requests. You could put that on a side band, but there is no need. Mutations and reads, as well as push all go through the same plumbinbg

Thanks!

i figured we might want to reads to go through xhr so we can still leverage http caching, at the browser level

yeah, there is no http caching story there

the nice thing is the websockets are another endpoint, so you can still hit the api endpoint that you are used to

To get that going in the same app, I think you'd have to have multiple remote support, which is not there yet. Unless you're using XHR directly

the problem though is reads and mutates will still go through the websocket by default since we override the networking, but you can do ajax

is that right Mark?

right

your right tony

what if i write my own networking component that wraps both the websockets one and the regular /api one? then my component just decides who to pass the request off to?

is that feasible?

So, it would not be a ton of work to support multiple remotes, and have each use it's own networking stack. That would give you both. Mutations would then say :my-remote true instead of just :remote true....each remote would have it's own key

This is a standard feature of Om, which we don't currently hook into

the networking queue would have to be fixed up to not be a singleton

I think we would need to patch the network layer (on the client) for that

yes

It could be done in the websockets layer. Which may be a good place to experiment

Nah, be much better as true multiple remote support

which we need (or want) anyhow

so the client network could just be a map of network components then

browser limitations on connections could get a little dicey if you, say, wanted multiple websocket remotes...but whatever

@mahinshaw: Yes.

I really don’t think that would be too hard

no, it really isn't

like I was saying...the main issue is the network queue...it is currently a singleton

so each network component would need it's own queue

that’s fine. they do at the moment anyways

?

you mean we already changed each to have a private queue?

I don't remember doing that

yeah, each queue is part of the network component in the client

oh...did I do that, or you?

it’s always been that way

I don’t use any of the networking code (for the most part) in untangled client.

oh, so I must have already fixed that

actually, I need to revisit that, one sec

right, the queue lives in the implementation of UntangledNetwork/send, and websockets has a different implementation

so in that case it probably is pretty simple. Just a matter of some wiring

I was wrong, it’s one queue that pushes to send

so there is more work

ok, that was my memory

server-send in application.cljs

but that shouldn’t be too bad, since we are using core async. we just need a router.

cool

but if I'm only going to use websockets for pushes, do you think it's a bad idea to avoid a networking component altogether, just have a separate component that opens a websockets, listens for pushes (mutation literals from the server), and transacts them into the untantled-app

does that sound like an unwise thing to do?

It is only unwise in that browses limit the total number of connections (browser-wide) to a domain

so, if you expect ppl to open more than one tab you're possibly asking for trouble sooner

but that is no different than having multiple remotes with one being a websocket

i see, thanks. well two connections seems acceptable IMO. it would be nice to get a google docs like functionality in our app

since most of the things in our app are dashboards shared between users

does the om.next logger get a little confused by tab switching?

Don't see how it could

I keep seeing this in my logs:

[1574.490s] [om.next] transacted '[(app/choose-tab {:tab :settings-tab}) {:tabs {:dashboard-tab [:id :type :extra], :settings-tab [:id :type :args]}}], #uuid "e80e791a-fa49-4aa9-aeb3-15ac20a653d3"

the {:tabs {:dashboard-tab ...} is always the same.

the follow-on read gets turned into a query

that is normal

you say :tabs, Om looks up the component in the index, gets it's query, and adds that to the transaction as the actual read to run

oh, duh. I was just seeing that :dashboard-tab was always there and didn't notice that it was the full query. operator error .... a good sign I've been at the keyboard too long today. 😛

any suggestions for what composes with untangled-server to get user authorization, and limit what mutations are allowed

am looking at cemerick/friend

There is a bit on what we do in the Untangled cookbook

k

but that is more for queries

mutations...not much out of the ordinary there. Up to you to figure it out.

yah well i'm not sure how well cemerick/friend composes with http-kit

i guess it's more an http-kit question

FYI, those using old-style app state (not new app state). There was a bug in new code that breaks code with unions that are NOT using the new app state mechanism. Fixed in 0.5.4-SNAPSHOT, which I just pushed

@jasonjckn: yeah, sorry, can't answer that

Any ring thing can be plugged into pre or post hook area of U.S.