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 (clojure.data.avl/sorted-map 0 0))) cljs.core/PersistentVector app:cljs.user=> (key (first (clojure.data.avl/sorted-map 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 (clojure.data.avl/sorted-map 0 0))) cljs.core/PersistentVector app:cljs.user=> (key (first (clojure.data.avl/sorted-map 0 0))) 0

@kaosko there was a change in the 1.10.238 Release https://clojurescript.org/news/2018-03-26-release#_map_entries

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 clojure.data.avl 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])
1

hmm ok. I think I only tried with 1.9.946

@kaosko You can see it returns a vector here https://github.com/clojure/data.avl/blob/master/src/main/cljs/clojure/data/avl.cljs#L771

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

Compare with what ClojureScript's core map implementations do: https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L6715

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)
                                  (pjstadig.humane-test-output/activate!)]

@andrea.crotti You can do setup and teardown before all tests, or before each deftest with use-fixtures https://clojuredocs.org/clojure.test/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
      (set-up-fcn)
      ~@body
      (tear-down-fcn)))

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

hmm

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

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.