This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-05
Channels
- # adventofcode (95)
- # announcements (3)
- # babashka (11)
- # beginners (39)
- # boot (19)
- # bristol-clojurians (1)
- # cider (32)
- # clj-kondo (39)
- # cljsrn (8)
- # clojure (156)
- # clojure-dev (35)
- # clojure-europe (4)
- # clojure-italy (15)
- # clojure-nl (28)
- # clojure-spec (43)
- # clojure-uk (153)
- # clojurescript (168)
- # core-async (13)
- # core-logic (11)
- # cryogen (4)
- # cursive (13)
- # datomic (26)
- # duct (3)
- # emacs (8)
- # fulcro (33)
- # garden (4)
- # graalvm (18)
- # graphql (4)
- # jobs-discuss (2)
- # kaocha (1)
- # leiningen (3)
- # malli (8)
- # off-topic (1)
- # pathom (7)
- # re-frame (21)
- # reagent (3)
- # rewrite-clj (1)
- # schema (4)
- # shadow-cljs (40)
- # sql (2)
- # uncomplicate (3)
I’m unclear on how to go about creating/managing component local state. Could anyone be so kind as to offer the fulcro version of this reagent example?
@jarrodctaylor 1. That isn’t component-local state. That’s an ratom closed over in a lambda. 2. The book covers these topics quite extensively.
You’d typically do that with a component that has an ident like this:
(defsc Item [this {:item/keys [checked?]}]
{:query [:item/id :item/checked?]
:ident :item/id
:initial-state {:item/id 1
:item/checked? false}}
(input {:checked checked? :onClick (fn [_] (m/toggle! this :item/checked?))}))
this gets you normalized data in state database, data-driven support for things like server queries, etc.
toggle!
is just a shorthand for a pre-build mutation that knows to find the item in the state db according to its ident
But you’re going to get nowhere trying to duplicate trivial examples. Trivial examples will always be “easier” using ratoms and will seem unreasonably complex…until you consider how the components will really be used in real world applications. Fulcro is about managing complexity at scale.
Thanks Tony. I’m working my way from trivial to complex.
Hello everybody. I use sablono for the html part of my components, but I can't seem make on-click events work. I read about the computed props parameter, but I don't think it applies to this situation, as the handlers don’t even show up in chromes inspector. My handler is simple.
(defn on-click [octave key _]
(comp/transact! PianoKeyboard `[(mut/highlight-key-green {:keyboard/octave ~octave
:keyboard/key ~key})]))
Which is then used in a component like this
(for [j (range 7)]
(white-piano-key i j (key-color i j green-key red-key) (partial on-click i j)))
white-piano-key
is a function that returns a svg rect.
(defn white-piano-key [octave key-number key-color on-click]
[:rect {:id (str "piano-key-"
(white-key-number->name key-number)
;; ...
:key (str "white-key-" octave "-" key-number)
:onClick on-click}])
I also tried :on-click
in stead of :onClick
with the same results.
Does anybody know whats going wrong?The first parameter to transact!
is app-or-component
. You are passing a class. Usually it will be this
. But you can pass app
if this
is too inconvenient.
Obviously you can debug to make sure receiving the click. Then debug to make sure the mutation is getting called. Need to know more about what you mean by 'can't seem make on-click events work'.
As you suggested, I debugged my code and saw that the Handler is called after all. I just think it is strange that no error showed up in the js console, witch lead me to believe that my handler was never called. Thanks for helping, sometimes I miss the obvious.
What tools are you guys using to measure test coverage? Cloverage looks like it has pretty deep integration with lein, and I'm not using that with Fulcro. Ah, I guess I should try kaocha with kaocha-cloverage.
what does test coverage even measure? every line of code is executed by your test suite, IMO that’s a low bar
good tests have the following properties, when you introduce a bug • a small number of (preferably 1) tests fails • failure message is very specific about the context and broken behavior • failure message has a small diff/assertion (preferably scalars no data-structures)
does coverage measure any of that?
you can get 100% coverage with really crapy tests but they won’t help when you are refactoring/building
i definitely understand the desire to have a hard metric that we can point to as the health of our tests, but i don’t think coverage is that metric
Measuring coverage does not produce perfect tests, but it is a good tool that belongs in every testing process. That's why you see so many repos with coverage badges at the top of their readme - it correlates pretty well with code quality.
what makes it a good tool? just because everyone else does it?
is it just a correlation?
It's helpful because it lets you see gaps in your testing. Anyway, I'm not down to debate the merits of measuring test coverage.
sounds good
bad coverage normally means bad quality, but good coverage doesnt imply good quality, so people use it as a proxy when they're in a hurry 🙂
yeah i’m of the opinion there are parts of the code base worth testing with high quality tests and parts that are just not worth it
in fulcro we have really good tests around the various algorithms for state normalization and query engine, the way to test the tests is intentionally break the logic in a subtle way and you should see a very clear, concise, and simple error message explaining what’s broken, in what context and why
and there’s stuff like the networking components (xhr and ws), which do a lot (sequential request queue, pending markers, abort pending requests, integration with tooling etc) which we don’t have any tests for, we feel this stuff is best tested in actual applications with real users
i take a similar approach to application development, test business logic heavily, manually verify plumbing
that said, i can totally recognize that there are multiple ways to write effective software
with different tradeoffs
Why not include some integration tests for verifying the plumbing? It's no silver bullet, but it does reduce the amount of manual work required to be sure that things are connecting properly. On the other hand, setting up your CI becomes far more complicated when your tests enter into that territory.