like read env from within a clojurescript file

and which target do you use? I mean does it run in the browser or node? do you just want to access the env during compilation to get some token into the code? or do you want actual runtime environment?

It rusn in a browser I need it during compilation

i want to set some secret variables

@U028WS6K23G check out aero: https://github.com/juxt/aero

it was recommended in this discussion: https://clojurians.slack.com/archives/C053AK3F9/p1631841538094500

thanks

thanks @U4YGF4NGM! > I think the second example is a function of protocols not being reified, and therefore intentional now sure what you mean, it is refied?

(ns domain)

(defprotocol Kikka (-do [this]))

(def k (reify Kikka (-do [_] "doing")))

(-do k) ; => "doing"

(satisfies? Kikka k) ; => true

(implements? Kikka k) ; => true

(instance? Kikka k) ; => false (this differs from Clojure

In my case, I have tens of reified instances, could make all also satify the IPrintWithWriter, but it would be a lot of boilerplate. In Clojure, I can just define it once for all reified instances.

also, I think I could implement the IPrintWithWriter for js/Object and read the :type metadata there and dispatch with that - but this is a library (malli) and I don’t think it’s a good idea to have such global things in a library.

by "reified" i mean literally, there is no concrete object created by defprotocol.

I guess in testing this isn't totally true, even though this is what's said in the "differences" doc on the clojurescript website. in Clojure defprotocol creates a class, but in CLJS it does not. it creates a function which it only seems to use to do some minor book keeping. it doesn't add it to the prototype inheritance tree and I would expect in a release build it would DCE the function created by defprotocol

implements? and satisfies? both operate at compile time. you cannot, for instance, pass around a protocol as a value

is there some reason you're using reify all over the place in your lib, rather than a deftype?

I have currently modelled things via reify as the components (schemas) have a three-fold life-cycle (https://github.com/metosin/malli/blob/master/src/malli/core.cljc#L444-L481) 1. creating schema types (line 444) - done once to configure the schema system (“all maps are closed by default”) 2. create schema instances from (line 452) - “the map has keys x & y” 3. creating schema workers, e.g. value transformer (like 468) - “give me a (pure) function to transform values from JSON-domain to EDN for this schema) … using reify is nice here, as I can share and precompute things in the parent closures (in 1 & 2) and they are available for 3. With deftypes, I think it would be a lot more parameter passing around. Not sure if the current design is good, but that’s the way it is today. And - a lot of reify all over the place.

and thanks for your time explaining the differences.

I’m not looking for detailed code or anything, but I’m curious if this seems feasible given the way CLJS works.

are you talking about getting correct links in stack traces via source maps, or are you trying to do something programmatically in your app code?

chrome devtools understands source maps, so you can include them in your bundle to get line numbers and (at dev time) view the code in devtools.

This is not fully thought out, but basically I’m trying to reproduce what devtools does at the REPL or in tests. When an errors occurs e.g. at the REPL, I’d like to be able to work backwards from the line number and filename to show the source code that produced the error.

So I guess I’m trying to understand if, at the REPL, I can get access to that source map info to display the original source code.

you can do that at the REPL yeah. here is a basic code snippet to map a line back to source https://clojureverse.org/t/server-side-decoding-of-javascript-sourcemaps/1591/3?u=thheller

I wrote a helper for graaljs exceptions doing exactly what you asked since they don't support source maps natively and errors are otherwise unusable

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/graaljs.clj#L79

basic thing you could adapt for other platforms

@U05224H0W Thank you so much! This is incredibly helpful.