# om

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

levitanong 05:13:55

@yaw what seems to be the problem?

yaw 16:48:21

@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!

solussd 17:25:08

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

solussd 17:25:20

I don’t recall seeing this in the past

danielstockton 17:35:43

@solussd static om/IQuery ?

solussd 17:36:02

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

danielstockton 17:37:56

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

solussd 17:38:42

@solussd uploaded a file: @danielstockton

solussd 17:39:14

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

danielstockton 17:40:40

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

solussd 17:41:24

it appears to be an instance of my component. :confused:

solussd 17:42:01

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

solussd 17:42:17

or, #‘RootView

solussd 17:45:06

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

solussd 17:45:55

<binary search underway>

solussd 17:46:22

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

solussd 17:49:08

issue caused by latest clojurescript release (1.9.293)

solussd 17:51:53

@yaw ^ is your problem from yesterday, too.

yaw 17:55:37

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

solussd 17:55:51

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

solussd 17:56:09

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

solussd 18:09:12

not sure if this is an om bug (given how defui* implements the protocols) or a clojurescript bug, but regardless:

peeja 19:00:28

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

peeja 19:00:34

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

peeja 19:01:07

^ This input lets me type text in the box

peeja 19:02:04

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

peeja 19:02:27

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

peeja 19:02:57

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

hlolli 19:06:31

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.

peeja 19:07:53

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

hlolli 19:08:58

yes oops foo, I would expect that.

hlolli 19:10:08

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

peeja 19:10:38

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

peeja 19:10:55

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

hlolli 19:13:43

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

peeja 19:18:27

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

peeja 19:23:34

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).

tmorten 22:44:49

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

solussd 22:45:34

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

solussd 22:46:08

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

solussd 22:46:42

@tmorten ^, and yes, to answer your question. :slightly_smiling_face: