This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-13
Channels
- # announcements (3)
- # babashka (130)
- # beginners (73)
- # calva (22)
- # cider (46)
- # cljdoc (18)
- # cljs-dev (196)
- # cljsrn (18)
- # clojure (255)
- # clojure-europe (2)
- # clojure-finland (8)
- # clojure-gamedev (1)
- # clojure-germany (2)
- # clojure-losangeles (6)
- # clojure-nl (1)
- # clojure-spec (16)
- # clojure-uk (33)
- # clojurescript (32)
- # community-development (1)
- # conjure (40)
- # core-logic (11)
- # cursive (4)
- # datascript (8)
- # devcards (17)
- # emacs (21)
- # exercism (2)
- # fulcro (29)
- # funcool (15)
- # graalvm (18)
- # jobs (17)
- # jobs-rus (1)
- # lambdaisland (1)
- # lumo (1)
- # malli (19)
- # off-topic (15)
- # pathom (22)
- # quil (7)
- # re-frame (3)
- # reagent (3)
- # shadow-cljs (14)
- # spacemacs (41)
- # specter (2)
- # sql (5)
- # tree-sitter (1)
- # unrepl (16)
- # vscode (3)
- # xtdb (11)
- # yada (1)
Hi, I would like to do some "spec driven development" in cljs, where should I start? Is it the same for clojure and clojurescript?
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.
Thanks for the note on 'separate', I was just thinking about that, I saw a video with @U064X3EF3 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 @U0CLLU3QT ? : D
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)
app.components.specs.cljs
(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 😉
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)