This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-10
Channels
- # aleph (3)
- # architecture (3)
- # bangalore-clj (5)
- # beginners (75)
- # boot (75)
- # cider (2)
- # cljs-dev (48)
- # cljsjs (3)
- # cljsrn (17)
- # clojure (125)
- # clojure-belgium (1)
- # clojure-boston (1)
- # clojure-italy (20)
- # clojure-losangeles (2)
- # clojure-spec (73)
- # clojure-uk (34)
- # clojurescript (127)
- # cursive (8)
- # data-science (5)
- # datascript (128)
- # datomic (5)
- # emacs (4)
- # events (3)
- # fulcro (1)
- # jobs (1)
- # jobs-discuss (4)
- # jobs-rus (9)
- # keechma (79)
- # lein-figwheel (2)
- # leiningen (2)
- # lumo (31)
- # om (1)
- # parinfer (61)
- # pedestal (1)
- # planck (1)
- # portkey (31)
- # re-frame (34)
- # reagent (53)
- # ring (3)
- # ring-swagger (13)
- # rum (1)
- # spacemacs (14)
- # testing (1)
- # yada (2)
Maybe just wrap q-id
and id
in a str
?
TaggedValue sounds like a problem with transit decoding
So check the place where you are getting the questions
data and validate if the types are correct there
js/console.log
should work great, if you have cljs-devtools
https://github.com/cognitect/transit-js/blob/master/src/com/cognitect/transit/types.js#L43
if you are using reagent, it would make more sense to use this one https://github.com/cognitect/transit-cljs
transit-cljs builds on top of transit-js
I’ve a reaction that recomputes from js/undefined to null, but that doesn’t cause the components to update
(= nil js/undefined)
true
;; impl of _run
(when-not (or (nil? watches)
(= oldstate res))
(notify-w this oldstate res)))
k that makes sense, thanks @pesterhazy
@juhoteperi i've used console log i am getting transit
i though that was the problem. so i started returning map and then use transit VM12870:1 Uncaught SyntaxError: Unexpected token ( in JSON at position 0 at JSON.parse (<anonymous>)
Is Reagent 0.7 also supposed to work with React 15.6 or is it locked to a specific version?
@borkdude Reagent 0.6.1 has a new version of React (15.4.0), and it fixes a bug with :ref attributes on input elements: #259.
so regarding this code
(defn lister [items]
[:ul
(for [item items]
^{:key item} [:li "Item " item])])
You can avoid the key item meta data by using a parent 'into' on the :ul vector, which will make the items a proper react hierarchy
^{:foo bar} x
is the same as (with-meta x {:foo bar})
good point
it's less magical to just pass it as a prop IMO
better style
In that case :key
can be provided in either, but if you use custom component in loop, you need to use metadata: (for [item items] ^{:key (:key item)} [custom item])
Well, that will work differently. If a item is updated or one item added into the list, React will have to do a lot more work to update the DOM.
When rendering dynamic lists, one should always use keys if it possible.
Or perhaps custom
could use props, I don't remember if that works aswell. But I think it is logical to set the key where the list is rendered.
You can avoid the key item meta data by using a parent 'into' on the :ul vector, which will make the items a proper react hierarchy