clojurescript 2022-03-13

Richard Bowen01:03:39

Hey, I'd like to target the :last-child selector via makeStyles to override the padding of a mui component. Any idea how do to it? Here's what I did which doesn't work:

(def usCustomStyles
  (makeStyles
   #js{:card-content
       #js{:padding "24px 40px 40px 40px"
           "&:last-child" {:padding-bottom "40px"}}}))

Sam Ritchie02:03:59

Wild guess since I don't know the problem domain, but could it be a missing #js in the most nested map?

Richard Bowen03:03:29

Let me try that.

Richard Bowen03:03:59

That worked. Thanks.

👍 1

Richard Bowen04:03:34

Trying to use map-indexed to generate some markup. The code looks like it should work but I don't see why it doesn't:

(def image-list ["image1.png" "image2.png" "image3.png"])

(def image-grid []
  [image-list {:cols 4 :row-height 120 :gap 0}
    (map-indexed (fn [index item]
                        [image-list-item {:key index :cols 1}
                         [:img {:src (:img item)}]])
                      image-list))

Richard Bowen04:03:15

I see why.

eccentric J17:03:32

What do you reach for if you want a custom keyword function when performing js->clj?

p-himik18:03:11

I write my own - it's just a few lines of code, not worth a dependency.

eccentric J21:03:02

Using nbb which fortunately had cljs-bean built in already and the bean function accepted a keyword function

eccentric J21:03:15

Did try copying the js->clj function but not sure those base protocols like IClojureEncode and the Map related one it uses are exposed through nbb. Plus cljs-bean is noticeably faster

p-himik21:03:29

If cljs-bean works for you then good. > not sure those base protocols like IClojureEncode and the Map related one it uses are exposed through nbb But do you need those protocols? And if you do, does cljs-bean support them?

eccentric J21:03:25

I'm not really sure if they're needed or not, it's possible they were not needed. cljs-bean works in a different way https://github.com/mfikes/cljs-bean

p-himik21:03:27

Right, I know. I'm just pointing out that you probably don't need those protocols that js->clj handles. If you work with plain old JS object aka JSON data then this is all you need:

(defn my-js->clj [v key-fn]
  (cond
    (object? v) (into {}
                      (map (fn [[k v]]
                             [(key-fn k) (my-js->clj v key-fn)]))
                      (js/Object.entries v))
    (array? v) (mapv #(my-js->clj % key-fn) v)
    :else v))

p-himik21:03:33

As a less obvious alternative, it's very often the case that any sort of JS->CLJS conversion is completely unnecessary. There is still interop, and JS arrays are seqable - you can see in the code above that mapv and into do work on them with no issues, and even that [k v] destructuring works.

eccentric J22:03:19

That makes sense

eccentric J02:03:02

Might end up going with something like the above solution, ran into a strange behavior that I don't think is intentional. https://github.com/mfikes/cljs-bean/issues/89

p-himik08:03:19

I left a comment there. But even if you fix the behavior by introducing ad-hoc code for UID, I still wouldn't use cljs-bean here and instead would prefer regular interop unless there's a good reason not to. That get-in then becomes (.. ^js data -properties -UID -formula -string). Although you mention spaces in field names, and those do bring the need for goog.object.

eccentric J11:03:13

True it only took a few seconds to get the regular interop working with that solution vs the bean approach seems like I'd be spending more time trying to create the counterpart to turn the key back into a prop and likely hit more bumps along the way

2022-03-13

Channels