Fork me on GitHub
#om
<
2017-02-10
>
ag01:02:10

is it possible in chrome dev tools (maybe with React Dev Tools) to see a query of a component?

sineer02:02:29

you can call the query static method on any component that implement om/IQuery protocol

sineer02:02:51

you could do this from repll inside DevTools using amazing Dirac repl 🙂

sineer02:02:02

hrmm, I thought you could but I just tried and it's not working for me... maybe I'm doing something wrong

sineer02:02:03

(def foo (new TimeLoop)) > foo ∅⊢IQuerymqueryλ[this]inom.nextjsfunction ()jsio$smitten$om$timeloop$TimeLooprefs: Objectstate: Objectupdater: Objectcontext: undefinedprops: undefined__proto__: ObjectTimeLoop > (.query foo) TypeError: io.smitten.om.timeloop.foo.query is not a function

baptiste-from-paris15:02:49

any feedbacks on using d3 or one visualization lib with om.next ?

matthavener19:02:12

baptiste-from-paris: d3 works fine

matthavener19:02:27

baptiste-from-paris: there’s a cljsjs/d3 so you dont need to stub it out either

baptiste-from-paris19:02:00

not a pain to write components with it and React/om ?

matthavener19:02:08

not really, just hook into the react lifecycle methods (componentDidXXX)

matthavener19:02:40

its kind “outside” the react model, but its really not much different than using react/d3 together

matthavener19:02:05

anything you read online for react/d3 will apply.. you’re just getting rendered by om.next driven updates

baptiste-from-paris19:02:13

have you tried other libs for data viz ?

therabidbanana22:02:42

Anybody seen issues with hot code reloading causing "No queries exist for component path (...)" errors?

therabidbanana22:02:55

I've got the indexer logging and I can plainly see the component path in the component-path->query map, and on initial render everything is fine, but when I reload code all of a sudden I start getting the No queries error in my console, even though the component-path->query map still shows it's there. My only guess was maybe somehow the code reloading causes weirdness with the component path matching?

therabidbanana22:02:12

But that doesn't really make sense because all my other queries work fine with code reloading.

adambros22:02:29

what do you mean all your other queries work fine? is just one component failing?

therabidbanana22:02:59

As far as I can tell, yeah, just this one component

adambros22:02:12

is a code snippet possible?

therabidbanana22:02:41

Actually, nevermind, it's multiple components - this one was just the most obvious

adambros22:02:59

to be captain obvious, are you using ^:once ?

therabidbanana23:02:30

Looks like we were not using ^:once in our defui wrapper, but that doesn't seem to help here.

anmonteiro23:02:47

I think I've seen that happen, perhaps when using dynamic queries (`set-query!` and co.)

therabidbanana23:02:37

Nah - we don't use set-query! anywhere. I think I put the ^:once in the wrong macro though. I'll try that again.

anmonteiro23:02:21

I don't know that ^:once will help your case

anmonteiro23:02:34

might be more worthwhile to defonce the reconciler and the state, etc

anmonteiro23:02:43

so that it doesn't get wiped on reloads

adambros23:02:06

seems strange though that its working elsewhere

therabidbanana23:02:49

I think it's not, it just seemed like it was because the other components weren't failing as noticeably

adambros23:02:07

are you using untangled?

adambros23:02:49

so i assume you’ve already got the new-untangled-client in a defonce

therabidbanana23:02:05

Yeah. I'm pretty sure this used to at least seem like it worked better - I feel like it started throwing this specific issue after upgrading our app to alpha47.

adambros23:02:33

sounds like you should start verifying that first

adambros23:02:05

maybe a good ol’ fashion git bisect