What is $
?
Has anyone any experience with using Lottie in clojurescript? Any quickstart guide for it?
I have a question on best practices in clojurescript: since the return value of
[:select {:on-change #something)}
[:option {:value false} "first-option"]
[:option {:value true} "second-option"]]
is returned as strings, (so, "false"
instead of false
), do you usually convert back and forth when storing things in your state?IMO that fact that <option>
ends up converting its argument into a string is an implementation detail that should be kept in the view. The state should contain the actual domain-specific values.
https://clojurians.slack.com/archives/CALJ3BFLP/p1607189001162900 Does anyone have any idea how to deal with this?
right, I totally agree, and in fact I'm curious if there's an idiom to deal with this, since it must be so common (I thought about using read-string
but it seems unsafe, so I started doing (= "true" (.. % -target -value))
but it's kind of ugly
Don't use read-string
. It's not unsafe (simply because the client state is completely controlled by the client) but it's fragile.
For similar tasks, I use maps like {"true" true, "false" false}
with an assert that the value exist or something like (case value "true" true "false" false)
that asserts that automatically.
Also, if your select has only two values that are true and false, you may want to consider using a checkbox instead. :)
how does (case value "true" true "false" false)
assert that automatically? Good point about the checkbox
Try executing (case 1 2 1)
.
I see, it returns an error instead of returning a nil
which makes it easy to spot it, even if I only catch it at runtime
thanks for all the answers @p-himik, I really appreciate it
hey I'm trying to parse a date in the format YYYY-MM-DD
but both goog.date
and cljs-time
will gladly accept nonsense like 2020-02-70
, supplying bogus values (`goog.date` adds default values, cljs-time
adds the exceeding days to the month). While I can do the validation by myself, I find strange that that's not a solved problem. What's the common way of validating a YYYY-MM-DD
date?
Tick library will do this
Thanks!
But seems like it has some rather heavy dependencies. Personally, I would stick to the string comparison unless I needed tick
in CLJS for other reasons.
Ah, I see that you're the author of cljc.java-time
. :)
Just checked to make sure - @js-joda/core
takes up 173.71 KB in an :advanced
build.
Yes it's not right for all situations
Huh. If all else fails, I would probably just convert the resulting date back into a string and then compare the two strings. If they're the same then the input data should be valid.
yes, that was the plan B (because it's a bit ugly). But I think I'll do this, after all, thanks
So seems like cljs-time
is built on top of goog.date
which in turn is built on top of js/Date
. And the latter just works the way it does.
I couldn't find any easy way to do such a validation in JS. And seems like any attempt at doing that given the API that we have will result in a much uglier code that just comparing the strings. Dates and times are a mess. :(
So i'm building a calculator form in clojurescript for trading position sizes. Just want a quick sanity check on my approach: • Form inputs update re-frame db on change • Output fields subscribe to subscriptions which return relevant value of the calculation Not sure if this is idiomatic, but seems correct? Also, i need to reset the value of the form fields in the reframe db when the component is destroyed, is it ok practice to dispatch an event from a component lifecycle hook to handle this?
your approach seems sane! hard to say without more context of what you’re going for, but if you’re determined to keep your state in reframe, that’s how to do it. Regarding the dispatch in component-will-unmount - it may be clearer to clean up that state in whatever event is causing the component to be unmounted, but using the lifecycle method is also fine and you see that type of thing a lot.
agree with all of the above. there's also a handy macro in reagent with-let
that lets you add a finally
clause which makes it easier to do something at unmount without reverting to the map syntax for reagent and {:component-did-unmount ... :reagent-render ...}
Ahhh, very nice. That's exactly what I was looking for. Solved it by dispatching the event before returning the render function in a form-2 component but that with-let solution is much nicer. Also cheers for the sanity check Dane
when I use with-let
from reagent, I have a warning in emacs saying that I have an unresolved symbol (probably it doesn't realize that r/with-let
binds the same way as let
). Is there a workaround?