@yaw what seems to be the problem?

@levitanong I kept getting nil whenever I ran (om/get-query (om/class->any reconciler AnimalsList)) in the repl. It turns out it was because I set up my project using the figwheel template from lein. I'm good now. Thanks!

I keep getting "transact! should be called on a componentthat implements IQuery “ on a component that does implement IQuery. Is this a known issue?

I don’t recall seeing this in the past

@solussd static om/IQuery ?

@danielstockton yup, it’s there. Simplest component you could imagine

Not come across it before, are you sure the component is what you think it is?

implements? and om/iquery? both say it does not implement om/IQuery

try logging this inside the click handler perhaps, it looks ok to me

it appears to be an instance of my component. 😕

I’m concerned by (implements? om/IQuery RootView) returning false

or, #‘RootView

@danielstockton whoa, appears to be a regression caused by a recent version of clojurescript. I just downgraded a few versions and now it works.

<binary search underway>

CLJS-1658: testing for protocol membership may return false positives

issue caused by latest clojurescript release (1.9.293)

@yaw ^ is your problem from yesterday, too.

Interesting. I saw the same "transact!" message in my console as @solussd did but it completed the transaction.

it does bc it just grabs the reconciler, in that case

but– it isn’t able to resolve the query for the component (which is the problem you were having)

nod

not sure if this is an om bug (given how defui* implements the protocols) or a clojurescript bug, but regardless: https://github.com/omcljs/om/issues/839

I'm confused. Any input with a value should be a controlled component, right?

(dom/input #js {:type "text"
                :value "foo"
                :onChange (constantly nil)})

^ This input lets me type text in the box

(dom/input #js {:type "text"
                :value "foo"})

^ This one doesn't. The contents remain "foo" no matter what I type.

I'd expect the first one to act like the second. The presence of an :onChange shouldn't make the input uncontrolled, should it?

I expect this behaviour actually. Its just immutable value "text". Recomment to use some local-state changes for every typed letter, this is mostly annoying when using fillers with input maskers. But with patience it can be done.

@hlolli I'm not following. The :value is always "foo". The text box should always read "foo" no matter what I type, no?

yes oops foo, I would expect that.

ok I see your point now, that when you apply onchange function then the text-field becomes mutable. Sounds strange.

Yeah, this is definitely some kind of bug. I now have two identical devcards:

(defcard test-2
  (dom/input #js {:type "text"
                  :value "foo"
                  :on-change (constantly nil)}))

(defcard test-2
  (dom/input #js {:type "text"
                  :value "foo"
                  :onChange (constantly nil)}))

The first one works correctly; the second one lets me type additional characters.

well... obviously :on-change in the json map wont do anything. But this could be a javascript/react caveat http://stackoverflow.com/a/34006506

Oh, yeah, they're not identical, I fat-fingered the first one.

Ah, okay. I think this is more of a devcards issue. If I wrap the dom/input call in a function, it works as expected, I assume because there's now a component that's re-rendering the input (with the constant :value).

@solussd: does downgrading the version of CLJS fix the protocol issue. then?

om 1.0.0-alpha46 and older depend on clojurescript compiler details around defining protocol adherence in object metadata

tl;dr, use omcljs 1.0.0-alpha47 or newer with the latest clojurescript

@tmorten ^, and yes, to answer your question. 🙂

Cool