This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-06-29
Channels
- # announcements (44)
- # architecture (12)
- # babashka (45)
- # beginners (56)
- # calva (16)
- # cider (34)
- # clj-kondo (6)
- # clojure (47)
- # clojure-austin (2)
- # clojure-brasil (3)
- # clojure-europe (39)
- # clojure-germany (2)
- # clojure-nl (1)
- # clojure-norway (39)
- # clojurescript (7)
- # cursive (1)
- # datahike (2)
- # datomic (28)
- # emacs (8)
- # gratitude (3)
- # humbleui (4)
- # hyperfiddle (45)
- # kaocha (1)
- # lsp (94)
- # nbb (2)
- # off-topic (29)
- # practicalli (8)
- # releases (2)
- # shadow-cljs (6)
- # squint (17)
- # tools-deps (12)
- # vim (11)
Just watched @alex395’s talk on State of Front End which mentioned Squint which made me think more about using it at work to let me write cljs but produce JS for use in our React.js app... but we're mostly still using class components and it looks like JS class support is still on the roadmap for Squint (issue #97 et al). I'm not yet familiar enough with our React.js codebase to know if we're using any functional components and hooks stuff so I'll have to see if that's a viable path...
Ooh, it looks like quite a bit of the codebase does use functional components... I just haven't worked on that part yet 🙂 I was just a bit puzzled by seeing components have .propTypes
and .defaultProps
added to them and assumed they were classes... but they are functions...
I'm able to generate .jsx
code that looks a lot like some of the existing JSX files we have so this might be a fun experiment to continue tomorrow and see whether I can make a real React component that plays nice with our existing! :thinking_face:
Cool, let me know how it goes. Defclass should be added, just haven’t gotten around to it yet
Ooh, it looks like quite a bit of the codebase does use functional components... I just haven't worked on that part yet 🙂 I was just a bit puzzled by seeing components have .propTypes
and .defaultProps
added to them and assumed they were classes... but they are functions...
One thing I ran into: if you write code that uses lodash and you (:require ["lodash$default" :as _])
to be like other JS code, then you can't refer to the core -
function in a context that needs a reference to it as a function (rather than just math expressions), e.g., (let [f -] (f 1 2 3))
-- because -
munges to _
and that's what the core.js
function is called... but instead you get the _
lodash object.
I know this is kind of a weird edge case, but it did make me wonder how you could reference core functions when you have an alias to the same name.
In Clojure (and I assume in ClojureScript) you could say clojure.core/map
if you had some other map
symbol in the way.
I then realized you could (:require ["squint-cljs/core.js" :as cc])
and then reference cc/-
and it worked -- sneaky how it uses the :as
name to prefix and rename functions that are used!
@U04V70XH6 sorry I only saw this message now, if it's still important to you, can you file an issue about it?
I didn't file an issue because I'm not really sure what the expected behavior should be here. I understand why it happens and I know how to work around it. I mean, what could it do differently?
I consider it a bug. In CLJS you get this:
cljs.user=> (require '[clojure.walk :as _])
nil
cljs.user=> (map - [1 2 3])
(-1 -2 -3)
cljs.user=> (_/postwalk identity {:a 1})
{:a 1}
Ah, okay. Shall I create an issue then?
I actually can't repro it with the newest squint version:
user=> (require '[clojure.string :as _])
undefined
user=> _
[Function: _]
user=> (vec (map - [1 2 3]))
[ 1, 2, 3 ]
user=> (_ 1 2)
-1
user=> (_/join "," [1 2 3])
1,2,3
user=> (- 1 2)
-1
user=> (apply - [1 2])
-1
ah I can repro it outside of a REPL:
(require '["fs" :as _])
(prn (vec (map - [1 2 3])))
(prn (_/join "," [1 2 3]))
(prn (apply - [1 2]))