Hi I want to make a chrome extension and it would basically take a paragraph of text and add bounded boxen to different words. Anyone have any experience working on chrome/firefox extensions leveraging CLJS? Part of what stumps me is the fact that I could potentially use regex to figure out what's what, but the box-drawing has got to be pretty flexible... so imagine you have a sentence like "the elephant goes to school" .. I want to draw a box around "the elephant" and "to school." But I also want it to work on partial inputs / not crash because sentences are incomplete... so "the elephant goe" would get a box around "the elephant" and it could somehow wait for more useful input.

@borkdude just reiterating that the requires as string is not necessary

in ClojureScript we simply allow that in the cases where the import includes chars that cannot be in a symbol

$ is valid in symbols and the convention was taken from Clojure usage of inner classes

@dnolen yeah cool, I kind of knew that but in clj-kondo it's used as a way to differentiate between JS libs and clojure namespaces. I should probably rethink that.

Now that I've actually got more experience with this myself, I know where the problems are.

@borkdude right, so clj-kondo would be wrong here

there is no distinction between CLJS and JS libs using the string require format

yes, understood. it's not invalid to use strings only for JS libs though, and that's what people have been doing to satisfy the static analysis. I will see if there's a better solution though.

Hey, I’m looking for example how to use directly firebase (recent, ver. 9) from ClojureScript (shadow-cljs). I have problem with requiring of right functions directly (without using fancy wrapper). Do you have maybe working examples with using v9?

following the documentation https://firebase.google.com/docs/database/web/read-and-write?hl=en&authuser=0#web-version-9_1

import { getDatabase, ref, set } from "firebase/database";

const db = getDatabase();
set(ref(db, 'users/' + userId), {
  username: name,
  email: email,
  profile_picture : imageUrl
})
.then(() => {
  // Data saved successfully!
})
.catch((error) => {
  // The write failed...
});

(ns some.fb.db
  (:require ["firebase/database" :refer [getDatabase]])

I’m able to initialize firebase via:

(ns giggin.fb.init
  (:require ["firebase/app" :as firebase]))

(defn firebase-init
  []
  (firebase/initializeApp {...}) 

Ok, time to try and use some Specter in this clojurescript project.. How do I properly add it to the project? So far I've only added node modules (using shadow-cljs)

also is there a convention for naming the import since using s as the documentation suggests seems to collide with accepted practice for spec.

@rdonahue there is no convention, and using s for spec is not a convention - you can do whatever you like

it's the whole point of ns aliases - you're free to pick names best suited to your project

@rdonahue as to adding stuff to Clojure projects it depends largely on the tool - I think shadow has it's own way of doing it

Continuing on the cljs vs js lib "namespace", are there any heuristics that can be applied whether to detect a cljs namespace vs js lib, beyond just trying to load the js lib, catch and then try the cljs lib? can also first check the classpath for the cljs lib and then try the js lib This is more a question about how CLJS itself implements it. I can also just go read the source.

@borkdude note that there are significant differences here between what ClojureScript does and what shadow-cljs does

but what ClojureScript does is index node-modules

there is no other way detect whether a library is one or the other

right, because CLJS is a compiler and you can't just try something at runtime

(unless you generate that code but that gets messy)

this was true always

long before node_modules

we indexed Closure Library - you can requires a Closure Library just like a normal CLJ namespace

nothing to distinguish one kind of require from the other

right. in nbb I have the luxury that I can use resolve (on a require created with createRequire) to lookup the JS source first. I just wonder if that would be correct: JS and if that fails, then try CLJS, in that order.

I guess a conflict is really rare

pretty sure that's not the order we use

I think it's something like

CLJS, node_modules, Google Closure, classpath JS

classpath JS, I can't remember I've ever used that

for the case where you're writing Google Closure JS

transit-js works this way

again the whole point of the ClojureScript design is "who cares where this stuff comes from?"

it's just some namespace with something you want to use

it's also why we ended up with $

because all this ESM stuff is nothing we care about

all JavaScript libraries are simply nested objects

and we've supported using that pattern since day 1 - that's how Closure works

yes, it makes sense, I just have never used it myself, but I can imagine that there's a use case for it (like you've mentioned). this is helpful, thanks

does the async ESM stuff complicate stuff for CLJS or is it just a matter of setting the right JS language target and it generates import stuff?

we simply don't support dynamic require

I mean, e.g. CLJS on deno, loading "namespaces" from web resources

what I'm saying is we don't support this thing at all - and are probably unlikely too

unless Closure does

it's my opinion that all the JS changes over the years has a net negative

and the more stuff happens the more likely we're not going to do anything about it

this is the strategy around :bundle

somebody else's problem chasing low-value stuff

yeah. right now CLJS uses google closure's way of bundling and loading modules, which is distinct from async import. you can use async import to get external JS to load, but that isn't something that involves the compiler in any way. you would just call (js/import ,,,) or whatever

exactly it's not our intention to make things impossible

but my experience w/ interop heavy stuff in Clojure & ClojureScript is it's a losing game

in that some things are better written in Java and JavaScript (rather than adding features to achieve parity which is always a moving target)

maybe CLJS can add its own module standard to the mix 😆

(not serious)

do you still think Closure was (and is) a good decision?

it's still state of the art far as I can tell

my primary complaint - though it's somewhat of our creation is that Closure doesn't follow a Hickey-esque approach to development

removals, renaming, signature changes you name it

I think in the old days Closure development was slower because they were a lot of consumers of the APIs

but I think we're probably the biggest one now by far

it's also hard to go back in time to 8 (?) years ago and think to pick any other solution

but more importantly ESM is not a good answer

it really was the best at the time, and any solution built on top of other existing tech back would have seen at least as much churn and discrepancies with current bleeding edge tech

Google Closure namespaces are effectively late bound environments

this is what lets the REPL work w/o Clojure Var stuff

all the Dead Code Elimination stuff works around ESM modules from what I can tell

anyways, I don't think the calculus has changed at all

because JS people don't have proper live programming and they're never going to

yeah ESM essentially cemented the status quo a lot of other bundlers set w/ using closures as modules rather than object namespaces

that requires reloading the entire app from the root when any dependency changes

not saying that Racket is bad - but that where ESM comes from, people that worked on Racket

One of the very best ideas that Rich Hickey had (among all the others) is form-at-time compile

and avoiding modules as compilation unit

interesting, didn't know the Racket lineage there

I guess module-at-time compilation makes some mechanical sense, since pragmas set at the beginning of a module can radically change the way compilation is done. is that how most schemes work?

Smalltalk didn't work that way, Lisp didn't work that way

then you had Self - which continued Smalltalk

StrongTalk / Self laid the foundation for proving you could optimize all kinds of wild thing at runtime

whereas previously people believed you had to do this whole program optimization up front

Clojure whole idea was that you have runtime optimizing compiler and fast GC - so just focus on the stuff that matters

ClojureScript was created right at the time that was becoming true for JavaScript - and the design is based on the same principles

Is there a canonical way to tell at runtime whether you're in the browser or in node?

Basically, I need to figure out whether to use goog.net.XhrIo or node's http lib for making a request.

I think typical practice is to check for either window or process