Clojurians Log v2

what’s the closest equivalent to extend? https://clojuredocs.org/clojure.core/extend seems like https://cljs.github.io/api/cljs.core/extend-type?

For devcards, is the best way to organize it to put a folder in the classpath (say src/dev) and mimic the folder structure of he namespaces under test. I have them currently in a src/dev classpath under "<my app name>/devcards.cljs. how do you all do you do it?

there is a very silly error I am getting which doesnt make sense. I am retrieving data from the server using the ajaxlibrary. the server sends the body as application/json, using ring-json-response handler. after retrieving the data I am logging it using (.log js/console (type body)) -> function String (). when I log body I get [[0 0] [1 2 ][2 3]]. So it seems the client received a string. now when I try to (read-string body) I get this error in the console Uncaught TypeError: cljs.core.read_string is undefined Why is clojure.core/read-string not available ? any help will be appreciated, stuck on this one

@murtaza52 its called cljs.reader/read-string

@thheller thanks, have tried that too, similar error Uncaught TypeError: cljs.reader is undefined

you need to require and refer or alias it in your ns (:require [cljs.reader :refer (read-string)]) then (read-string foo)

Does any remember why I am using goog.dom/createDom to generate dom instead of *document.createElement()`* ? I just burnt a few hours trying to figure out why a datalist was not working, turns out the list attribute on the input was being silently discarded. Had to do a setAttribute to jam it in. Now I am tempted to switch my whole UI framework off goog.dom. Does it have some advantage i am forgetting?

@hiskennyness the goog.dom stuff does some compatibility stuff for older browsers and fixes some related quirks. probably safe to use regular dom interop nowadays unless you need to support really old browsers

@thheller thanks, that worked. but shouldnt fns from clojure.core be available by default ?

its not part of core in cljs. not everything from clojure is available by design.

Thx, @thheller! That sounds like why I used goog.dom. But time moves on, so I’ll bet on browsers catching up and lose the dependency. 🙏

Hi All, I am new to clojure, and definitely plan to use it on the backend. I love svelte on the frontend. It is really good. But I have heard people talk about how much they like clojurescript also. I will appreciate if you can comment on the following: (1) Do you need to first learn react before using reframe/reagent? Surprisingly, I could not find this information. (2) If you have experience with Svelte, would you say that you still prefer Clojurescript. Thank you.

@curiouslearn 1) I would say no, not really. I first started with no React experience (as I basically inherited a re-frame app at work). Still, you'll want to dig into how React works over time to fill in the gaps.

@curiouslearn 2) not familiar with Svelte, but there's definitely scale advantages to using the same language front/backend, not to mention it's easier to mentally process how to implement features from start to finish

Thank you.

in my apps I have designed "shared" systems of data processing that both backend and frontend use on the same data, for example

that are basically the same clojure functions compiled to both targets

1. as reagent is just a wrapper around react, it's good (but not mandatory) to understand how react works overall before jumping into reagent. Re-frame is a bit similar to redux, so understanding of redux would help grokking re-frame. 2. Have a bit experience with Svelte. It's very different from ClojureScript. Mostly using ClojureScript because it's Clojure that transpiles to JS. Svelte is HTML+JS+CSS while ClojureScript development is mostly just using Clojure data structures for everything that then transpiles to HTML+JS+CSS. Biggest win for me is being able to move between backend/frontend code without having to consider what language/environment I'm in, as most things work the same. Also, would never use anything but Clojure/Script today, unless it can give me a proper repl connected to my state in backend/frontend

the REPL really spoils you, I'm having a hard time writing anything else but Clojure now, as it's such a frustrating experience not having a REPL aware of application state

> that are basically the same clojure functions compiled to both targets That is definitely a great advantage.

@victorbjelkholm429 Thank you. This is very helpful. Any pointers to videos/posts that explain the very basics of how to make REPL aware of the application state. Thank you.

Best starting resource I've found: https://www.youtube.com/watch?v=j-kj2qwJa_E @bhauman goes through why and how you can use repl to speed up development

He's using figwheel in that example, lots of people are using shadow-cljs nowadays as well, but not sure about any videos with shadow-cljs that are as easy to understand without much knowledge since before

Thank you @victorbjelkholm429. I look forward to seeing it.

I think one of the big wins of Reagent/re-frame is not having to deal with the madness of ReactJS. One of the huge wins of CLJS is that it is done. ES still seems to be emerging from the sea. It is a lot better but why mess with the evolution when we have apps to write? 🤷

Pardon a nooby Q, but I have been away. I hear great things about shadow cljs. I am doing great with figwheel:main, loving the hot loading and spectacular error diagnostics. What would be the elevator pitch for switching to shadow? Thx! 🙏

is there a way to use a single NPM package (mapbox-gl) with figwheel-main, without setting up an entire JS toolchain? can the package be included “manually” somehow?

For me, the selling point was first class integration with NPM. You can literally yarn add any-package and :require it in CLJS code. Error diagnostics and hot reloading are at par with Figwheel. I didn't feel any difference when I switched. CLJS recently released support for NPM packages, you can read Shadow' author's views on his blog: https://code.thheller.com/blog/shadow-cljs/2020/05/08/how-about-webpack-now.html

You see the message just below yours, asking how to integrate mapbox-gl , things like this are a no-brainer with Shadow.

Ugh, I have PTSD with Node. But I lack seamless package integration. I’ll check it out. Thx!

Node is too strong to beat by force or resistance, but you can hide in the Shadow.

not sure whether to post here or in #core-async : is there a sane way to run things in async chans in a browser? it seems like any amount of work I do in an async chan will freeze up the render thread since it seems to handle up to 32/1024 scheduled tasks in one batch.

only way forward I see is to do the minimum amount of work in those chans and try to move off to a worker as fast as possible or possibly to split work into smaller chunks

Is it possible to list all vars in a ns at runtime, without using macros like ns-publics?

I just set this up with figwheel-main and it was a no-brainer there as well, but I had to drag in npm and webpack which I wanted to avoid for the same reasons as @hiskennyness

what’s difference between (mapboxgl/Map. #js {:container "app"})) and (.Map mapboxgl #js {:container "app"}))?