Clojurians Log v2

I don't really know but I believe that the default behavior in Q might be to only log warnings and you must switch on throwing exceptions.

Check your (System/getProperty "guardrails.enabled") and make sure it is actually set in your REPL

There’s very little to the macro, other than the config + turning it on/off

Hmm!! Okay, that was super helpful!! Obviously, I don’t understand :jvm-opts as well as I thought! 🙂 > (System/getProperty “guardrails.enabled”) > => nil Huh. I just spent 30m scouring the docs on deps.edn…. Is it not allowed to put a :jvm-opts at the highest level in a deps.edn file?

{:src      ["src"]
 :jvm-opts ["-Dguardrails.enabled=true"]
 :deps     {analytij/analytij                   {:mvn/version "0.4.0"}
            com.fulcrologic/guardrails          {:mvn/version "0.0.12"}
            org.clojure/data.csv                {:mvn/version "0.1.4"}
            vlaaad/reveal                       {:mvn/version "1.1.164"}}
 :aliases  {:test {:extra-paths ["test"]
                   :extra-deps  {lambdaisland/kaocha {:mvn/version "1.0.700"}
                                 org.clojure/test.check {:mvn/version "1.1.0"}}}}

…holy cow… :jvm-opts must be inside of an alias.. 😱 https://clojure.org/reference/deps_and_cli Prepare JVM environment JVM arguments may either be passed on the command line (with `-J`) or by using data stored in an alias under `:jvm-opts` and passed with `-X` or `-A` or `-M`

It’s working. Thank goodness. (Trying not to weep at the time I spent on this…. Worth it, though! 🙂

@tony.kay BTW, can one put things like #(instance? LocalDateTime %) (or String or any class) into the parameter types? When I try, I get this error. Thx for your great work here, and I’m looking forward to your commercial offering — consider me on the “must buy” list, as well as happy to test anything you have!

(>defn tt2
    [x] [int? => #(instance? java.time.LocalTime %)]
    (+ 1 1)))
Syntax error compiling at (src/analytics/guardrails_test.clj:10:1).
Unable to resolve symbol: fn* in this context

yep…parsing limitation. Might fix eventually, but for now just s/def that and use the keyword instead

Thank you! Makes total sense now! And PS: just watched your RAD video on YouTube, after listening to your interviews on ClojureScript podcast and scanning all the docs. Wow. I'm inspired to give it a try this weekend!

Thanks for all your great work — Fulcro RAD seems like the closest we've come to Microsoft Access for designing form based apps. That's meant as a huge compliment!!! Keep up all your amazing work!

1. You can choose to delete from a parent. Then the “component” won’t be the one you’re deleting. 2. You can change the default result action. It is pluggable. Take out the errors on ui component stuff, perhaps you don’t even use it. 3. You can choose not to GC this particular thing…there’s a lot of RAM in a browser

One thing that strikes me is your global resolver is liable to return {:foo nil}. You could slightly alter things so that if (get @foo-table 1) is nil then your resolver actually returns say :unknown-foo. I regard any resolver returning nil as a bug in my own code.

That's a good rule of thumb to remember, no resolver should ever return nil. Thank you guys. It ended up being a silly fault of my own but your replies were helpful nonetheless.

are both in the query? All components come with a shouldCopmonentUpdate that checks for props diffs. If props don’t change, components don’t re-render…and if things are not in the actual query, then targeted refresh will not send them (and thus nothing will change). If rendering is broken, this is almost always the cause.

They are, I even println them in the rendering function to make sure that all values used for rendering are indeed what they should be. Still, when a mutation leads to changing both max and value at the same time, only max gets updated in the DOM although I know for a fact value changed as well (ie. its prop). Furthermore, If I save my files and trigger compiler + re-rendering, then value gets updated as expected. Well, to be more precise, I noticed some float wizardry. value doesn't stay exactly the same, it's changing from 1.444446 to 1.4444457 for instance. No idea what is happening there! Disclaimer, that component is not exactly trivial, it uses getDerivedStateFromProps for instance, there is room for a weirdness. However I did spend some time on it, trying different variations, the end result was always the same. I was wondering if it wasn't due to React, maybe something like the algorithm updating max before value? But I would have a hard time believing no one noticed this before.

If you get to a small reproducible issue that I can pull into a workspace card it would be helpful. I don’t have the time to do much else. I’m not aware of any Fulcro issues, but I’m sure getDerivedStateFromProps is not heavily used.

@tony.kay All right, the problem kept reappearing... and the solution is weird. I have no idea why but working with float values (even set as strings, as they should) results in the DOM input range updating its value only every couple of times, and this happens only with renders happening after mutations, not after set-state!. The rendering function runs all right, everything is fine, all props are correct, it really is about the DOM (React itself?) and the value (other DOM properties such as max were always updating as expected). The issue completely disappeared since I've starting working exclusively with integers. Spooky. If you hear about this again someday I recommend mentioning it in the book since it is a particularly strong head-scratcher (hours spent on the matter...)