Can anyone recommend canonical examples of how common DOM types (eg NamedNodeMap, HTMLCollection, NodeList, etc...) can/should implement CLJS protocols? I found pangloss/synergize (https://github.com/pangloss/synergize/blob/master/src/synergize/browser.cljs#L69) and clojure.data.xml (https://github.com/clojure/data.xml/blob/master/src/main/clojure/clojure/data/xml/js/dom.cljs#L172), but wanted to see if there's a set of impls commonly accepted by the community. P.S. I'm aware of the discussions online regarding why these aren't part of CLJS core, and why one shouldn't extend native/platform types in a library. My use case is an application.

@robert.mather.rmm it isn't a great idea to make the DOM list types look like clojure datastructures (ie. protocols) since they are mutable underneath

one easy way of working with them is (array-seq html-coll-or-node-list) (but they are still mutable underneath, so depending on what you are doing might be a good idea to (vec (array-seq ...))

what is a thing called that you can :import in CLJS? as class? object? thing?

I can't find any docs on this on the CLJS site

class is closest I guess

technically it just aliases a name. that name could resolve to anything

@borkdude :import exists primarily for the annoying case where a goog ctor is the same as the namespace itself

I was fixing a false positive in clj-kondo (a clojure linter) because people seem to be using it like this:

(ns foo (:import [goog.date UtcDateTime]))
(defn utc [x] (UtcDateTime.fromTimestamp x))

is UtcDateTime a class? I don't know if this is even a concept in JS (outside ES6, TS, etc.), hence my question

they seem to be calling it like that over here: https://google.github.io/closure-library/api/goog.date.UtcDateTime.html

that's idiomatic

goog.date.UtcDateTime is a library and a ctor

UtcDateTime is a class with static methods

ok, but that doesn't matter so much - :require won't let you do what you want

that's informative, thanks

the point is that the thing you want to use and the namespace are the same

(:import [foo.bar Baz]) lets you require a namespace called foo.bar.Baz & use Baz as if referred

according to the issuer you can also:

(:require [goog.date.UtcDateTime :as udt])
udt/fromTimestamp

right

sorry if it's a class with only static methods and you don't need to use it as a ctor

then :require is fine

IMHO it should probably be (defn utc [x] (UtcDateTime/fromTimestamp x)). that is how clojure accesses static class methods

but I don't think that works currently in CLJS

right

well that used to work years ago but we disallowed that to remove ambiguities about namespaces

if we can know that UtcDateTime is a class then we could recover that

but this was before externs parsing

yeah its a bit messy since closure "provides" don't actually always describe namespaces

so we couldn't - now we could I suppose?

yeah

dunno I would prefer allowing calling the actual :as alias as a function. like we have for other JS

@constructor is present in UtcDateTime case

makes many issues go away

(:require [goog.string.format :as format]) (format ...)

so we could support static method pattern w/ this information

(:require [goog.date.UtcDateTime :as udt]) (udt/fromTimestamp ...) (udt. ...)

From a linter/tooling perspective it would be nice if UtcDateTime/... could be restored

:as can be strict and not callable for CLJS, but ok for JS

and be as close to the JVM Clojure syntax as possible

@thheller right, still kind of meh about doing that though - though to be fair we already have invokeable nses for JS modules

so would be easy to extend that to Closure nses

yeah, it isn't great but can't think of anything cleaner

@borkdude sure - I'm ok w/ supporting / again for known classes

doesn't seem like particularly hard ticket

yeah externs parsing returns :ctor

code might need some minor tweaks to support - but I think it's 95% of the way there

:ctor means it's a class?

annotated with @constructor in the JS

what if you only have static functions and no constructor?

then you can just use the thing as a namespace

er correction just what I said above

so only static functions and no constructor is a namespace

so this would only be supported for a limited set of classes baked into the compiler?

hmm?

only static functions and no constructor always works

I mean, the class inference

if you mean only Closure style JS (possibily ES6) yes

i.e. foreign libs are out

Rephrased: CLJS has to know if some import is a class. How can it know from arbitrary libraries.

hrm

I guess it should always work for :import since no ambiguity

so that would work for foreign

ah I see, you were referring to the :require case

yes

:require some lib and if you :refer a known ctor then Foo/static should work

:import some lib then Foo/static works no checking

:refer (Foo) and Foo/static? that shouldn't work?

that should work if you know Foo is ctor

like I said I'd like to see cases in Closure where you have static methods on a Foo where you don't have constructor

that is foo.bar.Foo if that's just a namespace and not a constructor seems to break the convention I've seen

hmm I kind disagree

like I said I don't want to go back to the old thing

(:require [foo.bar :refer (Foo)]) is problematic because the mapping isn't 1:1 and could be defined in foo/bar.js or foo/bar/foo.js

I mean I don't want to just interpret / as always working

I would say / is for namespace aliases only, . for everything else

except for imports

like in Clojure

probably should move this convo into #cljs-dev 🙂

So I followed the code splitting guide and have a clojurescript application built that properly code splits and I can load things dynamically using cljs-loader. That all works great. Now I’d like to take those same code split modules (my home page, my about page, etc) and have node server where I require those modules and server side render them. Sadly, that does not seem to work because when I try to require [mysite.about] it tries to require cljs.loader which does not exist in the node environment. Is there are way around this or a better way to accomplish the same goal? Does anyone have a setup like this working?

I don't think anybody's asked for what you're trying to do

I think the issue w/ trying to use the loader in Node.js is that we're just using the Google Closure thing - so I doubt that would work under node - definitely meant for the browser

that said I don't really see why you need to bother w/ all this if you just want to server side render

just don't use the code split version of your code base - it does means you need to compile twice

I’m not actually trying to use the loader directly. The problem I’m running into is that, from my understanding, any modules I want to code split, I need to add the loader/set-loaded! call to. So if I have a simple about page like this:

(ns my-site.about
  (:require [cljs.loader :as loader]))

(defn main []
  [:div [:h1 "About"]])

(loader/set-loaded! :about)

(Just for context, I’m basically trying to make a nextjs like framework in clojurescript)

right so you just have to think differently about the loader code

instead of putting it directly in, you make a thing which is just for the loader bit

i.e. a ns called my-site.about.loader

which refers to loader directly

but my-site.about does not

you can load my-site.about into Node.js then w/o issue

@jimmy ^

@dnolen Makes sense. Thanks!

Hi

I’m trying to interact with WASM from ClojureScript

On https://emscripten.org/docs/api_reference/module.html it’s explained to create a Module object that overrides print and printerr

How do we do this in ClojureScript?

(defprotocol Module
  (^:export print [this tex] ...)
  (^:export printErr [this text] ...))

One approach would be to create a JavaScript object from cljs named Module, that has a method print and printErr The question is: how can I overwrite print so I can access the stdout of the webassembly package in clojurescript and do something with it?

@erwinrooijakkers you can just make an JS object just like the example shows

(js-obj "print" ...) or #js {:print ...}

has anyone ever done a write up comparing hiccup and factory functions? esp. when using React

I think Om (Next) used factory functions primarily. any lessons learned from that?