Fork me on GitHub
#clojurescript
<
2020-12-08
>
Shako Farhad13:12:14

Has anyone any experience with using Lottie in clojurescript? Any quickstart guide for it?

👀 3
Carlo15:12:20

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?

p-himik15:12:40

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.

Carlo15:12:57

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

p-himik15:12:43

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.

p-himik15:12:17

Also, if your select has only two values that are true and false, you may want to consider using a checkbox instead. :)

Carlo15:12:54

how does (case value "true" true "false" false) assert that automatically? Good point about the checkbox

p-himik15:12:46

Try executing (case 1 2 1).

Carlo15:12:42

I see, it returns an error instead of returning a nil

Carlo15:12:00

which makes it easy to spot it, even if I only catch it at runtime

Carlo15:12:14

thanks for all the answers @U2FRKM4TW, I really appreciate it

👍 3
Carlo17:12:11

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?

p-himik18:12:09

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.

Carlo18:12:33

yes, that was the plan B (because it's a bit ugly). But I think I'll do this, after all, thanks

p-himik18:12:26

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. :(

henryw37421:12:56

Tick library will do this

p-himik22:12:08

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.

p-himik22:12:19

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.

henryw37409:12:39

Yes it's not right for all situations

Calum Boal21:12:33

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?

Dane Filipczak22:12:53

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.

dpsutton22:12:30

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

👍 9
Calum Boal23:12:24

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

Carlo23:12:21

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?