Fork me on GitHub

still don't understand this data.avl / clojure 1.9 issue. with the same clojurescript version (1.10.439) and compiled with 1.9 I get: app:cljs.user=> (type (first ( 0 0))) cljs.core/PersistentVector app:cljs.user=> (key (first ( 0 0))) #object[Error Error: No protocol method IMapEntry.-key defined for type cljs.core/PersistentVector: [0 0]]


compiled with 1.8 I get: app:cljs.user=> (type (first ( 0 0))) cljs.core/PersistentVector app:cljs.user=> (key (first ( 0 0))) 0


Sorry: ignore the above. I've now read your question more closely


thanks @mikethompson, a good try anyway


so I understand that PersistentVectors shouldn't be IMapEntries but I don't quite understand why cljs returns PersistentVectors for data.avl structures in the first place


@kaosko Previously, there was no such thing as map entries in ClojureScript. Without them, 2-element vectors were used as ersatz map entries. With 1.10.238, map entry support was fleshed out fully, and the core map implementations were revised to return bona fide map entries (for something like (first {:a 1})), and at the same time, the key and val functions were made to work on map entries, and the "bridging glue" for regular vectors was removed. It appears that needs an update so that its map implementation returns map entries under 1.10.238 and later.


@mfikes, yeah I got that. but I don't think it's that simple - I tried and it doesn't work any better with pre 1.10.238 versions and clj 1.9


On older versions of ClojureScript, you could do this (this is with 1.9.229):

cljs.user=> (key [1 2])


hmm ok. I think I only tried with 1.9.946


I guess it worked before with -key and -value functions implementing the procol functions for IMapEntry... yeah I was just looking at it ok


anyone knows how to have some code always running before clojurescript tests run?


to be more specific we use pjstadig.humane-output, but if we just evaluate and run tests in one namespace and it's not explicitly required in that namespace, it just blows up


for Clj it injects itself

:injections  [(require 'pjstadig.humane-test-output)
but that doesn't help for Cljojurescript


@andrea.crotti You can do setup and teardown before all tests, or before each deftest with use-fixtures


I find this doesn't allow me enough flexibility for certain things, so I opt to do the setup and teardown myself with a macro

(defmacro deftest-my-special-little-flower [name & body]
  `(clojure.test/deftest ~name
So for cases where say I had to setup and teardown my special little flower, I would use (deftest-my-special-little-flower my-test-case ...)


If you need even more flexibility, you could develop a deftest alternative that individually have injectable fixtures. re-frame has some interesting takes on that sort of thing.


@benzap mm not what I'm looking for, I'd like to not need to use another macro or actually change anything in the test namespaces


All I need is to make sure a certain require is always done


like a js/require, or a clojure require? I don't think a clojure require is allowed in clojurescript after compile-time


I sounds like one of your require's is producing mutable state, you could try reworking the namespace to make it idempotent


What's your favorite alternative to <button> elements for pure JS behavior? The default styling of buttons is driving me towards something else. I know I can just use a <div> or whatever but am wondering if there are any particularly appropriate things to do


Is there a specific thing that is lacking in how you want to style your buttons? has some good examples of nicer styles (I had the same thought a week or so ago and realized I could do everything I wanted without changing my element type)


I've recently used, very lite and much of bad defaults in css removed. But I wonder if grabbing towards div will make a bad SEO story. Don't know about the many screen readers visually impaired people use. I guess many look out for the html tag button.


Using non buttons for buttons is really bad for accessibility


I am aware that it's bad for accessibility but I just find myself restyling buttons over and over again and was wondering if maybe there was something that could be a more vanilla replacement (perhaps utilizing role= and similar attributes to maintain accessibility) 😄


there are many thing I find myself doing too, like removing yellow highlight after autofilling text fields. And not to speak removing padding and margin on html and body. I should make a default css to every new webapp, but somehow I always forget to make it 🙂


well the list is long, repitition is overwhelming, list styling, href styling, blue square on focus, default static display.


Not being a css guru, I have found using re-com components (including buttons) to be really nice. If you are unfamiliar, check the demo: Gotta use reagent though...


Buttons support by default a wide range of input methods, like keyboard navigation, trigger by space bar etc etc. Don’t replace them with divs lightly, IMO.


If your only concern is the styling, you could use libraries such as semantic ui to get nice default buttons.