Fork me on GitHub
#clojurescript
<
2022-05-25
>
pinkfrog13:05:22

Hi. How can I call a js function whose name is a string. For example, given s = "foobar", I want to call the method “foobar” on some object. Note that, I only know the string s.

p-himik13:05:15

(let [f (.bind (gobj/get obj s) obj)]
  (f))

👆 1
pinkfrog13:05:11

Good to know.

sansarip13:05:46

If you’re ok with pulling in an extra dependency, you can also use https://github.com/binaryage/cljs-oops for things like this e.g.

(ocall+ obj s)

pinkfrog14:05:15

@U04V15CAJ fyi, I was working on this.

borkdude14:05:11

@UGC0NEP4Y this should be supported in nbb.

borkdude14:05:20

you can also use (js/Reflect.apply (gobj/get obj s) obj (into-array []))

pinkfrog14:05:04

Yes. gobj is there.

borkdude14:05:58

user=> (require '[goog.object :as gobj]) (let [obj #js {"dude" (fn [& args] :hello)}] (js/Reflect.apply (gobj/get obj "dude") obj (into-array [])))
nil
user=> :hello 

pinkfrog14:05:02

I directly use (.apply fun args) dunno what’s the difference

borkdude14:05:32

That also works, if the function is unrelated to the object

borkdude14:05:48

But sometimes this matters...

👆 1
jpmonettas14:05:06

hi! how can I get the current repl-env at macroexpansion time? Looking at https://github.com/clojure/clojurescript/blob/r1.11.54/src/main/clojure/cljs/repl.cljc#L1578 it is getting it from &env but when I try it, it doesn't contain :repl-env key. What I'm trying to do is to eval some forms at macroexpansion time.

pinkfrog15:05:23

What’s the way to achieve the functionality of intern in clojurescript?

thheller15:05:21

CLJS doesn't have vars at runtime so its not supported. you can achieve more or less the same just manipulating JS objects though.

pinkfrog00:05:55

Something like this?

(set! *ns*.a 4)
Invalid for the above though.

thheller06:05:49

namespaces and vars do not exist in any meaningful way after :advanced optimizations. *ns* does not exist either outside macro evaluation or the REPL.

thheller06:05:08

whatever you are trying to do you are better off not doing it with namespaces and instead your own object system

pinkfrog08:05:42

What I want to do is to create a variable in the current namespace, like a dynamic version of (def foobar 42), or to say (intern ns ’foobar 42) exactly. Understand there is some difference in cljs on how ns and var works. Yet, is my case doable?

pinkfrog08:05:38

@U2FRKM4TW This is my original question.

p-himik08:05:36

> to create a variable in the current namespace For what?

pinkfrog08:05:58

Exactly speaking, not in the current namespace. For example, say I have a function util/func, inside the function, I’d like to create a var in whatever namespace that invokes the util/func. It might be foo/func invokes util/func, then util/func shall intern a var in foo.

p-himik08:05:06

Yeah, but for what?

p-himik08:05:28

I'm trying to get to the X in the XY problem.

pinkfrog08:05:23

I develop with repl. The above code is not for production, just to make repl dev easier. The use case is, when I evaluate foo/func, then I can get a var say *f that contains some result of the evaulation.

p-himik08:05:23

I'm 80% certain that's not possible. And I'm 95% certain that even if it is possible, doing that wouldn't be worth it as you'd end up relying on some undocumented internals that can easily change in the next minor CLJS version. If I were you, I'd stick some registry into the user namespace, use tap> when I need some value be put in that registry, and add a tap that puts tapped values into that registry. Then, whenever you need some value, you'd use user/stuff in your REPL, which would be available from anywhere, without any need to (require 'user).

p-himik09:05:08

And, just in case you haven't tried it yet, I'd definitely recommend trying that with https://github.com/djblue/portal. Not only you can see all the values that you've ever tapped, you can also send them back to your REPL.

pinkfrog09:05:50

That’s the thing I am doing.

dnolen16:05:55

@jpmonettas it's very impractical to try to evaluate ClojureScript at macroexpansion time

jpmonettas18:05:31

yeah, the thing is that I'm porting flowstorm debugger (https://github.com/jpmonettas/flow-storm-debugger/) to Clojurescript, and I'm researching a way of instrumenting entire namespaces. So it is basically for interesting loaded namespaces, for every ns-interns, get the source form, instrument it (for tracing its execution) and then evaluate the instrumented one to replace the original

jpmonettas18:05:30

maybe there is another way of accomplishing the same :thinking_face: , that is the way I'm doing it in Clojure

ccann19:05:42

can anyone tell me what ^:once does? the context is an Om.Next app with (defui ^:once MyComponent ...)

p-himik20:05:23

It's just metadata - nothing special about it. Om.Next itself handles it here: https://github.com/omcljs/om/blob/3a1fbe9c0e282646fc58550139b491ff9869f96d/src/main/om/next.cljc#L423

Andrew Carlile19:05:35

Greetings wizards and warlocks, I'm having a proverbial aneurysm trying to upgrade a legacy app to reagent-mui 5. I've gotten most of the kinks worked out (so far) but I can't get spacing to work. The app compiles without error and the page renders mostly fine, except the layout has been thrown all out of whack. I did update the logic for pulling the spacing fn out of the theme, but it doesn't appear to have any affect on layout. could you spare some thoughts on anything that might have changed? I'm following the example project at https://github.com/arttuka/reagent-material-ui/blob/master/example/src/example/core.cljs as closely as I can detect. I'm also running into a real blocker with figwheel: normally, 'lein fig' results in a repl connection; mine does not; fig hot-reloading is kaputt. If I update cljs to 1.11.54, compilation crashes with an error related to 'RhinoErrorReporter' which my firm does not use and about which I find painfully little on google. Where is this coming from and how might I fix it? finally, when trying to use reagent-mui.x.data-grid, compilation breaks with an error related to npm deps in reagent-mui. curiously, my stack-trace points to an @ symbol in a docstring. How can I include the necessary deps in my project to get data-grid off the ground?

p-himik20:05:47

> with an error related It would be helpful to actually have those errors here.

Andrew Carlile20:05:24

here’s the Rhino-related error message as a result of tryingto upgrade to 1.11.54:

lein fig
Execution error (NoSuchMethodError) at com.google.javascript.jscomp.RhinoErrorReporter/<clinit> (RhinoErrorReporter.java:169).
com.google.common.collect.ImmutableMap$Builder.buildOrThrow()Lcom/google/common/collect/ImmutableMap;

Full report at:
/var/folders/20/pn1s4g7d3yv6vq7460j50vj482tm74/T/clojure-15695970514389633136.edn

p-himik20:05:36

What are your dependencies?

Andrew Carlile20:05:29

here’s the error I get when trying to use reagent-mui.x.data-grid:

lein fig
[Figwheel] Validating figwheel-main.edn
[Figwheel] figwheel-main.edn is valid \(ツ)/
[Figwheel] Compiling build dev to "target/public/cljs/main.js"
	[Figwheel] Failed to compile build dev in 9.637 seconds.
[Figwheel:WARNING] Compile Exception   target/public/cljs/dev/reagent_mui/x/data_grid.cljs   line:2  column:12

  No such namespace: @mui/x-data-grid, could not locate _CIRCA_mui_SLASH_x_data_grid.cljs, _CIRCA_mui_SLASH_x_data_grid.cljc, or JavaScript source providing "@mui/x-data-grid" (Please check that namespaces with dashes use underscores in the ClojureScript file name) in file target/public/cljs/dev/reagent_mui/x/data_grid.cljs

  1  (ns reagent-mui.x.data-grid
  2    "Imports @mui/x-data-grid as a Reagent component.
                ^---
  3     Original documentation is at  ."
  4    (:require-macros [reagent-mui.util :refer [with-unchanged-js-props]])
  5    (:require [reagent-mui.util :refer [adapt-react-class]]
  6              ["@mui/x-data-grid" :as MuiDataGrid]))

Andrew Carlile20:05:39

here’s my dependencies:

:dependencies [[org.clojure/clojure "1.11.1"]

                 ; HTTP Server + Handling
                 [metosin/reitit "0.5.5" :exclusions [org.clojure/spec.alpha]]
                 [metosin/ring-http-response "0.9.1" :exclusions [ring/ring-core]]
                 [metosin/muuntaja "0.6.7"]
                 [ring/ring-jetty-adapter "1.8.1"]
                 [org.clojure/tools.reader "1.3.3"]
                 [hiccup "1.0.5"]

                 ; METRICS / MONITORING
                 [yleisradio/new-reliquary "1.1.0"]         ; API To NewRelic

                 [org.clojure/core.async "1.3.610"]

                 ; Configuration
                 [environ]]
here’s my :plugins
:plugins [[lein-environ "1.2.0" :hooks true]
            [s3-wagon-private "1.3.4"]
            [lein-parent "0.3.8"]
            [lein-npm "0.6.2"]
            [lein-cljsbuild "1.1.8"]]
here’s profiles >:cljs
:cljs    {:source-paths ["src/cljs"]
                       :dependencies [[org.clojure/clojurescript "1.11.4"]
                                      [arttuka/reagent-material-ui "5.6.2-1"]
                                       ;:exclusions [arttuka/reagent-material-ui-js]]
                                      [reagent "1.1.1"]
                                      [cljsjs/react "17.0.2-0"]
                                      [cljsjs/react-dom "17.0.2-0"]
                                      [re-frame "1.3.0-rc3"]
                                      [metosin/reitit-frontend "0.5.18"]
                                      [cljs-http "0.1.46"]
                                      [cljsjs/auth0-lock "11.16.2-0"]]}

Andrew Carlile20:05:20

and profiles > dev

:dev     [:cljs
                       {:dependencies   [[com.bhauman/figwheel-main "0.2.18" :exclusions [clj-time joda-time]]
                                         [com.bhauman/rebel-readline-cljs "0.1.4"]]
                        :resource-paths ["target"]
                        :clean-targets  ^{:protect false} ["target"]}]

p-himik20:05:00

Nothing really catches the eye there. But if you ask Lein for a full dependency tree, does anything depend on the Closure compiler apart from the CLJS dep itself?

Andrew Carlile20:05:46

this is the only time closure appears in the results of running lein deps :tree

[org.clojure/clojurescript "1.11.4"]
   [com.google.javascript/closure-compiler-unshaded "v20210808"]
   [org.clojure/google-closure-library "0.0-20211011-0726fdeb"]
     [org.clojure/google-closure-library-third-party "0.0-20211011-0726fdeb"]
 [org.clojure/core.async "1.3.610"]

Andrew Carlile20:05:57

so I’m gonna guess “no”?

Andrew Carlile20:05:54

I would want to add these deps to an exclusions vector, right? like this?

:dependencies [[org.clojure/clojurescript "1.11.54"
                                       :exclusions [com.google.javascript/closure-compiler-unshaded "v20210808"
                                                    org.clojure/google-closure-library "0.0-20211011-0726fdeb"
                                                    org.clojure/google-closure-library-third-party "0.0-20211011-0726fdeb"]]
                                      [arttuka/reagent-material-ui "5.6.2-1"]

p-himik20:05:21

No, you don't want to exclude them - they are needed. Weird that you get that error though, especially given that both of the conflicting classes are in the same jar. Sorry, can't help further here - I myself have stopped using Lein and all related stuff a long time ago. Regarding your second error though - seems like you should install @mui/x-data-grid via NPM.

Andrew Carlile20:05:43

thanks! that stepped us over the @mui/x-data-grid error, only so that one relating to @mui/styles appears… am I going to have to do this for every node package mui depends on? sounds antipatternish. not to mention it blows up:

npm install @mui/styles
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR! 
npm ERR! While resolving: undefined@undefined
npm ERR! Found: [email protected]
npm ERR! node_modules/react
npm ERR!   peer react@"^17.0.0 || ^18.0.0" from @mui/[email protected]
npm ERR!   node_modules/@mui/base
npm ERR!     @mui/base@"5.0.0-alpha.82" from @mui/[email protected]
npm ERR!     node_modules/@mui/material
npm ERR!       peer @mui/material@"^5.2.8" from @mui/[email protected]
npm ERR!       node_modules/@mui/x-data-grid
npm ERR!         @mui/x-data-grid@"^5.11.1" from the root project
npm ERR!   peer react@"^17.0.0 || ^18.0.0" from @mui/[email protected]
npm ERR!   node_modules/@mui/material
npm ERR!     peer @mui/material@"^5.2.8" from @mui/[email protected]
npm ERR!     node_modules/@mui/x-data-grid
npm ERR!       @mui/x-data-grid@"^5.11.1" from the root project
npm ERR!   7 more (@mui/private-theming, @mui/styled-engine, @mui/system, ...)
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! @mui/styles@"*" from the root project
npm ERR! 
npm ERR! Conflicting peer dependency: [email protected]
npm ERR! node_modules/react
npm ERR!   peer react@"^17.0.0" from @mui/[email protected]
npm ERR!   node_modules/@mui/styles
npm ERR!     @mui/styles@"*" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

p-himik20:05:52

> am I going to have to do this for every node package mui depends on? Only for the ones you're actually using. Somewhere, you required reagent-mui.x.data-grid - so, that's why you need that NPM package I mentioned. Same with @mui/styles. Why it blows up, though... well, the package itself is kinda broken - its siblings require React either 17 or 18, you have 18 installed, but the styles package for some reason doesn't list 18 as an acceptable version. You could try downgrading your React to 17.

Sameer Thajudin22:05:47

Why have you stopped using lein? I assume you have a better alternative. If that is the case I would like to know.

p-himik07:05:47

I'm using deps.edn and shadow-cljs. Shadow-cljs is just a hassle-free build tool for CLJS, with some nice extras on top. And using deps.edn is much simpler conceptually, even though it might not always be easier to use it. But plenty has been written on deps.edn vs Lein - on this server and in numerous blogs.