fulcro 2019-12-05 | Slack Archive

Jarrod Taylor (Clojure team)00:12:29

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?

tony.kay01:12:25

@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.

tony.kay01:12:05

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?))}))

tony.kay01:12:10

this gets you normalized data in state database, data-driven support for things like server queries, etc.

tony.kay01:12:51

toggle! is just a shorthand for a pre-build mutation that knows to find the item in the state db according to its ident

tony.kay01:12:31

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.

👍 8

Jarrod Taylor (Clojure team)01:12:24

Thanks Tony. I’m working my way from trivial to complex.

Philipp Siegmantel05:12:07

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?

cjmurphy07:12:03

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.

cjmurphy07:12:00

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'.

Philipp Siegmantel13:12:47

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.

👌 4

sheluchin12:12:40

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.

currentoor19:12:45

what does test coverage even measure? every line of code is executed by your test suite, IMO that’s a low bar

sheluchin19:12:48

How so? Coverage is a pretty fundamental metric for testing.

currentoor19:12:18

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)

currentoor19:12:41

does coverage measure any of that?

currentoor19:12:30

you can get 100% coverage with really crapy tests but they won’t help when you are refactoring/building

currentoor19:12:38

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

sheluchin19:12:03

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.

currentoor19:12:28

what makes it a good tool? just because everyone else does it?

currentoor19:12:59

is it just a correlation?

sheluchin19:12:09

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.

sheluchin19:12:55

It's useful for me, YMMV.

currentoor19:12:52

sounds good

mping10:12:16

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 🙂

mping10:12:31

im pretty sure there are alot of exceptions to that rule though

currentoor19:12:06

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

currentoor19:12:09

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

currentoor19:12:13

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

currentoor19:12:51

i take a similar approach to application development, test business logic heavily, manually verify plumbing

currentoor19:12:39

that said, i can totally recognize that there are multiple ways to write effective software

currentoor19:12:52

with different tradeoffs

sheluchin11:12:08

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.

2019-12-05

Channels