Clojurians Log v2

"a page that does a load-field" worries me

the only statement that is reasonably value around load* is "such and such mutation triggers a load", "startup callback triggers a load", or "such and such user event on the UI triggers a load"

@tony.kay fyi turns out that bug I saw yesterday wasn’t an untangled bug. om/db->tree was confused by a weird ident, like you initially suspected

the data wasn’t being wiped from the app-state, but when I looked up the location at one ident the data was gone because it had been placed at another ident

confusing but it was just a component design issue

cool. I figured. We'd have a lot more bug reports if you'd found a bug on that 🙂

Hey all! I think I found a bug with follow-on-reads from within a union query, but I was hoping to double-check that I’m doing things right before opening an issue. Here’s a devcard reproduction of the problem I’m seeing. https://gist.github.com/gardnervickers/a1fcbd04132271f9f18e9e6fecb15822 Essentially there’s two unions here, the first one has the Main and Settings tab. Inside the “Settings` tab are two child components, one is a union with two elements, ActiveUsersTab and HighScoreTab, the other child of Settings has two buttons that increment ActiveUsersTab and HighScoreTab. This all works as expected until you add follow-on-reads to the button mutations. It doesn't actually matter if the follow-on-reads even point to anything legitimate, or if the mutation actually mutates anything. If you switch the currently viewed inner union component via “show high score” or “show active users”, and then run any mutation that has a follow-on-read, you end up with #error {:message "No queries exist for component path (cards.union-follow-on-reads/Root cards.union-follow-on-reads/TabUnion cards.union-follow-on-reads/SettingsTab cards.union-follow-on-reads/SettingsChooser) or data path [[:settings :tab] :settings-chooser]", :data {:type :om.next/no-queries}}

@gardnervickers So, if this is a bug, it is a bug in your code or Om, not Untangled.

Make sure you're using the latest Om. The kind of error you're seeing is something that has reared up a few times

Ok gotcha, thanks.

So just for your own info:

follow on reads hit the Om indexer to find things. This is why you can use single keywords instead of queries/component paths

The indexer tries to return all of the components that use that keyword

those get thrown into a re-render list, and at the next render Om tries to optimize the re-renders by running component-local queries (based on the ident of the component) to refresh the state of the UI of those components

Hmm ok thats helpful

I noticed that components that are part of a union don’t have an ident, but one would think that they’d take the ident that their parent calculated for them. Is it alright to give them idents?

We discovered a problem in IE 11(Edge engine) or Edge browser with input fields when using Om/Next. The onChange event is not always firing on the input field when we specify a :value for the input field. Om/Next utilizes the requestAnimationFrame feature (or setTimeout) and that appears to be whats causing the issue with Edge. To work around this issue i switched to using the onInput event instead which is always fired. I have reported the problem to Microsoft under https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/9125100/

Switching out the Untangled client for vanilla om.next fixes my problem with the nested union follow-on-reads. I’m even using Untangled’s parser read function. I’ll keep looking, maybe it’s an issue with my code but it seems that the Untangled client is doing something I’m not aware of. https://gist.github.com/gardnervickers/a1fcbd04132271f9f18e9e6fecb15822/revisions

Hm. Not sure how you'd do that "switch out" without writing a parser. In that case, there could possibly be a bug in our implementation of read for that particular circumstance.

@gardnervickers I guess that can't be it, though, since you used our read

did you do lein deps :tree to see what your om next version was when using Untangled? Is it specified in your project?

Yea we excluded it from untangled and manually brought in the newest version.

I'm not sure what logic you've "excluded" by removing untangled (since you used Untangled's read code)

Well, you also removed the initialization of unions

since Untangled does that...so your InitialAppState isn't going to work right

Yea, I’m supplying a normalized DB

yeah, I see that now

so, that is a difference. It could be that our union initialization code is failing to make sure the right metadata is on the initialized data in app state...I'm not aware of anything that is needed there, though

when you dump the app state from the Untangled version is it different (when constructed from InitialAppState)?

Thats actually how I am generating the pre-normalized db

I just printed that and used it

weird

I'm concerned that maybe you needed to clean/rebuild, and you were possibly seeing a problem from the build system failing to update code properly.

It could be your "fix" was just that it recompiled properly?

If I wanted to disable getting initial-state from the components, is it sufficient to just not compose it back up to the root and supply my own normalized db atom for :initial-state?

yep

just don't implement the interface

on the root

If Root does not implement InitialAppState, sub component’s that do implement InitialAppState should not have their initial-state incorporated into the app state, correct?

correct

Ahh that might be it

the logic just tries to detect it on root

I’m seeing initial-state on one of my unions called even though Root does not implement InitialAppState

Although now that you say THAT, I wonder if our logic short-circuits the union inits properly in that mixed case...it wasn't one I would ever expect

and it’s value is being pulled into app state

yeah...that mixed case isn't supported

but that is a minor bug...we shouldn't try to do union integration if there is no root InitialAppState

@tony.kay You use git flow, right? Do you use the git flow scripts or just the pattern?

Disabling initial-state on all my components still results in that error. If it’s not the reads or the normalization process there’s gotta be something going on with the mutations. I’ll look there

@grzm we use the home brew git-flow-avh package (which installs the scripts)

@gardnervickers Thanks for tearing into that. No time on my end, but very willing to merge a PR if it is an Untangled problem