Clojurians
#om
<
2017-01-17
>

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

levitanong03:01:55

@yaw what seems to be the problem?

yaw14:01: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!

solussd15:01: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?

solussd15:01:20

I don’t recall seeing this in the past

danielstockton15:01:43

@solussd static om/IQuery ?

solussd15:01:02

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

danielstockton15:01:56

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

solussd15:01:14

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

danielstockton15:01:40

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

solussd15:01:24

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

solussd15:01:01

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

solussd15:01:17

or, #‘RootView

solussd15:01: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.

solussd15:01:55

<binary search underway>

solussd15:01:22

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

solussd15:01:08

issue caused by latest clojurescript release (1.9.293)

solussd15:01:53

@yaw ^ is your problem from yesterday, too.

yaw15:01:37

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

solussd15:01:51

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

solussd15:01:09

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

solussd16:01:12

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

peeja17:01:28

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

peeja17:01:34

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

peeja17:01:07

^ This input lets me type text in the box

peeja17:01:04

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

peeja17:01:27

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

peeja17:01: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?

hlolli17:01: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.

peeja17:01:53

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

hlolli17:01:58

yes oops foo, I would expect that.

hlolli17:01:08

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

peeja17:01: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)}))

peeja17:01:55

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

hlolli17:01:43

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

peeja17:01:27

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

peeja17:01: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).

tmorten20:01:49

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

solussd20:01:34

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

solussd20:01:08

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

solussd20:01:42

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