Fork me on GitHub
#clojurescript
<
2021-11-07
>
pinkfrog02:11:35

Hi. What’s the benefit of using the goog library compared to those on npm? Is it because of some potential compiler optimization?

lilactown04:11:21

they're already included, very stable, and can be better optimized sometimes yes

Ivan Fedorov18:11:01

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

Drew Verlee20:11:37

Maps first? Css grid first? Awesome.

❤️ 1
Drew Verlee20:11:12

Namespaced keys. Yep This is what i would want from a component lib

Drew Verlee20:11:42

It's it opinionated about css, meaning how you declare them vs how they are compliled?

Drew Verlee20:11:18

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.

Ivan Fedorov08:11:55

@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

Ivan Fedorov08:11:24

@U0DJ4T5U1 it has space-ui.bem namespace to compile BEM naming classes with modifiers

Ivan Fedorov08:11:38

Does this help?

Ivan Fedorov08:11:27

I’m using CSS in JS (Garden in CLJS) for Lightpad now, not looking towards outside compilation

athomasoriginal23:11:35

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.

athomasoriginal23:11:37

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 ...

thheller06:11:00

webpack understands the npm_deps.js format just fine. you absolutely do not need path.resolve

thheller06:11:12

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)

thheller06:11:32

it then follows whatever is in there (or the index.js if no package.json exists)

thheller06:11:53

so your path.resolve basically just does what it would do by default anyways

thheller06:11:17

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

athomasoriginal13:11:01

@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.

athomasoriginal13:11:53

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?

athomasoriginal13:11:25

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.

athomasoriginal13:11:27

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.

athomasoriginal13:11:50

But I imagine the module-name suggestion is a non-starter haha

thheller19:11:08

@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

🙏 1
thheller19:11:26

appears to be loading the correct files but something must be different

athomasoriginal23:11:07

Also, please let me know if maybe the above is better suited in #cljs-dev at this point. :thinking_face: