Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-11-20

Channels

#fulcro
<
2022-11-20
>
Eva O02:11:43

I'm getting: ------ WARNING #1 - :redef ----------------------------------------------------- Resource: cljc/java_time/duration.cljs:33:1 abs already refers to: cljs.core/abs being replaced by: cljc.java-time.duration/abs I believe this is because RAD is dependent on an old version of cljc.java-time before this was fixed.

tony.kay17:11:21

Yes, cljc java time is a bit of a problem. The library was originally published without a group id in maven. The author has since added one, but that means that now you can end up with both on the class path at the same time from library dependencies, which is a real nightmare. It's on my list to do something about, but I can't really fix it by myself, because I don't own that library. The real fix would have been to completely change the name spaces in that library when changing it's Maven coordinates so that you wouldn't end up with this problem.

tony.kay17:11:38

Really, the best you can do is to specify recent version of the new coordinate in your local depths, and then add exclusions for every dependency that accidentally pulls in the old version. If you don't do that, then you'll end up with both on the class path, and random results as to which gets used. A real nightmare.

tony.kay17:11:12

When I get a little time, I will upgrade all of those in fulcro dependencies, so you won't have to have exclusions there, but you're stuck with the problem kind of for life because other libraries that you use might use it as a as well

Eva O17:11:30

Oh thanks that fixed it

Eva O02:11:01

It's kinda inconsistent that valid? takes in props but validation-message does not. If you want to have a validation message that matches everything you can validate for in the first place, you need to put validation-messages on the form itself

tony.kay12:11:49

There is no guarantee that for an attribute you’ll be in the context of a form, nor will you know what the form is including. Therefore the attribute level validation message can ONLY know it’s value. If you put validation-messages on the form, then you have context. You know what fields (and extra stuff) from that context. If you assume a particular form’s context in an attribute it will lead to bugs.

tony.kay12:11:06

There’s no way for an attribute to guarantee in a UI context that the developer of the form actually pulled in what might be required for anything beyond basic data validation of that field in isolation (e.g. it is a string that isn’t blank).

tony.kay12:11:41

but if you’re writing the form and you want to do something like “make sure these two passwords match”, then it is obvious to you that you need to query for both of them.

tony.kay12:11:06

Note that you can also over provision fo/validation-messages on any form. So if you want to make a global map of form validator for all of your attributes and make up your own defattr option, then you can just include your global validation messages with a single line of code on any form. Make you own macro and auto-include that and you don’t even have to type anything extra.

nivekuil05:11:33

anyone try the react 18 render functions yet? It seems to be a bit more involved than replacing :render-root! etc. with the advertised equivalents. I tried something like 

(defonce root (react-dom-client/createRoot (js/document.getElementById "app")))
;; adding these to app
{:render-root! (fn [args] (.render root args))
 :unmount-root! (fn [] (.unmount root))
 :hydrate-root! (fn [args] (react-dom-client/hydrateRoot (js/document.getElementById "app")
                                                                                args)
                                           )}
but it seems root renders get missed

nivekuil12:11:58

hmm, nope, still loses props on root render