Clojurians Log v2

I think in general it’s similar. For UI applications the boundries that you want to focus your specs on are different of course. I consider anything coming over http and websockets a good candidate for checking with spec and all of my component props as well. If you’re using Reagent the later is easy because your components are already functions and you can just us s/fdef . Another consideration is I like to keep my specs separate from my other code on the F/E. Instead I write separate spec files that require the namespaces that I’m specing. Then you can make a preloads file that imports those spec files and runs st/instrument to get development-time feedback.

I am not using reagent because it has no support of modern react, I am using helix.

Thanks for the note on 'separate', I was just thinking about that, I saw a video with @alexmiller where it was noted to not use these in production and I am not quite sure how to do that. I thought that the compiler would remove these when I build for production and I will not have to maintain two versions of my code

It looks like the defnc macro in helix eventually produces a function with [props ?ref] that you can spec like a Reagent component: https://github.com/Lokeh/helix/blob/master/src/helix/core.clj#L80-L87

How many years before I can do what you just did @colinkahn ? : D

I can read the code, but all these ^s and ~ confuse the hell out of me.

and yeah, I am fairly sure I can spec it, it's more about the context/reducer situation that I am somewhat unsure. I think I can do state transition functions and spec those and then I can create spec for the state as input and output before and after the transition.

The “separate” approach for me works because I agree these are more development-time tools and don’t really belong in my production source code. The compiler I believe will remove most of it (I’ve seen tricks where frameworks using Google Closure features to help with this as well) but I think certain parts of the spec library itself cannot be dead code eliminated (though don’t quote me on that, and probably better to try it yourself). For having two versions, this isn’t necessary. For example: app.components.cljs

(ns app.components)

(defn my-component [props]
  ...stuff)

(ns app.components.specs
 (:require [app.components :as c]))

(s/fdef c/my-component
  :args (s/cat ...))

https://clojurians.slack.com/archives/C1B1BB2Q3/p1586873997105600?thread_ts=1586766083.099100&cid=C1B1BB2Q3 You have to go through your “macros” phase 😉

I haven't even started that... : )

This is the preloads feature I was referring too: https://clojurescript.org/reference/compiler-options#preloads Once you have your *.specs namespaces I make a single specs.preload or something that is roughly:

(ns app.specs.preload
  (:require [clojure.spec.test.alpha :as st]
            ; all your spec namespaces here
            [app.component.specs]))

(st/instrument)

This is somewhat different for shadow-cljs, right?

It’s pretty much the same, you’d specify the preloads in your build defined in shadow-cljs.edn

https://shadow-cljs.github.io/docs/UsersGuide.html#_preloads

Actually yeah, it’s under a different key