This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-07
Channels
- # babashka (17)
- # beginners (33)
- # calva (9)
- # cider (2)
- # clj-kondo (17)
- # cljs-dev (2)
- # cljsrn (2)
- # clojars (3)
- # clojure (60)
- # clojure-australia (2)
- # clojure-europe (8)
- # clojure-gamedev (5)
- # clojurescript (27)
- # cursive (2)
- # emacs (9)
- # fulcro (8)
- # gratitude (5)
- # lsp (41)
- # malli (3)
- # meander (18)
- # pathom (5)
- # polylith (25)
- # re-frame (17)
- # reagent (1)
- # rewrite-clj (6)
- # shadow-cljs (11)
- # uncomplicate (5)
- # vim (6)
- # web-security (5)
Hi. What’s the benefit of using the goog library compared to those on npm? Is it because of some potential compiler optimization?
Recently published my reagent components library Space UI, which I use for Lightpad and some internal projects. Different from re-com. Would grateful for brutal critique. Thanks! https://github.com/spacegangster/space-ui
Namespaced keys. Yep This is what i would want from a component lib
It's it opinionated about css, meaning how you declare them vs how they are compliled?
Personally, i want to use clojure for managing the css data and then have it complied to classes. Which i think in react is the fastest solution, other then first load.
I asked about this topic in Reddit a while back https://www.reddit.com/r/css/comments/qf9gld/which_has_a_faster_time_to_paint_inline_styles_or/?utm_medium=android_app&utm_source=share
@U0DJ4T5U1 hmm, well, it provides its own classes for components and styling, there’s no option to override them for now
To add your own classes there’s no restriction there – whatever you pass down to :comp/css-class
will be added to component’s class property
@U0DJ4T5U1 it has space-ui.bem
namespace to compile BEM naming classes with modifiers
Does this help?
I’m using CSS in JS (Garden in CLJS) for Lightpad now, not looking towards outside compilation
RE: https://clojurians.slack.com/archives/C03S1L9DN/p1636213301423500
tl;dr: should requiring npm modules be like this?
I isolated the issue to the npm_deps.js
file produced by CLJS. What happens is that a CLJS require like this:
["@firebase/auth" :as auth]
Becomes
;; npm_deps.js
module.exports = {
npmDeps: {
"@firebase/auth": require('@firebase/auth'),
},
}
The require('@firebase/auth')
seems to be the issue as neither webpack or rollup understand how to resolve this by default. I can confirm everything is resolved correctly by manually modifying the npm_deps.js file so the require becomes require('firebase/auth')
.
Another solution, if you don’t want to manually modify the npm_deps.js file, is to write a custom webpack config with a manual resolve like this:
resolve: {
alias: {
'@firebase/app': path.resolve(__dirname, './node_modules/@firebase/app/'),
'@firebase/auth': path.resolve(__dirname, './node_modules/@firebase/auth/')
}
},
Does this seem like a “correct” solution or have I gone down some rabbit hole and made things difficult for myself 😆 If interested, here are some https://github.com/athomasoriginal/firebase-cljs. (branch “firebase-method-4" is the vanilla JS one and likely easiest to see the issue without the CLJS machinery).
Apologies for such a lengthy post, but I am sure this will stump others and hopefully this at least provides some direction.Also note that I did try just doing the following require in CLJS
["firebase/auth" :as auth]
But the above just results in the CLJS compiler yelling at me:
No such namespace: firebase/auth ...
webpack understands the npm_deps.js
format just fine. you absolutely do not need path.resolve
npm resolve works by taking what you require (eg. @firebase/auth
) and checking if a folder with a package.json of that name exists (eg. node_modules/@firebase/auth/package.json
)
firebase is one of those weird packages since there is a firebase/auth
and a @firebase/auth
. they are actual seperate packages and firebase/auth
basically is just redirecting the require to @firebase/auth
. don't let yourself get fooled by this
@U05224H0W I agree that I should not need to specify my own resolver, but as you noted: firebase is a weird package lol. If I don’t modify the resolver, the packages are not usable.
I have https://github.com/athomasoriginal/firebase-cljs and https://github.com/athomasoriginal/firebase-cljs/tree/firebase-method-4 demos which provide a minimal repro of the issues. At this point, I think I want to confirm whether there is any more room for exploration? :thinking_face: or is this the state of things for some npm modules?
If this is the case, it would seem that there are several solutions to this problem: • Prefer foreign-libs method if you need to use a weird package like firebase (if you want firebase to be the smallest it can be I believe this a requirement anyways) • Write a custom bundler config to help your bundler figure it out • Use a tool like shadow-cljs to help you out However, before I go about making recommendations, I want to make sure the above is correct. Firebase is a “popular” library which means it’s going to be a stumbling point for new CLJ/S devs.
I mean, another solution is having more control over the “module name”. For example, if I could tell CLJS I want require('firebae/*')
instead of require("@firebase/*")
the problem is also solved.
But I imagine the module-name suggestion is a non-starter haha
@firebase/auth
is definitely the correct require so it would help to figure out why it can't be imported. I took a look at your repro but can't figure it out either
Also, please let me know if maybe the above is better suited in #cljs-dev at this point. :thinking_face: