This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-09-13
Channels
- # announcements (15)
- # babashka (48)
- # beginners (5)
- # biff (4)
- # calva (3)
- # cider (10)
- # clerk (16)
- # clj-kondo (6)
- # cljdoc (20)
- # cljs-dev (13)
- # clojure (117)
- # clojure-argentina (1)
- # clojure-brasil (5)
- # clojure-europe (40)
- # clojure-nl (1)
- # clojure-norway (111)
- # clojure-uk (5)
- # clojurescript (16)
- # cursive (20)
- # datascript (2)
- # datomic (106)
- # etaoin (2)
- # events (3)
- # funcool (1)
- # graphql (1)
- # helix (8)
- # hyperfiddle (36)
- # leiningen (12)
- # matrix (1)
- # nrepl (1)
- # off-topic (61)
- # other-languages (10)
- # polylith (22)
- # practicalli (1)
- # reagent (28)
- # reitit (11)
- # remote-jobs (3)
- # ring (12)
- # shadow-cljs (109)
- # slack-help (6)
- # solo-full-stack (23)
- # squint (7)
- # xtdb (11)
got bitten (again) by a missing clj->js
today. The ongoing of friction (js interop and promises) are still reducing the joy of my experiences with CLJS. Does everyone else just :man-shrugging::skin-tone-3: ?
I almost never use clj->js
- sometimes we use cljs-bean at work for objects, but normally I prefer to construct a JS object using the #js
reader tags or use an explicit conversion like into-array
. There are also many cases you don’t need to convert anything - CLJS vectors are Iterable so you can pass them directly to lots of functions
True that #js
is easy to miss especially in nested objects. I’ve not thought about it in ages though, and we do lots of interop with ProseMirror and other React libraries. Maybe it just gets better :man-shrugging: So helpful, I know
I'll put you down as a :man-shrugging::skin-tone-3: @UE72GJS7J
there are 3 main interop ways that I see • #js / clj->js • cljs-bean • applied-science.js-interop which demonstrates the .... innovation | :man-shrugging::skin-tone-3: | 😖
> you saying it's ready for production? chicken and egg, the more people will be using it, the more ready it becomes. it's easy to try out since it works on a file by file basis though. you can integrate it in an existing CLJS project to e.g. write a few things and use those from CLJS
I think I’ve gotten better at starting to suspect that I have the problem. Not saying I am good at it yet, but at least I feel less of the friction.
Orthogonal, but anyway. I think @U06F82LES has some advice around not reaching for clj->js
and js->clj
too automatically, but to consider alternatives. I think it is mostly for performance reasons.
is it because the emitted JS should be compatible with version of JS when Map was not a class (eg pre ES6)?
It’s great with Pro Slack. I could find this: https://clojurians.slack.com/archives/C03S1L9DN/p1528186994000317
it doesn't apply to clj->js
... cos afaik there is no other way to do it (please don't say #js
all the way down cos yeah I could but I'm not gonna)
i quite enjoyed https://github.com/applied-science/js-interop on a recent project
and for promise stuff, i often find promesa's https://github.com/funcool/promesa/blob/master/doc/promises.md#let can clear up a mess
I've recently been using https://github.com/yapsterapp/a-frame to avoid infection - it's an async BE port of re-frame - the coeffect+effect handlers are mostly promise-based, but it lets you have pure business logic
dudez and dudettez and all others, look, import .cljs from js!
import { the_number } from "./calc.cljs";
😁
https://github.com/borkdude/bun-squint-loader/blob/e5a3cf3e94243f1e6d5d3892d47a2b794a601480/index.js#L1
I’ve been refactoring some code lately. Made me think about how much of this can be simplified with the REPL & clojure-lsp! I’m doing something like this, and I’ve been enjoying the process: 1. Deprecate function I want to stop using, another function that does it ’right, write “deprecated, use new thing” in old thing docs 2. Move usages over to the new thing (using find references with LSP) 3. Find the nest deprecated function with a piece of REPL code. I was kind of surprised that “look at the metadata of every var in process was a instant. But it’s already in memory, so perhaps I shouldn’t be surprised! I guess filtering out irrelevant namespaces early helps.