This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-29
Channels
- # beginners (42)
- # boot (12)
- # cider (3)
- # cljs-dev (277)
- # cljsrn (44)
- # clojure (127)
- # clojure-austin (9)
- # clojure-austria (1)
- # clojure-brasil (14)
- # clojure-canada (1)
- # clojure-dev (22)
- # clojure-dusseldorf (1)
- # clojure-italy (4)
- # clojure-russia (24)
- # clojure-spec (33)
- # clojure-taiwan (1)
- # clojure-uk (21)
- # clojure-ukraine (8)
- # clojurescript (134)
- # core-async (41)
- # core-logic (8)
- # cursive (1)
- # datomic (3)
- # ethereum (1)
- # events (4)
- # funcool (1)
- # leiningen (12)
- # off-topic (21)
- # om (19)
- # onyx (45)
- # overtone (1)
- # parinfer (2)
- # pedestal (3)
- # proton (2)
- # re-frame (103)
- # reagent (48)
- # test-check (27)
- # untangled (51)
- # vim (3)
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
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.
follow on reads hit the Om indexer to find things. This is why you can use single keywords instead of queries/component paths
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)
Yea, I’m supplying a normalized DB
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
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.
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
?
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?
Ahh that might be it
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
but that is a minor bug...we shouldn't try to do union integration if there is no root InitialAppState
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
@gardnervickers Thanks for tearing into that. No time on my end, but very willing to merge a PR if it is an Untangled problem