Clojurians Log v2

question for @clojurians.net or whoever

step 1 of getting started

add the artifact to your build configuration

in my case, a figwheel project

im used to adding deps to the top level :dependencies in my project

am i meant to be adding ghostwheel to my :dev build profile deps instead?

Additional question: I can't seem to get the syntax correct for a function with no arguments?

(>defn navigation-menu
       []
       [? => vector?]
       [:nav#navigation
        [:ul
         [:li [:i.fas.fa-bars]]
         [:li.active "Games"]
         [:li "Explore"]
         [:li "Leaderboards"]
         [:li "Contact"]
         [:li "Login"]]])

I thought this is what I'd want but it fails the >defn spec..

@samueldev I guess that first ? on the arg declaration shouldn't be there

have you tried just [=> vector?]?

@wilkerlucio that did it 🙂 thank you!

Now I'm getting some interesting (confusing) feedback from (g/check) on my namespace

Output:

https://puu.sh/AX6NA/dc12728bb1.png

(no details are present in the outputted log denoting that there's some kind of spec check failure)

(ns website.components
  #:ghostwheel.core{:check      true
                    :num-tests  10
                    :outstrument true}
  (:require [ghostwheel.core :as g :refer [>defn => |]]))

(>defn navigation-menu
       "website nav"
       []
       [=> vector?]
       [:nav#navigation
        [:ul
         [:li [:i.fas.fa-bars]]
         [:li.active "Games"]
         [:li "Explore"]
         [:li "Leaderboards"]
         [:li "Contact"]
         [:li "Login"]]])

(js/console.log (navigation-menu))

(g/check)

No. You're replacing your defns with >defn. If you were to run a build without ghostwheel as a dependency, those macros would be undefined. Ghostwheel does a good job of compiling away to nothing in a production build. Just make sure that your :ghostwheel configuration is only applied to your dev build.

@samueldev What version are you running?

0.2.3

@samueldev Hey, Sam, please confirm that it's the final 0.2.3 version and not a "-SNAPSHOT". I'll look into it in the meantime. On first sight some keywords look invalid, but not sure if that's related – I don't think you can have . in a keyword.

that's the reagent shorthand syntax for classes on a dom element

https://reagent-project.github.io/

(see first example Source)

and it is the final version, yup 🙂

Got it, will get back to you a bit later.

@samueldev I can't reproduce this here, everything checks out fine with 0.2.3, so let's make sure this isn't a stale build/cache issue first. Clean your build, remove .shadow-cljs if you're using it, remove ~/.m2/repository/gnl and try again.

On a side note – I'd recommend against outstrumenting the whole namespace when you're also checking it. This is a bit of a belt and suspenders situation and most likely you really only need one.

And regarding the . in keywords – apparently we were both sort of right. It violates the specification as far as I understand it, but the compiler's fine with it and changing that would break too much existing code, so I guess it's fine and likely to remain so. A bit like keywords starting with a number.

I was under the impression that ::g/check just enabled generative testing; not any kind of runtime call-checking. Looking at the docs, I can't find anywhere that outlines exactly what ::g/check does. Why would you recommend against using both? Does ::g/check report contract violations during runtime?

::g/check doesn't do anything at runtime (differentiating here between runtime and test time). It's the recommended approach, because you get proper code coverage, a much higher likelihood of catching edge cases, and no runtime performance penalty. I don't really use ::g/outstrument or ::g/instrument, but I know people do and it was easy to implement, that's why it's in there. But when they are used, I'd say it makes more sense to use them on a single function basis.

But point taken on that it's not exactly clear from the documentation what ::g/check does under the hood, precisely. I'll add it to the readme, but the tl;dr is that it generates the test code and is required for the additional checks that (g/check) does.

Everyone – if you have 2 seconds, please vote here for your preferred gspec operators if you haven't yet: https://clojurians.slack.com/archives/CBGSAMBPW/p1531436074000224 (message is pinned to the channel) I'm not taking anything out, just curious how Clojurians feel about this in general.