Fork me on GitHub
#untangled
<
2016-09-29
>
tony.kay00:09:44

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

tony.kay00:09:49

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"

ethangracer13:09:48

@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

ethangracer13:09:39

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

ethangracer13:09:54

confusing but it was just a component design issue

tony.kay15:09:19

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

gardnervickers16:09:38

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}}

tony.kay16:09:27

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

tony.kay16:09:53

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

gardnervickers16:09:11

Ok gotcha, thanks.

tony.kay16:09:08

So just for your own info:

tony.kay16:09:32

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

tony.kay16:09:44

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

tony.kay16:09:25

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

gardnervickers16:09:13

Hmm ok thats helpful

gardnervickers16:09:53

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?

jslavin17:09:32

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/

gardnervickers18:09:30

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

tony.kay19:09:59

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.

tony.kay19:09:15

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

tony.kay19:09:00

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

gardnervickers19:09:36

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

tony.kay19:09:38

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

tony.kay19:09:07

Well, you also removed the initialization of unions

tony.kay19:09:24

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

gardnervickers19:09:33

Yea, I’m supplying a normalized DB

tony.kay19:09:42

yeah, I see that now

tony.kay19:09:06

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

tony.kay19:09:33

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

gardnervickers19:09:59

Thats actually how I am generating the pre-normalized db

gardnervickers19:09:14

I just printed that and used it

tony.kay19:09:43

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.

tony.kay19:09:55

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

gardnervickers19:09:24

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?

tony.kay19:09:53

just don't implement the interface

tony.kay19:09:56

on the root

gardnervickers19:09:45

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?

gardnervickers19:09:58

Ahh that might be it

tony.kay19:09:59

the logic just tries to detect it on root

gardnervickers19:09:28

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

tony.kay19:09:37

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

gardnervickers19:09:45

and it’s value is being pulled into app state

tony.kay19:09:12

yeah...that mixed case isn't supported

tony.kay19:09:33

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

grzm19:09:43

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

gardnervickers19:09:29

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

tony.kay21:09:51

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

tony.kay21:09:23

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