Why is the manifest.edn map in a list?

ah, for multiple modules I guess

makes sense

It seems like the manifest.edn should not be generated in the same place as the target output, because the target output needs to be public, but it seems that the manifest.edn should not

Hello, new to shadow-cljs; I'm in the process of migrating an application over from figwheel-main and am encountering an error with the npm module viz.js https://www.npmjs.com/package/viz.js. viz.js is an Emscripten transpile of graphviz (which is C) to asm javascript so the javascript itself (in full.render.js in the viz.js package) is pretty hairy!

I follow the instructions at the bottom of the viz.js author's page https://github.com/mdaines/viz.js/wiki/Usage and the shadow-cljs user guide (section 11) and require viz.js into my code as so

["viz.js/viz.js" :as Viz] ["viz.js/full.render.js" :refer (Module render)]

and get a shadow error

Caused by: RuntimeException: INTERNAL COMPILER ERROR. Please report this problem. An enclosing scope is required for change reports but node LABEL 15 [length: 2] [source_file: node_modules/viz_DOT_js/full.render.js] doesn't have one. Node(FOR): node_modules/viz_DOT_js/full.render.js:15:4095

so, not really needing viz.js to be attempted to be further compiled, I set the following option in my shadow-cljs.edn

:js-options {:js-provider :require}

but unfortunately this seems to cause breaks around other existing dependencies in my project, for example [io.nervous/kvlt "0.1.4"]

Any tips on how to get this particular npm module to work (as an npm module) would be much apprecicated.

@mojo yeah the emscripten packages seem to confuse the closure compiler. :js-provider :require is only for node environments and doesn't work in the browser.

for viz you probably need to stick with https://github.com/mdaines/viz.js/wiki/Usage#using-a-script-tag for now

it used to be compilable though https://github.com/thheller/shadow-cljs/issues/173

but yeah this option is still missing

> A hack to put Graphviz on the web.

a 2MB+ package is really not that practical for the web 😛

Got it - thanks for the steer. Yes - as the description says it's a (clever) hack 🙂 I also have Graphviz mounted as an AWS lambda but then realised that sending my company's data out over the web is not policy compliant hence the need for the hack! Would be supportive of the option to provide a list of modules which don't go through any compilation processing.

Worked perfectly - thank you

One other thing to mention. I had also tried the approach of requiring the .js files as set out in section 11.2 of your excellent documentation, but had no luck with that approach - it couldn't find the modules even though I'd followed the suggested directory structure. Is that approach also only for the

node

lol - still yet to get the hang of backticking in Slack 🙂

not sure what you mean?

the require you had was correct

yes - requiring as a node module. Well, when that didn't work and before posting here, I always tried the approach laid out in section 11.2.1 of your documentation - requiring the js files correctly. The reason I tried that as well was that pretty sure I read there that any source .js files under a js/ would not be passed through compilation

so wondered alternative approach is valid for the :browser target? (and I just hadn't got it quite right) - or only for other targets?

no that is incorrect. quite the opposite actually. the files will go through :advanced optimizations

node_modules will only do :simple which already fails for viz.js so :advanced is unlikely to work

The line that confused me was actually in the following section 11.2.3 - Notice how src/js is not added to :source-paths and will not be added to the classpath. Obviously, I must have speed read too much and jumped ahead thinking that between the two sections, there was a way to exclude .js files from the compiler but still be able to require them. my bad. thanks for clarifying

I’m trying out that weird trick mfikes posted in #cljs-dev:

(do (declare ^{:arglists '([a b c] [a b & cs])} create-element)
    (set! create-element react/createElement))

18 | (defn tag-render [{:keys [title body]}]
-------^------------------------------------------------------------------------
 Wrong number of args (5) passed to hiccup-next.react/create-element
--------------------------------------------------------------------------------
  19 |   #h/n [:div {:class "card"}
  20 |         [:div {:class "card-title"} title]
  21 |         [:div {:class "card-body"} body]
  22 |         [:div {:class "card-footer"}
--------------------------------------------------------------------------------

how the heck is that even compiling? reader literals aren't supported like that?

😄 what do you mean?

#h/n this isn't supported (in shadow-cljs)

why not? it’s a perfectly valid ns’d symbol…

because its nonsense to do this in code

oh are custom reader tags not supported at all you mean?

yes, no custom reader tags during compilation. at runtime is fine but not during compilation

also the arglist trick is sort of a cheat an probably doesn't support varargs

hmm. I was getting some issues with the reader tags at first. I was able to work around it by having the CLJS namespace require the macro namespace

should I not expect reader tags to continue to work with shadow-cljs?

here’s my current experiment: https://github.com/Lokeh/thumps

they are not supported until I hear to compelling reason why they should be

the issue is that you are doing things during read-time. so you basically have to turn of caching since it impossible to tell what its going to do

hmm. is there a significant difference between doing things at read-time vs. macro-time from the perspective of caching?

(ns my-app.core
  (:require [hiccup-next.core]
            [hiccup-next.react :refer [<>]]))

(defn Mycomponent [props]
  (let [name (goog.object/get props "name")]
    (<> [:div {:style {:color "green"}}
         [:span "Hello, " name]
         [:ul
          (for [n (range 10)]
            (<> [:li {:key n} n]))]])))

(react-dom/render (<> [MyComponent {:name "Sydney"}])
  (. js/document getElementById "app"))

what do read-tags give you that you can't already do with function/macros?

I totally get their use for actual data

not so much for pure code

the difference with read-tags versus macros is that their dependency is never declared in the code

so by looking at the ns form you can't tell that the namespace is gonna use hiccup-next.react unless you require it

and if you require it you could just use a normal macro/refer

I am starting to see the tradeoffs yes I’m just still not sure about your mention of caching. probably my naivety about how shadow-cljs works

honestly it’s just an experiment. I kind of like the aesthetics of #hiccup vs (hiccup)

you get the whole data-is-code / code-is-data thing goin’ on 😛 aesthetically

except its not

and it allows you to seamlessly do things like shove elements over the wire and back (which is something we’re doing at work atm in a different way)

the caching issue is due to the undeclared dependency stuff I mentioned

your code doesn't declare that is depends on something and therefore won't be invalidated if that something changes

ah yes, I have experienced this while developing the reader tag code

but I don’t expect that would impact people consuming it

ah, unless they register a new element keyword e.g. (register-element! :my-app/foo FooComponent)…

actually that would be in the react namespace which is required everywhere it’s used

although it’s still global mutable state in a macro namespace so would probably still have issues

yes quite bad

the one concrete thing I think I like about #h/n ... vs (h/n ...) is ease of typing 😛 I basically write hiccup like I have been trained with Reagent / hx, then stick the tag on the beginning at a few places and I’m done

but it’s not a strong technical argument

how mad will you be if other people start using it?

couldn't care less 😛

cool! 😄

FWIW I have been down this road in CLJ when it was introduced

I need a bunch of time stuff so I naturally added things like #time/duration {:minutes 30} etc

I also used it over the write and stuff so it felt great

until it got a total maintenance disaster and caused all sorts of weird issues with AOT

in the end (time/duration {:minutes 30}) works just as well and has no such issues

so if anyone wants to learn that lesson that is fine by me

but I won't be debugging any issues related to it 😉

😬 😅

yeah I haven’t tried it in CLJ much at all

I started down the road of creating a CLJ implementation of React string rendering again… then got frustrated and gave up for now

I was telling roman01la that I think it would be really nice to have a react.clj lib that was separate from a specific hiccup library / ui framework like rum / hx / uix / etc.

that would take some normalized format {:type "div" :props {...}} and implement turning those trees into an HTML string

and then the rest of us can muck about with syntax / macros / extensions and processing on top of it instead of copying + pasting and rewriting the same code

but it’s a lot of work. there’s a lot of corners of HTML to cover

I don’t think rum does it 💯

well the only way you are going to solve that properly is by not using react 😉

haha, well I think either way we have to write the code to cover those corners 😛 just React’s already done it in the browser for us!

I am seeing a clear benefit of separating hiccup and the underlying rendering engine (whether it be React’s VDOM or something else)… there’s lots of different things we can do to improve the hiccup syntax experience, extensions, etc. that doesn’t really have anything to do with rendering HTML

semantics are all that matter

otherwise is just changing (:require [hiccup-next.react :refer [<>]]) to (:require [[something.else :refer [<>]])

one thing I did in my experiments is making events declarative

[:div {:onClick (fn [e] ...)} ...] is bad for server rendered code

and annoying on the client

[:div {:on-click [:foo 1 2 3]} ...] good on the server and client

right! and separating the syntax from the engine that actually produces the resulting HTML/JS allows others to extend the semantics further without breaking compatibility with the engine

yes, things should be as declarative as possible

put another way, we could build that semantic on top of React and it would continue to work with other React components once parsed & compiled

I'm not interested in react anymore personally

yes, that’s just an example

one of the reasons people have asserted that React isn’t needed and is inefficient is because we have hiccup. that we should use hiccup, instead of React’s VDOM

and I was kind of on board with this argument for awhile, but now I think that coupling the syntax we use for writing code to the rendering engine is probably bad

there are other reasons to eschew React, but I think that “using hiccup AND <underlying VDOM implementation> is inefficient” is a problem with hiccup, not the VDOM 😛

the true superpower we have is macros so we should use them

hiccup in itself is still too inefficient

yes! 100% agreed