But wouldn’t spec be a great feature to add to existing libraries? And can’t you partially add specs (For example, at the interfaces)?

I'm not saying it's neccessarily a bad idea, I'm saying this is why it hasn't happened

most clojure libraries don't need to be updated very often

most clojure libraries don't need to be updated very often This is something that I’ve noticed also. Some of the recommended libraries were last updated 3/4/5 years ago. Makes me pause a bit before I use them. What is the reason for that really?

because they operate on immutable data or stable java interfaces

if the world doesn't change underneath them (even for security updates you would just update the java lib yourself, no need to change the clojure lib)

so unlike many ecosystems, in clojure you really do see code that is seemingly "done"

Wow, makes sense when you explain like that. That’s a huuuuge +++ isn’t it?

indeed, it's a big payoff of good decisions in the design of clojure (and java and the jvm)

(and you'll notice cljs is less stable and has more deployment churn, because it's built on shakier ground)

👍

Your using CompjureApi the lib? or you built an api using compjure?

for reference: https://github.com/metosin/compojure-api

I would debug this by running the compjure client with the request: something like: https://github.com/drewverlee/plum/blob/master/src/plum/handler.clj#L22

In general, with clojure, you have to reach for a step through debugger less often because a) your writing smaller pure functions b) the repl gives you the feedback you would want from the debugger. This isn’t always true, for good reasons. In that case, i would start with print and pull in more techniques as you have time.

also, a good place to ask more questions is probably ring-swagger

@U0DJ4T5U1: Using compojureAPI the lib. My question was about my handler not being invoked when a request is sent from a client. (Turned out that the request was buggy - content-length was wrong). I had no idea how to figure out why the request is not reaching until my handler invocation. And how to see where it gets stopped.

Hmm. Yes, in that case a debugger might help.

error message seems self-descriptive enough, there is no such var clojure.core/cheshire.core. Where do you use it?

And it's doubtful clojure.core/cheshire.core is a real thing. Probably a typo.

perhaps in the ns definition

@U050PJ2EU yes it is!Confused with bracket in lisp way of coding..

Now installed plugin in atom which automatically deals with the bracket which i not supposed to care..

I think it's LEIN_HOME

I started with environ because that's in chestnut.

The current pieces of config data that differ are the db connection url, the web address against which the cljs makes its xhr/fetch requests, and now an asset path for the webserver to use to collate PDFs together on the fly from a set of a few thousand.

so environ is fine for the first and third (clj concerns), but I haven't been able to use it for the front-end XHR url, since (obviously) the browser doesn't have an environ.

I tried the trick of making up a macro that does use environ and burning it in at the time I build my uberjar ... couldn't get that working but adzerk/env seems to have done the trick (and I understand it's doing roughly the same idea on the cljs side).

anyway now juxt/aero has caught my eye ... I have broad philosophical agreement that config should mostly just be a file instead of a dozen env vars (not including secrets, of course).

and generally tools like direnv and using profiles.clj seems to take care of that.

but the thing that seems to make this all a bit weird is my possibly-misguided way of configuring the XHR endpoint on the client side

Anyway, long story. Hoping there's a more intelligent way to deal with separate envs for back- and front-end.

@U08BW7V1V there are a good number of config libs out now for clj/cljs

Some of them have goals of reaching both the server and client side

So far, I’ve used environ in a simpler project, and juxt/aero in a more involved config project

I’ve just loaded config on server and let the client get some of that config via a REST request. That may not be appropriate for you though

thanks ... the chicken-and-egg thing I'm not seeing clearly enough is, how can I pull down config from an endpoint if the endpoint is part of the config?

Yeah, I detected you may have that concern 😛

haha

There are ways to do it ad hoc, like building the URL into the initial document (html generated on server side can use config)

that may not be suitable for you either

well, that'd probably work ... I was close to breaking out sed as a part of jar construction.

but you can do some server-side rendering of your page that loads your js and all that too

just seemed like I was reinventing something that probably exists.

ooo.

that might work

I’ve used server-side rendering of the “index.html” page to splice in some simple config values before

it is a real minimal approach. The libs that exist that transport the config from server-to-client, probably build it into the js somehow (haven’t looked)

trying to find one of those more recent libs for config, but can’t find it immediately. I know I’ve came across like 2-3 config libraries recently that may do some stuff for you

yeah, adzerk/env seems to burn it in using a macro.

https://github.com/jarohen/nomad

yeah, I’m sure there are tricks to doing it

I haven’t dove into these server+client config libs yet. Still using juxt/aero and I’ve used the server-side rendering trick the few times I’ve needed it

maybe if you can get your URI out to the client, then the client can just http for the bigger config stuff hah

It really all depends on the situation I think

oh neat... that looks aero-esque but with the cljs side.

I believe that nomad is a pretty popular config lib out there right now

I’ve considered trying it out before long. I like some things with juxt/aero design-wise better I think. However, they aren’t necessarily taht different from one another I don’t think. And nomad may give you smooth clj + cljs side config sharing

<immediately rips out all current config code and stall feature progress>

hah, yeah

cool ... the crux for seems to be swapping out the XHR endpoint so I was hoping there was a well-trodden path there.

everything else seems do-able with straight-up environ.

sure, you could do the server-sider rendering trick then for tha tif you wanted

like you could put a <script>var myUrl=<url-from-config>

hiccup makes generating the server-side html pretty smooth on the clj side

if you aren’t needing anything too fancy.

Ends up looking like:

(require '[hiccup.page :as hicc]
         [hiccup.element :as elem])

(defn app-index
  [config]
  (hicc/html5 {:lang "en"}

              [:head
               [:meta {:charset "UTF-8"}]
               [:meta {:name "viewport" :content "width=device-width, initial-scale=1"}]
               [:title "My App"]
               ;; Whatever CSS
               (hicc/include-css "css/style.css")]

              [:body
               ;; Where yo you are hooking on your React rendering presumably
               [:div {:id "app"}
                [:h2 "Loading..."]]

               (elem/javascript-tag (str "var myUrl=" (:my-url config)))
               (hicc/include-js "js/compiled/app.js")

               (elem/javascript-tag "my.client.app.init();")]))

You could pass config then from environ since this is on the clj/server side

Just have to make sure whatever you splice in is in the appropriate format, such as a valid JS string for the myURL above

Your client-side could then access this via js/myUrl

Oh cool. It also just occurred to me I could also string replace on the initial js bundle going outbound, instead of a straight-up static file response.

Or do string replace on the index.html to do the trick above, instead of necessarily generating hiccup.

yes, I think I understand what you mean and that is a possibility

It also just occurred to me that nomad may not be the lib that shares clj to cljs config. I think I confused it with another. Just FYI since I may have been misleading there. I’d have to do some config lib research again to see what’s out there at this point hah.

user=> (= (#(flatten (zipmap %1 %2)) [1 2 3] [:a :b :c]) '(1 :a 2 :b 3 :c))
false

oh right, flatten ignores hash-maps

could you elaborate?

Note that maps aren't ordered

so, there's no guarantee of the order... is that why it could be failing on 4clojure?

Maybe, IIRC 4clojure uses an ancient version of clojure, so you're probably on a different version than they are.

hm, ok. I guess the only way to really find out what's going on is to run it on my own box

you don't need the flatten

ah my bad. read the question wrong. You just need to change the vector to a list

#(flatten (into '() (zipmap %1 %2)))

well, hmm... some of the require results aren't lists... but it passes

hmm... so why does that work but [] does not?

mmm. afaict, the problem is not constructed right

(#(flatten (into `() (zipmap %1 %2))) 
  [1 2 3] [:a :b :c])
;=> (3 :c 2 :b 1 :a)

That passes, but they're clearly not in the right order

Zipmap returns an unordered type, you can eg map list over two collections instead

I figured. The problem is broken though, right? It should fail on that.

it’s allowed to have an order, it’s not guaranteed to scramble the order