squint 2022-12-20 | Slack Archive

borkdude16:12:11

squint v0.0.5 now supports passing down props in JSX using the syntax that #CRRJBCX7S supports: (let [m {:foo :bar}] #jsx [Foo {:& m}])

🎉 2

alexdavis17:12:28

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

alexdavis17:12:45

But I'm not sure what is involved in doing that

alexdavis17:12:07

Since squint is actually pretty different to standard cljs really

borkdude17:12:05

REPL is on the roadmap

borkdude17:12:11

nREPL support

borkdude17:12:17

but clojure-lsp helps a lot already

alexdavis17:12:14

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

alexdavis17:12:25

and yeah agreed clojure-lsp and kondo work well already

borkdude17:12:37

yeah, source maps are also planned

borkdude17:12:44

expect this to take a couple of months

alexdavis17:12:33

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

alexdavis17:12:51

so once the tooling is further ahead I don't think I'll have many reasons to not use this for everything

alexdavis17:12:42

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

alexdavis17:12:30

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

alexdavis17:12:46

but I can live without if it means I get lisp + clojure core functions

borkdude17:12:55

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 :)

alexdavis17:12:30

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

borkdude17:12:59

how does typescript help you avoid the horrors of mutability? if you want regular CLJS data structures, there's also #C03QZH5PG6M

borkdude17:12:14

oh, thanks for doing that blog!

Cora (she/her)17:12:24

in typescript you can set properties as read only, so there's that

👍 1

alexdavis18:12:48

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

👍 1

lilactown18:12:49

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

borkdude18:12:02

Give me an example of how this normally goes wrong in JS?

alexdavis20:12:42

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 data

borkdude21:12:24

gotcha

borkdude21:12:59

but foo.data doesn't throw in JS, it just returns null or undefined, right...?

alexdavis21:12:43

oh 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 squint

👍 1

borkdude21:12:42

I fixed foo.data.username to throw in SCI - until yesterday i didn't, but it wasn't according to how regular CLJS works ;)

borkdude21:12:09

I mean if the intermediate was nil

dangercoder22:12:24

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 🙂

🤯 2

dangercoder22:12:32

export let is needed for https://svelte.dev/tutorial/declaring-props and $: for https://svelte.dev/tutorial/reactive-declarations

alexdavis22:12:58

Have you tried the js* macro? (js* "$: foo") should compile to what you want, not ideal obviously but it should unblock you

dangercoder22:12:32

I haven’t, I’m going to try it thanks!

borkdude22:12:57

do you have an example of this?

borkdude22:12:09

I mean, a link to svelte docs where they explain what this does :)

alexdavis22:12:26