Fork me on GitHub

@nnbosko: see if this works:

(defn filter-dd [results]
        {:component-did-mount (fn [this] (.dropdown ($ (r/dom-node this)) #js {:onChange (fn [v,t,c] #_(println v t c) (get-entries-by-tag results v))}))
            (fn []
                [:div {:class "ui fluid selection dropdown" :id "tag-dd"}
                    [:input {:name "tag" :type "hidden"}]
                    [:div {:class "default text"} "Filter by Tags"]
                    [:i {:class "dropdown icon"}]
                    [:div {:class "menu"}
                        (for [i log-events]
                            ^{:key (:tag i)}
                            [:div {:class "item" :data-value (:tag i)} (str (:tag i) " - " (:description i))])]])}))

Nicolas Boskovic14:07:48

or error, rather


@nnbosko: whats the exact error?

Nicolas Boskovic14:07:01

core.cljs:120 Uncaught TypeError: jayq.core.$.call(...).dropdown is not a function


what this is saying is that (.dropdown ($ (r/dom-node this)) isn’t valid


or rather ($ (r/dom-node this))


this is a cljs<->js interop issue and not a reagent issue

Nicolas Boskovic14:07:01

Alright, I'll ask in cljs then


@nnbosko just a guess, but try js/$ instead of $

Nicolas Boskovic14:07:58

Same error, though at least it says $(...).dropdown is not a function now

Nicolas Boskovic14:07:17

It's kinda wierd cause I haven't had this issue in previous projects


@nnbosko: I think I got it. I tried the spirit of your code with a minimal example, and it worked for me. However, when i didnt include the semantic ui javascript, i get the error that you see. If you are using cljsjs, dont forget to include this in your namespace requires [cljsjs.semantic-ui]

Nicolas Boskovic15:07:24

I fixed the mistake; turns out I was loading app.js before semantic.js, it's always the little things 😛


awesome! yeah, i continually get bit by the little things 😆


wondering what tools people are using currently for unit testing / integration testing using cljs and a react wrapper like om or reagent?


sweet, will check that out, thanks


I would recommend not testing the UI. Any logic should be pulled out of your react/reagent components and unit tested in isolation


@bostonaholic: I've found it pretty useful to test certain areas of the UI in the past, particularly in places where the UI is more complicated than the logic behind it. Before devcards it wasn't worth the overhead for my projects, but I now use devcards to both design and allow testing and verification for the parts of the UI that it makes sense for.


I understand some find it useful. I haven’t found testing the UI very useful and more of a hindrance in my experience. When thinking about a UI in terms of “data-driven” if you’re testing anything other than the data, you might have a bad time.


tests need to then change when a UI tweak is made and not a behavioral change, which is what I prefer to focus my tests on


to me, testing the UI (react/reagent) is similar to testing ring or another lib on the server. Tests should be blind to underlying implementations


interesting, I had been leaning in this direction myself overall as we use inline styles and everything in the app is literally a function that returns hiccup and could be tested as such etc


I find little value in testing hiccup and/or css styles


@shaun-mahood: any particular areas in specific you like to test?


hiccup and any UI specific generation should be “dumb"


@bostonaholic: do you not find it useful to do integration tests such as going through login flows and such? Part of me leans towards at least having some tests being done by a headless browser to verify some of the ui flows work properly


if I do, it should not be relying on reagent


but I rarely do


UI tests are slow, cumbersome, and break easily


there often times are faster tests that can be written which describes the behavior of your “flow” which do not require the UI


@mattsfrey: Here's what I've done for the places where it's held the most value for me. I design the component in devcards (as data-driven as possible), then set up a number of cards to test the areas I'm interested in validating or testing. Usually I will have a couple to test the basic functionality and expected data, then I will add more individual cards for edge cases that I expect may have some issues or add cards for particular issues I run into during development or that users run into later on. I will often test how the component fits into certain HTML or CSS structures (things like floating multiple components, fixed-width divs, etc.) depending on the expected use, as well as particular widths to test for things like phones and tablets. I will then use the test page to verify that everything still looks as expected as I'm making changes that may affect things (particularly CSS changes) and to rule out or narrow down issues when I run into other problems with the overall program.


I will definitely try out devcards and see if I like it, heard a lot of people recommend it


I’ve not used devcards so I’m unfamiliar with testing it


but there would be ways to test what you described without the use of UI in your tests


for instance, width can be calculated and passed to the component before render, test that piece instead of the component’s width


@mattsfrey: I would recommend it, it's changed the way I develop web apps and I would hate to have to live without it. It changed the way I look at UI development. There is a great intro video at


I am impressed by devcards and would like to try it out, just haven’t taken the time


Quickstsrt to use devcards, lein new reagent-figwheel myapp +devcards


@bostonaholic: I think it may just come down to preferences and habits, as well as team structure and application size and scale. Devcards has hit the sweet spot for what I want out of UI testing and may not work for what you are looking for in terms of your testing requirements, but I would still use it for design and development even if I weren't using it for any types of testing.


I completely agree


and I can’t yet say if using devcards works for me or not, since I’ve not taken the time to try it out