This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-12-20
Channels
- # adventofcode (29)
- # announcements (7)
- # aws (1)
- # babashka (3)
- # beginners (43)
- # biff (20)
- # clj-kondo (44)
- # cljs-dev (20)
- # clojure (74)
- # clojure-europe (24)
- # clojure-finland (2)
- # clojure-nl (13)
- # clojure-norway (3)
- # clojurescript (31)
- # code-reviews (1)
- # community-development (12)
- # cursive (3)
- # datomic (6)
- # emacs (1)
- # fulcro (25)
- # interop (7)
- # introduce-yourself (2)
- # leiningen (30)
- # nbb (3)
- # overtone (1)
- # podcasts-discuss (5)
- # polylith (24)
- # practicalli (1)
- # reclojure (1)
- # reitit (13)
- # rum (7)
- # shadow-cljs (12)
- # sql (23)
- # squint (51)
- # test-check (1)
- # testing (2)
- # tools-deps (2)
squint v0.0.5 now supports passing down props in JSX using the syntax that #CRRJBCX7S supports: (let [m {:foo :bar}] #jsx [Foo {:& m}])
nice! I think the next major pain point I have after working quite a bit with squint the past few days is tooling. specifically REPL and things that come with a REPL like jump to definition and autocomplete/auto requires
another thought I had was source maps, with typescript I basically don't need to ever see what it gets compiled into, and I'm not even sure where the compiled code goes. in the browser I can see the typescript files and stack traces go straight to the relevant line. with squint atm the stack trace shows the compiled js file, which isn't that bad honestly but I'm just wondering if its a possibility to get a more 'native' typescript-like experience
I'm honestly not far off the productivity levels I get with typescript right now, because even though it takes me an extra few seconds to manually add requires etc, the clojure core library is much better at a lot of tasks
so once the tooling is further ahead I don't think I'll have many reasons to not use this for everything
I guess I do kind of miss the ability to see the shape of objects, but I guess thats not going to happen unless it compiles to typescript which probably isn't worth it
I didn't really enjoy typescript at first but it did kind of grow on me, especially with graphql or trpc because the types get autogenerated and are end to end
yeah, perhaps we can have some interesting typescript annotations in comments or so, don't know, I haven't thought deeply about that, but first the tooling :)
yeah it sounds like it would be a big job, and the other stuff is definitely higher priority. but I know a lot of typescript purists who refuse to even look at standard js projects these days. and using raw js objects rather than immutable data structures does open squint up a little more to the horrors of js which typescript sort of protects against. but again I'm just thinking out loud here 😄 I'm going to try and write a blog article about my squint experiences over the holidays, I have enjoyed working with it a lot
how does typescript help you avoid the horrors of mutability? if you want regular CLJS data structures, there's also #C03QZH5PG6M
Yeah I should have just said ‘horrors of JavaScript’, stuff like knowing if something will blow up at runtime when it wouldn’t in cljs. Squint actually protects from a lot of it with its core fns and by not blowing up when trying to access a non existent key, but there’s still a few weird things out there
I spend a few hours helping someone with Python code last week, and the knots you have to tie yourself into in order to avoid accessing a key that doesn't exist had me so grateful that Clojure handles that with grace
const foo = useSomeQuery() ;; foo is initially an empty map and when the hook has successfully completed
;; a fetch the map will contain {data: "bar"}
return (
<div>{foo.data}</div>
)
this will blow up. typescript will warn you and tsserver lsp will auto correct foo.data
to foo?.data
for you which is safe, though you still have to be careful and usually it involves a lot of foo?.data && ....
which gets quite annoying, especially on more nested bits of dataoh yeah you're right, but generally foo.data will be some object that you've queried, so you want to do
foo.data.username
or whatever, and that will throw if data doesn't exist, which it doesn't if you do (-> foo :data :username)
in squintI fixed foo.data.username
to throw in SCI - until yesterday i didn't, but it wasn't according to how regular CLJS works ;)
Does anyone know if it’s possible to emit export let
and $:
javascript? I’m using squint* and svelte here: https://github.com/Dangercoder/svelte-cljs-example 🙂
export let
is needed for https://svelte.dev/tutorial/declaring-props and $:
for https://svelte.dev/tutorial/reactive-declarations
Have you tried the js*
macro? (js* "$: foo")
should compile to what you want, not ideal obviously but it should unblock you
I haven’t, I’m going to try it thanks!
Yeah think so, the $:
thing is apparently part of the js spec, though I've never seen it used outside svelte https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/label
Confirmed js* works for the reactivity part. Going to try props now, this is exciting 😄
props works too, added all of this to the example repo
next step is to define e.g. logic in standalone cljs files and use that from .svelte . This is really cool!