How to check during compilation time if should I make atom using: reagent.core/atom or atom. I wrote library which make atom to validate-form, but I would like to have it compatible with the most popular libraries. So if somebody use reagent I want to make atom using reagent.core/atom, if not use atom.

@kwladyka you could allow the user to configure it via :closure-defines

it is one of the option, but I would prefer over it detect if developer use reagent or not and then use right one

anyway as I understand this value can be string / number / boolean so I can’t refer to right atom function

i guess this question is more broadly related to javascript in general, but what is a good strategy for having different types of endpoint configurations in the clojurescript code depending upon which environment it is being deployed in ? the most obvious solutions i can think of is providing an argumen to the build (thus hardcoding endpoints in the javascript, suboptimal), or to assume the host that serves the js bundle has $some endpoint that provides configuration data (like an /config endpoint, an additional round-trip, but more flexible)

any other strategies that work well ?

the last i thought of was "just-in-time" compilation of all clojurescript code and injecting the endpoints dynamically that way, but this is also suboptimal for various reasons

I don't see why setting this via the build is suboptimal

but then you would need to know the endpoints that will be used in advance, not ?

i.e. you cannot deploy the same code in multiple environments

(fwiw, i am totally not a frontend developer, so i'm approaching this from a backender's perspective)

Krzysztof’s question was regarding compile time—for this :closure-defines is ideal

@lmergen you can build N times for each environment

pretty standard practice

ok

it's the simplest i guess

:closure-defines is all you really need

ok

@mfikes why not macro?

@kwladyka see the sidebar regarding macros in https://clojurescript.org/news/2018-03-28-shared-aot-cache

> In those situations, it is recommended that libraries and tooling employ goog.define instead, perhaps with the help of :closure-defines, as this makes JARs cache-friendly. Oh so it is only one option then. Right?

No alternatives.

yes - it's just the right and supported way to do configuration

goog-define will create a specially-handled var in a namespace of your choosing and you can document the qualified symbol for consumers of your library to use with :closure-defines

You can then write conditional code testing that var’s value which will effectively be done at compile time if the library consumer is using :advanced, all while being compatible with :aot-cache

I suppose for the Reagent atom case, on one branch of the code you would use interop to construct a Reagent atom

(Assuming your library isn’t actually requiring Reagent itself)

as a consumer of a library, I would much rather pick which one to use

stuff that creates problems for future leverage of :aot-cache should just not be under consideration

we need to stop using macros unless we absolutely need them

thanks for explanation

Is there any way how I can return multiple values for a reagent function? In Javascript there is a special element that does not get rendered to the dom, so similar to a div, but not put into the dom. I just cannot find this approach for reagent. Any ideas?

@andrea.crotti in #reagent you can use fragments just like in regular React

the hiccup is :<>, e.g.:

[:<>
  [:div "foo"]
  [:div "bar"]]

<>
  <div>foo</div>
  <div>bar</div>
</>

thanks so much!

I haven't been able to find the :<> symbol 🙂

yeah I’m looking for the correct docs rn

reagent is not very organized. a lot of the docs are in the re-frame repo too 😅

I just learned re-frame yesterday,

and I love it.

The syntax is so precise; my react/redux apps they are blown up on I think 10 files, just for a basic app.

And with re-frame, all the code is so clear to understand, and very short.

But docs, this is the huge missing thing.

I spent I dont know how many days, just to get a few material-ui components going,

and I haven't even had a look at more complex material-ui componets.

hahah

{:names->value {:email ""
                                  :password ""
                                  :password-repeat ""}
                   :names->validators {:email [::sc/email]
                                       :password [::sc/password]
                                       :password-repeat [?password-repeat]}}

(-> @form
              (pprint)
              (with-out-str))

{:names->value {:email "", :password "", :password-repeat ""},
 :names->validators
 {:email [:form-validator-demo.spec/email],
  :password [:form-validator-demo.spec/password],
  :password-repeat
  [#object[form_validator_demo$views$_QMARK_password_repeat]]}}

What’s the recommended way for a library to opt-in to accessing private variables without triggering a warning? My understanding is that future versions of CLJS will have a warning for private variable access (which is great!) but I’m not sure how to write code that will work both before and after ana/*private-var-access-nowarn* is introduced

If I try to always bind ana/*private-var-access-nowarn* true, then that will produce a warning in older CLJS versions. But if I omit it, then presumably the private var access will trigger warning in upcoming versions of CLJS

@kwladyka the issue is that it is printing a function value, which has never really had a decent way to print how that value was defined. One option is to (set! *print-fn-bodies* true) to see the JavaScript implementation of the function value

(I’m presuming you are dealing with a function value—perhaps it is actually some other object type.)

@bbrinck you could use the var special

@mfikes Hm, I’m afraid I’m not sure how to use that in a binding form. I want to do something like

(binding [ana/*private-var-access-nowarn* true]
  ;; some private var access  
)

do you mean I should wrap ana/*private-var-access-nowarn* in var e.g. (var ana/*private-var-access-nowarn*)?

I just mean, do it like you would in Clojure. So, for example you could do

#'clojure.string/replace-all

ahhhh

This leads to a little var bloat in the generated JavaScript.

gotcha, you’re saying I should just use #' to access the private function (like in CLJ) instead of trying to mess around binding a (possibly non-existent) dynamic variable like ana/*private-var-access-nowarn*

good idea, it looks like that worked. thanks!

Well, since you mention that dynamic var, it makes me think I may not be understanding what you are doing, maybe you are in Clojure

Sorry, dynamic var is likely the wrong term in CLJS

To zoom out a little, I want to call a private function in CLJS without issuing a warning, regardless of CLJS version (I understand I’m depending on implementation details, and I’m ok with that)

My first idea was to just call the function directly and wrap the call in (binding [ana/*private-var-access-nowarn* true] ,,,), which AIUI, would avoid the warning in new versions of CLJS

but now I’m going to try just using #' to call the private function, as you suggested. I’ll let you know how it goes.

See https://github.com/clojure/clojurescript-site/blob/a9943dad32db388f80f7b1b551e3bf6c03128274/content/news/2018-09-01-release.adoc#warnings-on-private-var-use

And vars in operator position are automatically derefed so no need to use @

Perfect, that’s super helpful. Thanks!

is it possible to write a macro that instruments something at the start some body given as an argument and unstruments something at the end reliably in clojurescript? there seems to be something going on with instrument/unstrument at macro compilation time

It can probably work, but instrument/unstrument is very static currently due to trying to support advanced compilation