Fork me on GitHub
#reagent
<
2020-03-09
>
Micah17:03:12

Does anyone know how I can remove a class name from and adapted react class?

(ns test.core
  (:require
   ["@material-ui/icons/Add" :default AddIcon]
   [reagent.core :as r]))

(def add-icon (r/adapt-react-class  AddIcon))
This will return an svg with a class of MuiSvgIcon-root as well as whatever other classes I have passed in. I would like to strip the MuiSvgIcon-root one out. Is there a way this can be achieved?

p-himik17:03:10

But it would disable such built-in classes globally. Another possible alternative - just pass your own root class.

juhoteperi17:03:59

Okay, yeah, The component will have some "root" class, but you can probably replace the built-in with your own class.

juhoteperi17:03:08

Maybe [add-icon {:classes {:root "your-own-root-class"}}

juhoteperi18:03:49

Point is, you can't modify the elements a component rendered, from the outside, but the component might provide API to control what it renders.

Micah18:03:05

Thank you @p-himik and @juhoteperi. I can use [add-icon {:classes {:root "your-own-root-class"}} but it still includes the original one as well. Too bad.

p-himik18:03:40

And you don't want to disable such classes globally?

Micah18:03:19

That would be okay. Just haven't seen how to do that yet.

p-himik18:03:41

I posted the link above.

Micah18:03:34

Oh I see, thank you. I am not actually using the Material UI. I was just trying to get the Icons easily packaged. And unless I am mistaken, that is using the MUI library.

p-himik18:03:22

You have it right there in your code example: "@material-ui/icons/Add".

p-himik18:03:21

To my best knowledge, using it will still require @material-ui/core/styles, which is exactly where createGenerateClassName is located. So you are using Material UI, at least the parts of it that matter to you.

Micah18:03:15

You are absolutely correct. I feel like an idiot. I was intending to use just the npm icons package. I tried out the full MUI early, but decided to dump it, but still wanted the icons. I appreciate your help.

p-himik18:03:56

No problem. :) Just in case - IIRC requiring everything from the icons package will add that code in the resulting JS bundle. No matter whether an icon is used or not. So if you're trying to create some namespace like mui-icons-cljs that has all the icons (even if each icon in its own namespace) - your users end up embedding the whole MUI Icons package into their app, even if they use just one icon.

p-himik18:03:31

To make sure that that's indeed the case, run https://shadow-cljs.github.io/docs/UsersGuide.html#_build_report on your release build.

Micah18:03:50

That is good to know. I am still trying to get my head around this stuff. There sure are whole lot of moving pieces :)

p-himik18:03:27

Yep. Fortunately, in the CLJS world they don't move too far away or as quickly as in the raw and barbarian JS world. :)

Micah18:03:06

That is something to be thankful for indeed!

juhoteperi18:03:42

I think having every icon in their own namespace should only include those icons whose namespace is required by the application. But I'm not super familiar on how Shadow-Cljs works with JS modules. This could also depend on built settings, dev build might include JS files for all icons, but optimization would remove unused ones.

Micah18:03:56

That would make sense. i will have to do more testing on this for sure.

p-himik18:03:38

Oh yeah, @juhoteperi you're right! I just did a build report and it doesn't contain every icon if I separate them by their own CLJS namespaces.

p-himik18:03:52

Ah, right, I remember now - you can do that but you cannot create one "master" namespace that combines every CLJS icon namespace under one roof. Even if those def's end up being unused, the :require's are still there, so the icons will end up in the JS bundle.