so from the department of This Can’t Be Happening, I speced out a reagent component with fdef and instrumented it, and now it actually calls one of the callback-handlers that is passed to the component as part of the instrumentation process. is this expected/possible? or am i misunderstanding? in the code below, the on-cancel callback gets called 21 times if I leave the instrument call in the code

(spec/def ::name string?)
(spec/def ::class string?)
(spec/def ::type string?)
(spec/def ::*value #(instance? reagent.ratom/RAtom %))
(spec/def ::on-cancel (spec/nilable (spec/fspec :args (spec/cat))))
(spec/def ::focus? boolean?)
(spec/fdef input
 :args (spec/cat
        :props (spec/keys
                 :req-un [::type ::*value]
                 :opt-un [::class ::focus? ::on-cancel]))
 :ret any?)

(stest/instrument `input)

fspec args are validated by gen’ing from the :args spec and invoking the function, then checking the :ret spec

some people have found this to be surprising :)

probably the easiest “fix” is to replace (spec/fspec :args (spec/cat)) here with ifn?

the good news is i’m not crazy 🙂

sometimes i suspect i’m using spec improperly. i really just want an assertion library to catch my typos

so is it ever possible/safe to use fspec with a side-effecting function? i don’t see how it could ever work unless you passed it a pure function

I would not advise it

passing a side-effecting function that is

there are ways to (for example) swap out an alternate spec when you instrument - those are optional capabilities of instrument

but I’m not sure you’re getting much value than bother out of having the fspec at that point

TIL about stubbing in s/instrument

well I’m talking about replace, not stub, but yeah

stubbing is great for stubbing out a remote call in instrument

if I'd commit fdef + instrument-with-stub instead of actual implementation, I wonder how quickly my teammates will notice in production?

oh, pretty quick I’d guess

unless you wrote some really good generators

number?