Fork me on GitHub

Hello guys for rest API design, how separating the validation of request and response from the business logic code? (edited)


@abdullahibra depends on your stack - typically this is accomplished by using something like middleware (express for node and a lot of other frameworks) or interceptors if you’re using If you’re using some sort of gateway product they’ll probably have some method for request response validation (AWS’s approach - It really depends on the stack.

Faisal Hasnain17:08:33

cljs Open-source Hacker News Reader built using ClojureScript & #re-frame. Any code reviews or suggestions for improvements are most welcome 🙂


When running in a Node-based ClojureScript REPL, is it normal for all print calls to cause a newline to be printed at the end (not println -- print) ?


And is there some configuration or other small change I can make to prevent print from appending a newline?


My peeking and poking around has led me to find *print-fn*, and I see that I can override that myself if I want. So I am trying out that approach.


So a little Google searching led me to find the existence of process.stdout object in Node.js, which has a write method that can take strings.


I write this function, full of hope that it is on the way to my dream:

(defn write-multiple-strings [& strings]
  (doseq [s strings]
    (.write js/process.stdout s)))


And when I evaluate this (write-multiple-strings "foo" "bar" "baz" "guh"), I get a very odd printed result:



It seems that no matter how many arguments I call write-multiple-strings with, the first string is printed, then a newline, then the other strings are printed without a newline after them. I just don't even know how to make sense of that yet.


It is somehow as if something in the implementation of process.stdout write method knows whether I am going to call it again from within write-multiple-strings? I would gladly pay $10 for someone to explain this behavior, because it will easily cause me that much time of wondering.


More data -- it behaves weirdly as described above when I am running over a socket REPL from inside of Emacs inf-clojure so perhaps something in that stack is messing with things.


When I start a Node-based REPL from a terminal with this command, no newline is injected in the middle: clj -Sdeps "{:deps {org.clojure/clojurescript {:mvn/version \"1.10.520\"}}}" -m cljs.main --repl-env node


OK, and when I use telnet to connect to the Node-based REPL, without Emacs or inf-clojure involved, also looks good (no extra funky newline)


So this looks like it is probably something strange in inf-clojure, probably.


Shaving 1 yak is enough for now. I will not attempt to also shave the inf-clojure yak today (or probably ever)


Hey Andy, I think this is a long-standing issue with the Node REPL…


Issue, as in you wish ClojureScript out of the box behaved differently?


It even occurs with the “plain” supported setup of

clj -m cljs.main -re node


I think I fought with this one in the past… I wonder if it led to a JIRA or I found a good reason to give up.


I have an alternate definition of function enable-util-print! in file src/main/cljs/cljs/nodejs.cljs that looks like it will do better in this regard, if you are interested.


Although I do not know how stable it is across different versions of Node.js -- it uses (.write js/process.stdout s) to write strings without a newline.


The maybe-enable-print! stuff near the bottom of cljs.core might be relevant as well.


It probably takes the (exists? js/console) cond branch.


Maybe a branch would need to be added prior to that one for *target* "nodejs" that sets up a better print facility.


lumo is Node-based and somehow gets this right 🙂


I am learning from your description of the dizzying variety of environments available. 🙂


Welcome to ClojureScript 🙂


ClojureScript has reach, which is usually thought of as a good thing 🙂


I am not sure if I have the activation energy required to try out proposed changes for all of these environments, but am definitely happy to try out a variant or two for a Node-based REPL. I suspect that is a drop in the bucket compared to what needs to be tested, though.


Would it be more help than busy-work for you if I tried out a variant with a new cond case for *target* "nodejs" in maybe-enable-print!, that seemed to work for me?


What scares me is things like re-natal which is for building React Native mobile apps, which ends up using this Node-based bundler process, and re-natal specifically sets the *target* to Node, which I now think of as an abuse, even though I wrote about it in


In short, it is nearly impossible to come up with a perfect answer for all of these strange environments. I would suggest it is OK to limit consideration to the shipping Node REPL, and let time prove whether any given patch suffices for non-shipping environments.


In other words, I’d try seeing if *target* "nodejs" in maybe-enable-print! flys.


Understood. I have a solution that I am happy monkey-patching *print-fn* for my local dev. If you'd like a patch that relies upon (.write js/process.stdout s) for *target* "nodejs", that sounds easy for me to cook one up, but again, not sure if it helps.


Looks like I might learn how to build ClojureScript from source today 🙂


Oh, cool. 🙂


FWIW, you don’t actually have to build it. You can use it as a :local/root or even a :git/url dep.


So one dev workflow is to make a change, and then test it by specifying ClojureScript as a :local/root dep.


ok, will give that a shot first. thx


Well, I definitely know :local/root is working after accidentally introducing a syntax error 🙂


At least in my Node-based REPL, the fn maybe-enable-print! is called with *target* bound to "default", not "nodejs"


That is the case regardless of whether I create a Node-based socket REPL, or use -m cljs.main --repl-env node when starting ClojureScript REPL from a terminal command.


BTW, Clojure atoms for the debug logging win, when messing with how print functions work 🙂


Thanks for the help and suggestions, @U04VDQDDY. I turned them into a proposed patch for ClojureScript: The patch might be inadvisable for all kinds of reasons I do not know yet, so don't hold back on suggesting alternatives, if you think of any.

Godwin Ko22:08:26

what’s the proper way to handle build env variable in clojurescript project? so far I only find closure-defines, but its usage is a bit cumbersome, and I’m not sure if that’s the proper usage of it… :thinking_face: