Fork me on GitHub
#clojurescript
<
2021-05-26
>
borkdude09:05:40

@thheller Would it be possible to compile an advanced build of reagent and let people provide React using a script tag, so the version of React becomes a choice in the HTML?

borkdude09:05:59

or are the names of the React library also mangled by Closure?

thheller09:05:49

npm packages in general don't go through advanced so renaming is generally not an issue (if you have externs of course)

borkdude09:05:22

@thheller is this :js-resolve option something from shadow or cljs?

borkdude09:05:06

For completeness, I had to configure it like this:

:js-options
   {:resolve {"react" {:target :global
                       :global "React"}
              "react-dom" {:target :global
                           :global "ReactDOM"}}}
You might want to update the example in the book

borkdude09:05:17

but it seems to work perfectly, thanks!

thheller09:05:32

what do I need to update? isn't that the example in the book? :resolve is purely from shadow, CLJS handles this differently via :foreign-libs

borkdude09:05:52

@thheller "react-dom". When I left that out, my website got stuck in an infinite loop (since there were still some node modules in the project, things got weird)

borkdude09:05:59

hmm, the dev build worked fine with React from a CDN, but still got some problems when compiling with release. Somehow it also re-creates a package.json, etc, while, I think it shouldn't have to? EDIT: probably some other dev build running in the background, messing things up.

Dharmendra10:05:16

Hi, I am new in clojurescript world. I was trying to do breakpoint debugging in VSCode with Calva. But could not able to do that. I followed this doc: https://calva.io/debugger/#:~:text=You%20can%20insert%20a%20breakpoint,level%20form%20with%20alt%2Benter%20. Is there any Video instructions available for it?

p-himik11:05:45

At the very top of that page: > The debugger currently does not support ClojureScript And there's also the #calva channel here.

thanks3 3
valerauko11:05:36

is there some simple cljs http library for node? (preferably one that just blocks for me so i don't have to play around with go chans etc)

borkdude12:05:37

blocking in node? lol, good luck with that :)

Karol Wójcik12:05:49

It's possible when using fibers 😄

(defn <!!
    [c]
    (let [f js/Fiber.current]
      (go
        (.run f (<! c)))
      (.yield js/Fiber)))

Karol Wójcik12:05:57

But it's Node.js only and it works terribly bad with channels

valerauko15:05:42

i was hoping for something along the ease of js await

Karol Wójcik13:05:53

Await does not block for you 😮

Karol Wójcik13:05:37

It's just a syntax sugar for Promises. If you looking for such sugar then check Promesa out.

valerauko14:05:22

promesa isn't much different from just calling .then and .catch though (in cljs world)

Karol Wójcik14:05:57

Do you thing that async/await is in some sort different?

valerauko14:05:11

no i'm well aware that it's syntax sugar and i was hoping for something similar

valerauko14:05:38

<p! is nice but you must use it in a go block which makes passing things around much more difficult

Karol Wójcik14:05:04

I'm trying to avoid channels on Clojurescript as much as I can now. It makes the bundle size really huge even for simple operations. Actually promesa is something you seek for: https://cljdoc.org/d/funcool/promesa/6.0.1/api/promesa.core#plet

valerauko16:05:15

oh wei that plet really looks amazing. reminds me of manifold's let-flow. thanks, i'll check that out!

Karol Wójcik16:05:41

It’s really got soft. To full async/await alike flow only try/catch as a macro would be needed. Plet it's even better than pure async/await and with bluebird you can get a really good performance!

valerauko12:05:39

okay then just "anything that doesn't want me to juggle around async chans"

borkdude12:05:46

cljs-ajax is what is used a lot, I've also used it in several projects

borkdude12:05:14

not sure if it works with node or only in browser

borkdude12:05:30

in other cases I would just write raw interop with the node stuff

borkdude12:05:06

If I have a map like (ns quux) (def namespaces {'foo foo/bar}) in my code, is my assumption correct that the map will only contain a reference to the function foo/bar and Closure will not actually duplicate a copy of that function to the quux namespace? I wonder about this since in this report https://borkdude.github.io/scittle/report.html you see that it pulls in about 300kb from cljs.core but also has about 300kb in sci.impl.namespaces, which is a bit suspicious imo, since sci.impl.namespaces should mostly contain references to other functions.

thheller13:05:31

you are creating huge amounts of vars with metadata, the actual code probably is only a fraction of that. yes, the maps will only contain references, it won't duplicate the code.

borkdude13:05:19

true, I should investigate if I can elide this stuff, perhaps using some goog defines

valerauko13:05:31

yup sadly that lib doesn't work on node

valerauko13:05:38

time to write some Nice Interop

borkdude14:05:53

thheller: yep, that was it

👍 3