> What's a gent to do? Well, what do you need to do? A personal blog is one thing, a data-heavy SPA is another.

I will eventually be writing a web app that acts something like a dictionary. I suspect drawn input (from a mouse) from the user will also be required.

As part of the output, there will be some (hopefully) interactive graphs (the node-and-edge kind).

I'd say this is a good way to start then: https://github.com/shadow-cljs/quickstart-browser

Is it basically assumed that the React wrapper are to be used?

You can write code without any wrappers but that would be similar to going with plain JS instead of JSX. There are really thing wrappers that make interop with React pretty much seamless. And there are more abstracting wrappers that focus on other things.

If I were to go the React route, would learning it entirely through Clojure be good?

I did it that way but I'm hesitant to recommend it. If you enjoy reading source code as much as you enjoy reading prose, consider debugging minified JS bundles to be fun, don't get put off by 15 unrelated issues you know nothing about, then you're like me and I'd say "sure, go for it". But if not, then I don't know.

😆 I think I'll "consider my options"

But to be fair, learning vanilla React to a degree where you can build great stuff with it is not that much of a task. So you can easily get started with some React quick start, get comfortable with it, and then switch to CLJS and some React wrapper.

"Is it basically assumed that the React wrapper are to be used?" I would say React wrappers indeed have been the community favorite for a long time, but: • Hoplon/Javelin is also a veteran and slick way to go, and is being refurbished as we speak; • on the newer side we have Biff with HTMX; • I have a Web/MX project which handles the DOM directly; • and to me the coolest way to do the Web is Flutter, so we get mobile and desktop at the same time, almost for free. Check out #C03A6GE8D32 or again one of my libs, Flutter/MX supported in the #CKCBP3QF9 channel; • and if you do go with React, #CRRJBCX7S offers a nice functional interface (no Hiccup), and #C073DKH9P is excellent and very propular. Have fun!

Thanks for a breakdown of the options!

That's expected for anything that's not a plain JS object and doesn't satisfy IEncodeClojure.

I see. The object has only flat data, so is there any way to convert the object to a 'plain js object'?

What does (identical? (type x) js/Object) say for that object?

You can always iterate over the kvs yourself - the impl of js->clj is trivial.

It gives false

But in the browser console:

> typeof(x)
'object'

Then it's not a plain object. :) It has a constructor and you can't convert those objects in general - you have to figure out what is suitable in your specific case. typeof is misleading:

=> typeof(new Date())
'object'

Fair.

In clojurescript (type x) is undefined.

That is surprising. Does that object have a constructor field that's set to undefined?

type in CLJS is just this:

(defn type
  "Return x's constructor."
  [x]
  (when-not (nil? x)
    (.-constructor x)))

Nope

Strange

Welp, Doing JSON.parse(JSON.stringify(x)) and passing that to clj->js works.

How did you create that object in the first place?

I got it from blockly's json export.

And how does it look in text? Assuming it's not private and not huge.

(Which gives you the json as an object rather than a string...for some reason...)

Huh.

The object?

> And how does it look in text? Assuming it's not private and not huge.

Not sure what you mean by that.

Yeah, I thought Blockly's export gave you a string.

Is it something that one can easily reproduce on their own? Curios to poke around.

Oh, no, it used to, back when they exported as xml.

But it seems like their json export gives you an object.

FWIW, here is my code: https://gist.github.com/LeifAndersen/5c27f64142203832fcf61b7eb65214c4

Is the line with onJsonChange the one where the export is done?

That is correct.

In older versions it was onXmlChange

Which gave a string.

But here when I print it to the console, it prints a javascript object.

Ah, they're using Object.create(null). Seems like it ends up with something more plain than a plain JS object, heh. I'd iterate over such an object directly to create a CLJS data structure. So, if I were you, I'd just write my own js->clj that would not only handle this particular case but would also be somewhat faster because you would be able to exclude a bunch of checks from there.

Mmm...that makes sense.

Odd...I didn't even know that was possible. Thanks btw.

Oh, and there's an issue for it already: https://clojure.atlassian.net/browse/CLJS-2408

And, if you want, you can vote on it here to increase its priority: https://ask.clojure.org/index.php/5926/js-clj-does-not-work-on-objects-with-null-prototype?show=5926#q5926

Looking at the age of it, I doubt it will get closed any time soon...

> And, if you want, you can vote on it here to increase its priority: https://ask.clojure.org/index.php/5926/js-clj-does-not-work-on-objects-with-null-prototype?show=5926#q5926 Ah, didn't see your second link. Thanks. 🙂

There are a lot of things in the backlog, and without voting for it it won't get prioritized.

Yup, I get that.

Anyway, voted.