This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-28
Channels
- # announcements (6)
- # beginners (89)
- # boot (1)
- # calva (1)
- # cider (24)
- # cljsrn (19)
- # clojars (2)
- # clojure (102)
- # clojure-europe (2)
- # clojure-italy (9)
- # clojure-nl (1)
- # clojure-spec (6)
- # clojure-uk (56)
- # clojurescript (29)
- # code-reviews (14)
- # cursive (5)
- # data-science (1)
- # datomic (44)
- # duct (1)
- # emacs (10)
- # figwheel-main (5)
- # fulcro (8)
- # graphql (10)
- # hoplon (1)
- # leiningen (7)
- # overtone (17)
- # pathom (8)
- # re-frame (13)
- # slack-help (3)
- # spacemacs (22)
- # sql (2)
- # vim (3)
@domkm What's the motivation for Serene generating a spec for every enum value in an enum, instead of a single spec with enum values in a set? I've got some fairly large enums in my graphql schema and the current approach ends up generating files more than 2x bigger (a spec for each enum value in addition to its entry ni an enum spec). I'm not sure what the extra level of indirection is buying me.
Serene generates both a spec for the enum values as a set and a spec for each enum value. The goal is to be exhaustive as there might be a case in which one would want to refer to a specific enum value or a set of enum values that isn't represented by an enum type. If you want to remove/rewrite specs you can add a custom transducer to do so.
ah, that makes sense, thanks
bigger issue is I can't use def-specs bc I hit "method code is too large". 🙂
You must be working with a very large API. I think I have a fix for this. Please open an issue about it.
spit-specs
will work, regardless of API size, and is probably more pleasant to use for large APIs.
:thumbsup: