<div hc-on:click="(-> el (_closest :div) _remove)">
      click to remove me ....
    </div>

shouldn't be too difficult

the fiddle doesn't work yet right?

it should work

show/?editor_console=:183 Uncaught ReferenceError: htmx is not defined at show/?editor_console=:183:24

oh wait hmm

can't see what is off. Works here in a fresh incognito browser window. Tried Chrome and Brave

before and after 🙈

ah yes, it does work in another browser for me

don't know what the difference is

it works now, very cool!

Yeah it think so too :face_with_hand_over_mouth: Probably needs some good API design and real life testing. But I like the idea i think

where can I see the source of this in the jsdiffle?

fiddle

It should be below the html. I was hiding it for the wow effect

Here is the whole snippet

very cool

old squint version ;)

haha oh oops 😅

I also didn't know a better way to expose an api to the squint context, but it works this way. Maybe it would be good to have some namespaces for the htmx functions and maybe a threading macro to not having to repeat that namespace. Maybe some experienced htmx users have an opinion, i'm not there yet

you can use the repl output in the newest squint versions to emit "namespaces" as global objects

anyway, let me know if you have any concrete questions, happy to help

not yet, thanks! now just sharing this brainfart. Maybe I'll try it a bit for real later

I was also thinking about this a few days ago! The idea I had also involved something like the following on the server side

[:button {:onclick (squint (js/alert "test")))} "test"]

And then there could be a tiny support lib like what you used in your example @U0FT7SRLP

Nice @U050TNB9F! I think the native onclick cannot be used nicely because the element is not passed to the function (so you don't know where you are without hacks). I think that's why hyperscript has an edge for instance. But yeah lot of options

Also, a custom attribute also has the advantage of allowing a custom treatment. So you can assume a certain format, context etc. With onclick it has to be javascript. I guess some tradeoffs here

"I think the native onclick cannot be used nicely" I guess you could make a convention of what the el thing is or so

Ah yeah, totally could use a different attribute, I didn't really think to far about it. I just really liked the prospect of having an actual syntax in your editor (and lint that even)

yes and to compile it on the backend has the benefit of reduction in JS size

Yeah sounds good, i think it is nice that squint allows to experiment with both. So it would also work for people that don't have a clojure(script) setup

> I guess you could make a convention of what the el thing is or so Yeah in case you mean the naming, for sure. But I could not find a way to get access to the current dom element with the normal onclick . this seems to be the window in e.g. <button onclick="console.log(this)">click</button> from the top of my head

With addEventListener you can do this.target and get the element from which you can to the parent etc

sorry i mean the argument to the function, not this

[:div {:on {:click (some-squint-code)}}]

now only a question of how to compile that 😄

why not just [:div {:onclick (squint ...)] which is regular hiccup where squint can be the macro?

This is what this does here

[:div {:onclick "function(e){console.log(e)}"}  "hi"] 

<div onclick="function(e){console.log(e)}">hi</div>

Uncaught SyntaxError: Function statements require a function name (at squint.html:31:231)

yes, this is true, why pass a function there though?

ah but i ran into this before 🙂

you have to write function foo () {}

as in, give it a name

you can wrap it with another function and then it works too

I think I'm missing a couple of points here

onclick doesn't support a function expression, right?

it just supports a snippet of JS that it will execute?

yeah i think that's the problem. I was just verifying if i missed something, but yeah that's the reason

so the snippet doesn't give you the current element. Which is what you want often. Maybe you could do a lookup, but that might be expensive?

(like parsing and searching for it?)

Perhaps you could compile to:

(fn [this] (-> ...)) => (this-as this ((fn [this] ...) this)

which should work

and I think this points to the target element there

yeah indeed. But this only works if you add if via node.addEventListener('click', function(this) { ... }) I think

no...

first transform to (this-as this ((fn [this] ...) this)) and then compile that

this is just an ordinary expression

ok this is something I don't know I guess

but would be nice

this-as comes from clojurescript? It feels familiar

yes

I think in the end the squint macro or whatever would need to inject compiled JS into the runtime, it probably won't work to emit the compiled JS into an HTML attribute 😄

sure it will ;)

with the right pre/post-processing

https://squint-cljs.github.io/squint/?src=KHRoaXMtYXMgdGhpcyAoKGZuIFt0aGlzXSAid2hhdGV2ZXIiKSB0aGlzKSk%3D&repl=true

ok maybe i just missed something or missed one step. I was wrong you have access to this in the onclick . Never mind the above 🙈

right, so you could have:

{:onclick "(this-as this ((fn [this] ...) this))"}

(fn [this] ...)

maybe, but it'll hurt readability, probably makes it hard to debug etc. no? I'd think emitting a <script> tag would be a bit more "in line"

fine, but then why use inline expressions at all and not just use squint normally

<script>(squint ...)</script>

if you compile it with squint you could wrap this in the context? No need for this-as ? We don't need the function wrapping at all i think. I was wrong here

you need this-as since this is renamed

since it can be a normal function argument which doesn't clash with JS's this

(fn [x y this whatever])

ah maybe that's what I ran into

this is why you HAVE TO use this-as if you want to access JS's this

or you can fuck around with (js* "this")

I had the wrong assumption that htmx and hyperscript were using custom attributes because of the lack of access to this, but that is not the case. But a custom attribute does allow custom treatment, with onclick it needs to be valid javacript. So maybe custom still gives nicer syntax options

(have to go, thanks for your enthusiasm 🙂 )

> fine, but then why use inline expressions at all and not just use squint normally btw, that would be this argument https://htmx.org/essays/locality-of-behaviour/

my point wasn't to argue for or against locality, but if you're using local snippets, why compile to JS that behaves different, was my question to Martin

gotta go too

> fine, but then why use inline expressions at all and not just use squint normally Mostly to not have a compiler on the client and be able to provide some wrapping constructs for handlers... but maybe that can be achieved in other ways as well 🙂

So maybe just wrapping the ="..." expressions in a (this-as el ...) would be enough, then the user could write:

(-> el ...)

One issue was that npx didn't work on Windows, another one is that yarn somehow didn't work