clojurescript

ClojureScript, a dialect of Clojure that compiles to JavaScript http://clojurescript.org | Currently at 1.10.879
p-himik 2020-12-08T03:52:13.185900Z

What is $?

Shako Farhad 2020-12-08T13:19:14.188100Z

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

đź‘€ 1
william 2020-12-08T15:00:20.190Z

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-himik 2020-12-08T15:04:40.191Z

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.

GGfpc 2020-12-08T15:04:46.191300Z

https://clojurians.slack.com/archives/CALJ3BFLP/p1607189001162900 Does anyone have any idea how to deal with this?

william 2020-12-08T15:06:57.191500Z

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-himik 2020-12-08T15:08:43.191700Z

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-himik 2020-12-08T15:09:17.191900Z

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

william 2020-12-08T15:10:54.192100Z

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

p-himik 2020-12-08T15:11:46.192300Z

Try executing (case 1 2 1).

william 2020-12-08T15:13:42.192500Z

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

william 2020-12-08T15:14:00.192700Z

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

william 2020-12-08T15:14:14.192900Z

thanks for all the answers @p-himik, I really appreciate it

đź‘Ť 1
william 2020-12-08T17:45:11.197800Z

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?

2020-12-09T21:56:56.214700Z

Tick library will do this

p-himik 2020-12-09T22:26:08.214900Z

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-himik 2020-12-09T22:41:19.215200Z

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.

2020-12-10T09:55:39.216800Z

Yes it's not right for all situations

p-himik 2020-12-08T18:08:09.198Z

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.

william 2020-12-08T18:12:33.198200Z

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

p-himik 2020-12-08T18:19:26.198400Z

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

Calum Boal 2020-12-08T21:43:33.200900Z

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 Filipczak 2020-12-08T22:19:53.203900Z

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.

dpsutton 2020-12-08T22:28:30.204900Z

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

đź‘Ť 3
Calum Boal 2020-12-08T23:22:24.206900Z

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

william 2020-12-08T23:49:21.208Z

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?