Fork me on GitHub
#reagent
<
2016-07-21
>
rohit14:07:28

@nnbosko: see if this works:

(defn filter-dd [results]
    (r/create-class
        {: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))}))
         :reagent-render
            (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))])]])}))

nnbosko14:07:44

same result

nnbosko14:07:48

or error, rather

rohit14:07:36

@nnbosko: whats the exact error?

nnbosko14:07:01

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

rohit14:07:25

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

rohit14:07:46

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

rohit14:07:21

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

nnbosko14:07:01

Alright, I'll ask in cljs then

gadfly36114:07:43

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

nnbosko14:07:58

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

nnbosko14:07:17

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

gadfly36115:07:21

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

nnbosko15:07:24

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

gadfly36115:07:52

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

mattsfrey20:07:12

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

mattsfrey20:07:56

sweet, will check that out, thanks

bostonaholic20:07:21

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

shaun-mahood20:07:22

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

bostonaholic20:07:27

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.

bostonaholic20:07:32

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

bostonaholic20:07:02

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

mattsfrey20:07:54

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

bostonaholic20:07:35

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

mattsfrey20:07:38

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

bostonaholic20:07:20

hiccup and any UI specific generation should be “dumb"

mattsfrey20:07:53

@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

bostonaholic20:07:50

if I do, it should not be relying on reagent

bostonaholic21:07:00

but I rarely do

bostonaholic21:07:20

UI tests are slow, cumbersome, and break easily

bostonaholic21:07:17

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

shaun-mahood21:07:48

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

mattsfrey21:07:14

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

bostonaholic21:07:02

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

bostonaholic21:07:43

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

bostonaholic21:07:13

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

shaun-mahood21:07:53

@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 https://www.youtube.com/watch?v=G7Z_g2fnEDg

bostonaholic21:07:56

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

gadfly36121:07:53

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

shaun-mahood21:07:22

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

bostonaholic21:07:13

I completely agree

bostonaholic21:07:52

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