Fork me on GitHub

React 18 notes added to developer’s guide:

🙏 2
👍 1

Actually, it looks like hot code reload is broken with React 18

Andrey Boriskin11:12:37

Do you plan to add support for the new version of react so that everything works without surprises in it? (if possible)))


Yes of course. I just have not had time, and probably won't until after the holidays

🥳 2

I’ve not had time to test it out much, or add wrappers for the new hooks, but doing that switch in a demo app seemed to work.


Is there a way to combine these with fulcro-spec?

     (sut/select env "x") =throws=> #"Invalid SQL statement"
     (sut/select env "x") =throws=> (_/ex-data* (_/embeds?* {:stmt "x"
                                                             :type ::ex/incorrect}))))))


no idea…that was a contribution that I didn’t write. I don’t use the embeds stuff personally. I’m mainly interested in the fact that it threw. If I want to make assertions about what is in the ex-data, then I’ll try/catch it before making assertions so that I can just treat it as data. Much easier to read and reason about IMO.


(-> exdata :stmt) => "x"


that way I can also say what each thing is for, so when I get a failure I can read the darn thing


(let [e (try ... (catch e e))
      data (ex-data e)]
    (boolean data) => true
    "Includes the statement"
    (:stmt data e) => "SELECT foo..."


of course you can mix that with embeds if you really want it 😄


Valid points. I was just looking for the idiomatic fulcro-spec approach, but if there aren't well-established patterns to use, I'm okay with using a let as above. ty!


Idiomatic is a bit wiggly. The design of the lib is centered around my own test philosophies: • Able to control things not being tested (limit cascading failures and false positives) • Test failures should inform you what went wrong in a way that does NOT involve grokking the test. ◦ Aim for one assertion per behavior with a legible meaning (this is why assertions allows a label for each one) ◦ Wrap the whole thing with reasonable amounts of context (thus the descriptive string support of “component” “behavior” “assertions”, and “provided”)


(defn ensure-response! []
  (if (under-attack?)


(specification "ensure-response!"
  (let [launched? (atom false)
      ;; Prevent unwanted testing side-effect
      (launch-missles!) => (reset! launched? true)

      (provided "We are under attack!" ; indicate the context to the reader of the test results
        (under-attack?) => true  ; control an external check

        (ensure-response!) ; function under test

          "we launch our missles"
          @launched? => true))))



  PROVIDED We are under attack!
    we launch our missles


when you get into crazy assertions with nested data then the embed stuff can be nice (that’s why I accepted it), but since I prefer a descrpitive string on everything I want to happen, it isn’t very useful to me


Ah, I've not leaned on provided before. I saw it while browsing around the code, but it's not in the book, only the fulcro-spec readme. I'll try to get some use out of that to manage context as you describe. I'm planning on making more sense of my errors+logging and writing tests for more of it, so your advice is timely. In Python I have a very TDD approach, but I kinda get lazy with being able to check everything in Clojure's REPL.


In other words I accept that other ppl have preferences that are not mine 😄


and I hear you on the lazy, but you’d probably want a regression test to ensure that no one accidentally reorders those then/else clauses in that if in my example 😄


but you’d also probably want to make sure launch-missles was somehow impossible from you CI server as well 😛

😄 1

And I guess you probably do a lot of your sanity checks by using Guardrails specs. I did a lot of that in one project, but I don't think it's the right tool for data pipelines that process a lot of stuff, because of the performance penalty.


See #C015AL9QYH1. I just dropped new versions of 4 libraries to better support unions in forms.