Clojurians Log v2
cljs-dev
ok @thheller point yesterday was really good concerning the type problem that cljs.host would introduce. i.e. cljs.host.String etc. would be strange, or if the type resolved to String even though it seemed to come from cljs.host.String
This has me feeling that pretending that there is a namespace is just not a good idea. All the options so far feel like complecting :require - now I'm wondering if we shouldn't just split the feature apart - i.e. :require-global
@borkdude also pointed out that global packages are always available in Clojure - it seems to me in ClojureScript they are not by design (otherwise js/ wouldn't be a thing).
@dnolen I agree, but I think having a single-segment special thing isn't bad. Since it's special and not something users would create. So personally I'd drop that column as a concern and still look at any of the other candidates, like (:require [js$crypto]) or (:require [global:crypto])
I mean compared to (:require-global) that seems reasonable?
Not strongly opposed to :require-global though
adding new parsing to :require really isn't that awesome and more likely to lead to regrets. :require-global is pretty conservative.
Would it look like
(ns foo (:require-global [console :refer [log]]))it would be more like :refer-clojure
(:require-global :refer [console] :rename {...})
and then console/log instead of js/console.log right
it's just global browser stuff, I don't know about needing nested access etc.
console/log unfortunately is a separate conversation, which I don't want to focus on at the moment there are conscerns there that @thheller raised.
(.log console ...) for now as before
(.log console) or (.log js/console) doesn't really make much of a difference tbh
What's the problem statement again? Perhaps good to add that to the Excel sheet :)
It's not about convenience anyways. And I'm not going to add that.
There's tons of obvious benefits - externs validation, renames, REPL support (docs etc.)
splitting it out into a separate thing that only implies a single global namespace (no qualifiers via $ or :) greatly simplifies the scope of the feature.
What JIRA issue is this again?
found it: https://clojure.atlassian.net/issues/CLJS-3233?jql=ORDER%20BY%20created%20DESC
I'm not totally against more generalized (:require-global [...]) but the scope of impact seems small? The examples in CLJS-3233 are neat, but to be honest not that common. People are loading most libraries from CLJS, GCL, or NPM - I would think in most cases anything that's global is really just that - global browser API stuff, not a nested lib structure.
one use case I do have in mind is the one developer just putting together a blog post with some interactive examples. You just drop some libs via script tags and you want to use ClojureScript with those libs.
I feel like most of these libs are lightweight and the simpler (:require-global ...) is sufficient
> one use case I do have in mind is the one developer just putting together a blog post with some interactive examples. You just drop some libs via script tags and you want to use ClojureScript with those libs. this is exactly how people use #scittle (CLJS interpreter that you include in a script tag + other libraries in script tags that are defined as globals, e.g. React) someone recently showed interest in having the CLJS-3233 feature in scittle to make working with that more convenient Here's the issue about that: https://github.com/babashka/scittle/issues/95
thanks will take a look
To summarize the issue: Before people always have to write something like this:
(js/React.whatever ...)(:require ["react" :as react])(:require [#?(:scittle "js$React" :cljs "react") :as react]):require-global would also work in this setting. Am I summarizing it right @chris358?
I guess this would be useful for normal CLJS in itself as well for letting people switch more easily between global and npm libs
seems like that could be easily fixed by scittle if it looked for some kind of config somewhere?
<script type="application/x-scittle-config">{:resolve {"react" {:global "React"}}}</script>Yep that’s an option too
Sorry for the slow reply (traveling). Yes, I think that's a good summary, thanks @borkdude. The fundamental use-case for me is being able to re-use code when using libraries in interpreted mode (Scittle or cljs with script tags pulling libraries in) and compiled mode (shadow-cljs with npm installed modules that get compiled in the usual way). I am using Scittle to quickly try out ideas and MVP things, and then later move to shadow-cljs to get smaller artifact with better performance once I know it's worth investing more dev time. To give a concrete example, it would be great to be able to pull in my https://github.com/chr15m/cljs-dopeloop/blob/main/src/dopeloop/render.cljs library into Scittle apps (currently only using it in shadow-cljs). What makes this tricky is these JS deps in the library, which makes it incompatible with Scittle:
["virtual-audio-graph" :refer [bufferSource gain] :as vag]
["virtual-audio-graph$default" :as createVirtualAudioGraph]
["wav-encoder" :as wav-encoder]js/ referencing.Looking at your reader conditionals above I now realize I can probably hack something to create aliases in scittle mode anyway, so maybe I'll give that a try, thanks.
Would it make sense to rely on something like :foreign-libs instead? Or maybe to extend :foreign-libs. So that the actual code is not conditioned upon where the functionality comes from.
if reagent have a :foreign-libs configuration
And I'm using reagent
clojurescript will be able to import :foreign-libs directly from reagent jar?
replicate the configuration in the project is not a good thing.
It shouldn't work that way - jars shouldn't dictate where an app's dependency comes from. Only what the dependency is.
scittle can't do the official method?
@nbtheduke What is the "official method"?
you said "while with official CLJS they can use ..." as if scittle can't do that
@nbtheduke What I meant is that there is no way to use js/React as globally defined from the ns form. That would benefit scittle as well.