Clojurians Log v2

I'm referring to the use of macros like defstyled. I'm looking for something that will fit in nicely with the hiccup in Reagent.

It works really well with reagent: https://dvingo.github.io/cljs-emotion/#!/dv.cljs_emotion.reagent_cards see the last card on that page for an example that doesn't use defstyled

I have a ISO timestamp string like so 2021-03-20T07:00:58.000Z

What’s the most convenient and least error prone way to convert it into a date and a time according to a specific timezone?

in a format like so: March 3, 2021 6 pm

@ps https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat should have all that

@henryw374 the link has the following but I don’t know how to convert it into cljs:

new Intl.DateTimeFormat().format(date)

I tried this:

(.format (.DateTimeFormat (js/Intl.) "en-US") date)

but it’s giving Intl is not a constructor

(-> (js/Intl.DateTimeFormat. "en-AU" #js{:weekday "long"})
    (.format (js/Date.)))

cljs.user=> (.format (js/Intl.DateTimeFormat. "en-US")) "3/5/2021" cljs.user=> (-> (js/Intl.DateTimeFormat. "en-US") (.format (js/Date.))) "3/5/2021" cljs.user=>

if you're not at a repl already... it's a great way to work out interop syntax ... and do everything else 😉 online one http://app.klipse.tech/

As an aside, I notice that “en-GB” in the above still gives me 3/5/2021, not 5/3/2021 which I’d expect. The plain Javascript looks good: > new Intl.DateTimeFormat('en-US').format(new Date()) '3/5/2021' > new Intl.DateTimeFormat('en-GB').format(new Date()) '05/03/2021'

(-> (js/Intl.DateTimeFormat. "en-GB")
    (.format (js/Date.)))

I believe the dot after DateTimeFormat is optional (but not after (js/Date.)

the . invokes it with newhttps://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/new, . not sure if that makes a diff in the case of this fn but the docs all show it being invoked with new so I'd stick with that

Hm, yes. Good point.

btw @ps if you're doing much work with dates, including formatting, I would recommend https://github.com/juxt/tick (which I maintain). atm it's quite a lot of code though, so not everyone's cup of tea . see https://github.com/juxt/tick/blob/master/docs/cljs.adoc#optional-timezone--locale-data-for-reducing-build-size

After I posted, I started to wonder whether it was because for the CLJS I used a bespoke Node that’s bundled with another application (where for the plain JS test it was the standard Node). I’m going to guess that’s the issue and will investigate.

For me the biggest stumbling block was dealing with the extra dependencies from ClojureScript (apart from the recent issue I reported I actually tried using tick a few months ago but gave up at the time because I couldn’t make it work in ClojureScript, and for me the Clojure + ClojureScript code re-use is one of the biggest wins of any library that is heavily used across both languages)

Do you think there’s a way to bundle the extra dependencies as part of deps.edn somehow? Perhaps that’s similar to how ClojureScript bundles the google-closure compiler (if I’m not mistaken) : https://mvnrepository.com/artifact/org.clojure/google-closure-library

it does include those extra dependencies as foreign libs already. so you don't need to bring in the npm deps. but since you are using npm anyway, I'd expect you'd prefer to get them via that route

Oh it does? So the npm/yarn step is not necessary?

no, not if the only thing coming from npm was tick deps.

btw shadow would ignore the foreign-libs and do the npm step for you

(not using shadow)

I see that they are included under Dependencies, cool https://clojars.org/tick

but e.g. if you use reagent as well, then you would already do that npm step, and that would pull in tick npm deps as well

in another world, clojurescript deps might be less complicated 🙂

Hmm… ok (not using reagent)

So you’re saying that any use of yarn/npm would pull the juxt/tick dependencies into package.json ?

Or just the use through ClojureScript tools/methods like :

clj -m cljs.main --deps-cmd "yarn" --install-deps

yes, just through that. npm on it's own would not

Right… ok.

I generally don’t use any of the clojurescript means, just use: yarn add yarn install etc directly

So you’re saying that if I remove all juxt/tick dependencies from package.json, the library should still work (in theory)

and for non-shadow build, if you do use --`install-deps` , then you need to exclude the foreign-libs, otherwise you'll end up with 2 lots of them in your build, which is definitely not small

Ah, good point… so why wouldn’t I just stick with the foreign-libs? (for my case, given that I avoid most other ClojureScript+npm/yarn tooling combos)

in your case foreign libs sounds fine

Cool, I might give it a try 🙂 Thank you for the input! That was very helpful.

:thumbsup:

Yup, seems to be the case. Sorry for the noise.

👍

Actually, now I recall trying the foreign-libs route some months ago. Is the foreign-libs route expected to work with :advanced ? (I think that was the stumbling block I hit back then)

Yes that works

The tests are done with advanced. And all my work builds use advanced with foreign libs

Great! Awesome. Will give it a shot later.

I have the following where iso is the iso string coming from a database.

(defn get-local-date [iso]
  (js/console.log "iso is " iso " " (= iso ""))
  (if (and iso (not= iso ""))
    (let [date (js/Date. iso)]
      (js/console.log "date is!!! " date)
      (->
       (js/Intl.DateTimeFormat "en-US"
                               #js {:dateStyle "full" :timeStyle "long"})
       (.format date)))
    ""))

(get-local-date iso-string)

3/20/2021

you are missing a .. js/Intl.DateTimeFormat. not js/Intl.DateTimeFormat. its a constructor called with new in JS.