My usecase for this heresy: I'm trying to practice some so-called "Domain Oriented Design" where the business logic closely matches the common sense notions of the business rules. I'm trying to make it open for extension but closes for modification, so I want the code to be polymorphic and compile-time extensible. I can do this with defprotocol/defrecord but it's too slow and there's too much code duplication, so I'm dipping into typescript. However -- I want to use all the cljs functions. Then I want to use those datatypes in my clojurescript library code. Then I want to use the clojurescript library code in the javascript functions to make more sophisticated datatypes. Then I want to use THOSE more advanced datatypes in the clojurescript app code.

More detailed notes:

// baseData.ts

    get: () => any
}

interface ISettable<out T> {
    set(x: any): T;
}

export interface IGetSet<out T> extends ISettable<T>, IGettable {

}

type MapType = cljs.core.PeristentHashMap | cljs.core.PersistentArrayMap;

export class MyData implements IGetSet<MyData> {
    cljsData: MapType


    constructor(data: MapType) {
        this.cljsData = data;
    }

    get(): any {
        cljs.core.get(this.cljsData, cljs.keyword("data"))
    }

    set(x: any): MyData {
        let existingData = this.cljsData;
        let path = cljs.keyword("data");
        let newData = cljs.core.assoc(existingData, path, x);
        return new MyData(newData)
    }
}

(ns somens.core
  (:require ["./path/to/src/gen/baseData.js" :as my-data]))


(defn ^:export fancy-cljs-fn [my-data]
  (.set my-data 42))

// fancyData.ts
import {fancy_cljs_fn} from "???"; // help needed
import {IGetSet, MyData} from "./baseData";

class FancyData implements IGetSet<FancyData> {
    mydata: MyData;

    constructor(data: MyData) {
        this.mydata = fancy_cljs_fn(data);
    }

    get(): any {
        return this.mydata.get();
    }

    set(x: any): FancyData {
        let newData = this.mydata.set(x);
        return new FancyData(newData);
    }

}

(ns fancyns.core
  (:require ["./path/to/src/gen/fancyData.js" :as fancy]))

(defn ^:export super-fancy [fancy-data]
  "yay")

wtf xD for requiring cljs in JS, there's the doc : https://shadow-cljs.github.io/docs/UsersGuide.html#_access_cljs_from_js import {fancy_cljs_fn} from "goog:somens.core" Did you already try it?

Ohhh ok I thought that "goog:cljs.core" was a hardcoded constant or something, didn't realize that was extensible

Ok there's no way this is possible in the same compiler pass.

Or is it :thinking_face:

Don't know but I want to know 😅

The JS file is not processed by shadow, it is used directly as it is, so I think it should work. With a parallel TS watcher of course.

this will be wild

I think it's gonna work but ran out of time

will try again soon

damn it actually works

I can't even believe this works 😮

I think this must be what Voldemort felt like when he got into the blood magic section of the library

nice, hope your new weird stack will fit your needs

It will I think as soon as I get hot reloading to work!

Okay at the bottom of https://shadow-cljs.github.io/docs/UsersGuide.html#_javascript_dialects it mentions this:

but I'm not observing this behavior

are you sure your js files are in your source paths ? hot reload works for me

ok, probably on my end then

does it watch subdirectories, too? so for instance if I have src/gen in :source-paths, will it watch src/gen/sub, or do I need to mention that explicitly?

Even when I delete the js/cljs-runtime/module$cljstable$baseData.js, it gets rebuild with the unchanged code

this makes no sense, unless you have a second js source file with the old code. Or could it have cached the old result somehow ? I don't see why

yeah, ripping my hair out about it

will try to start with a fresh project 😞

uuugh yeah with a fresh project it works. there's some garbage artifacts somewhere. good call @U02F0C62TC1

tangential, but your cider-nrepl (and most notably refactor-nrepl) are outdated :)

Yeah not sure how to fix that when doing cider-connect-cljs

Ok I FINALLY figured out what it was... sort of

working:

not working:

so it seems that I need to reference at least one of the js file in the :init-fn namespace in order for shadow-cljs to recognize a recompile

> Yeah not sure how to fix that when doing cider-connect-cljs You'd have to have a look at whatever is your nrepl server (maybe some webapp?)

yarn shadow-cljs watch frontend then whatever cider does when connecting

yeah, confirmed, there needs to be some kind of reference to the javascript file in the :init-fn namespace in order to recompile... phew... thank god... can move on with my life now...

taking a quick look at the docs, looks like shadow-cljs picks up whatever cider-nrepl version is defined in either your project.clj or deps.edn. The docs also reference a ~/.shadow-cljs/config.edn file, although it looks like it's not much advised

@U3BALC2HH as a general rule: shadow-cljs only compiles files that are actually required in a build. so :init-fn is following all :require in the namespaces (or import in JS files) and compiles those. a file that is not required is not compiled, as you learned 😉

also when using :deps true the :source-paths config in shadow-cljs.edn has no effect. you should be warned about that on startup, but depending on how you start things that may not be visible (eg. emacs hiding it in some buffer)

:middleware [cider.piggieback/wrap-cljs-repl] this you don't need at all

as a general warning the JS support is not widely used and can cause issues with externs in release builds. since there is no externs inference those might be hard to debug later

Makes a ton of sense when you put it like that. There were so many moving parts with that typescript debauchery that I got lost in the sauce

dunno, nobody ever attempted to get it there?