Clojurians Log v2
cljs-dev
FWIW I don't think a generic morph thing is all that useful. kinda also need the rest of the stuff, like assuming you have some server generated HTML, where do you get the next one from? by which method? by which event? initiated from the server or the client? you really need more of a library for that, at which point the library would include the morph thing. Not saying that wouldn't be useful, but "just a morph function" doesn't do much, and is also kind of the least interesting thing.
Just don't agree, you do not need the rest of the stuff because you don't care what the rest of the stuff is
and it's unlikely you'll imagine what those things will be. people will figure it out.
in anycase it's doesn't really matter that much impact-wise, there's plenty of things in GCL that various people do and don't use depending on their needs.
I don't have a strong opinion on whether such a thing should or should not be included, but right now people can include Idiomorph using a script tag, no NPM needed?
The issue about making CLJS work with libraries from script tags, using the js$ require thing would be interesting to me in this area
if you want to use idiomorph having this thing won't change that.
sorry, then I misunderstood. I thought you were going to include Idiomorph itself as a goog module
haha, no a whole new goog.dom.morph is what I'm proposing
gotcha
sorry for the confusion
I'd totally drop the goog. shit ... whats the point in that 😛
yeah including idiomorph no way
haha, sticking w/ goog is a bit odd, but cljs is also not great for a js lib.
org.cljs ?
whether I get around to doing this morph thing, a convention around additions to GCL for our own stuff would be good.
doesn't really matter in the end. I don't agree that this needs to be a concern of cljs itself, so I'd always put it in a library. if it turns out useful thats a better distribution method just by not being "shackled" by CLJS Jira ways of doing stuff. That hasn't been exactly "contribution friendly"
that's a reasonable point - but a I think a truly primitive morph thing is kind of one-off thing. not something you're continually developing in a active sort of way all the time.
the fact that there are so many morph libs suggests that is not true. there are various strategies for doing this, all with different trade offs
I don't think there are that many, the ones I posted are the most canonical
nanomorph shows conceptually that it's a very simple thing. Phoenix Live View uses morphdom, and idiomorph is Rails, htmx, and datastar.
idiomorph of the 3 does the best job of preserving the UI state far as I can tell, I think Rails switched to that from morphdom.
having this much prior art (and none of them are that new) is a good thing.
would goog.morph.dom (or why not cljs.morph.dom or whatever) provide a different impl than idiomorph? then why not straight up copy and wrap it?
a different impl - would like to abstract the tree rep
would love to see a POC of an CLJS app/website using this
I mean one advantage to be honest is you could get on the HTXM style bandwagon out of the box w/o reading about all the JS stuff and making assessments
figuring this stuff is not a small amount of work
HTMX/datastar already make this choice for you, kind of.
right you have to eat everything all at once, I don't like that.
vs. here are some primitives and they are Clojure first
HTMX/datastar also seriously un-Lispy - they are great, but I wouldn't want to use them as is.
re: the global thing, I think all options except new (:require ...) syntax are dead. Later can consider sugar, but against addressing that in the first pass.
first pass of what exactly?
dealing w/ globals directly as a require construct
i.e. like macros, special syntax
the sugar stuff appeared way later
I see
https://clojure.atlassian.net/browse/CLJS-3233?focusedCommentId=51059
I'm not totally clear what you mean by "sugar". Do you consider (:require ["js$..."]) sugar? What would be the non-sugar variant of that?
I linked to the variant I'm interested in, not interested anything beyond that.
you can look at the current ns parsing to see how we desugar - it's pretty annoying - a lot of complexity.
oh sorry for not noticing that. yeah, either way would be great. the sugar is a bit annoying to implement, I've implemented it in squint and SCI too
I assume you mean the $default.foo.bar sugar right
anything that's merged in w/ normal :require
and if it wasn't a require
(ns foo.bar (:require ...) (:globals [window.location :as loc] [MyCustomGlobal]))
And use as
(location/reload)
(.send (MyCustomGlobal.) ...)That's what @dnolen proposed in the comment he linked to:
:require-global(:require [js/foo :as-alias dude])we've been through this already, no js/ magic in require