Fork me on GitHub
#clojurescript
<
2019-10-27
>
kwladyka08:10:09

> Every day I deal with 2-3 items from that queue and add 5-10 new items. The game is rigged from the start... oh… for me 1 thing take around a few months. I am even not counting small things which I can learn during the day 🙂

p-himik09:10:52

What is the correct usage of UtcDateTime.fromTimestamp? Many projects seem to use it just like that, with an accompanying (:import [goog.date UtcDateTime]). However, clj-kondo thinks that's its invalid.

p-himik09:10:02

Using it as in (:require [goog.date.UtcDateTime :as udt]) with (udt/fromTimestamp) doesn't produce any errors. But I'm not sure whether the initial usage is still wrong.

thheller09:10:53

thats a bit of an undefined area I guess. both variants end up emitting the same code

thheller09:10:07

:import doesn't really map that cleanly to CLJS -> JS as it does in CLJ -> Java

p-himik09:10:47

Yeah, I was afraid so. FWIW the page at https://clojurescript.org/reference/google-closure-library mentions cljs-time and says "Their source code also serves as good examples of how to use Closure directly." And cljs-time uses UtcDateTime.fromTimestamp.

thheller09:10:41

I guess clj-kondo complains because this would be invalid code in clojure

p-himik09:10:48

@borkdude Should I file a bug about the false positive for this?

borkdude11:10:40

@p-himik Please file an issue with a complete repro (full .cljs file that produces the error)

borkdude11:10:19

Since this is kind of undefined behavior in CLJS, maybe it's better if people started to adopt the require form?

borkdude11:10:25

What do you think @U05224H0W?

thheller11:10:29

:require is tricky too because of the special rules

thheller11:10:06

(:require [goog.date.UtcDateTime :as udt]) (udt. ...) isn't allowed (calling as constructor)

thheller11:10:28

since :as is only "callable" for JS deps, but this is a closure dep so it is kinda special

borkdude11:10:33

this is supported by clj-kondo if you use a string require there, since people do this with npm libs

borkdude11:10:51

ah only for JS, ok

thheller11:10:04

yeah. its a bit messy and things were added without a specific design

thheller11:10:23

imho (udt. ...) should be fine

thheller11:10:14

and only disabled for actual CLJS namespaces

borkdude11:10:38

is the gist of this example that there is no clear way of how people should do this in a current version of CLJS?

thheller11:10:09

there are many ways to do this and I don't know what the official correct way is

thheller11:10:21

some time ago I was strictly against supporting anything.foo and would have made that an error and forced (.-foo anything)

thheller11:10:32

but anything.foo is really convenient so I kinda changed my mind on that

thheller11:10:42

also too much code out there to ever remove it

borkdude11:10:13

ok, I'll check if I can just support it then, since it works and people do it

thheller11:10:20

it is a surprisingly difficult subject in the compiler. I tried coming up with a clean way to handle this but failed

thheller11:10:32

(strict way would be much easier) 😛

itaied20:10:47

Does anybody have experience with re-graph + authentication + Authorization header?

mruzekw22:10:06

Is there a good CLJS lib for creating a server?

mruzekw22:10:39

I know there’s Machiatto

nenadalm06:10:54

that's what I use. With reitit for routing.