Fork me on GitHub
#clojurescript
<
2019-08-08
>
abdullahibra15:08:44

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

oconn15:08:06

@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 https://github.com/pedestal/pedestal. If you’re using some sort of gateway product they’ll probably have some method for request response validation (AWS’s approach - https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html). 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 🙂 https://hackernews-app.netlify.com

andy.fingerhut20:08:32

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) ?

andy.fingerhut20:08:08

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

andy.fingerhut21:08:22

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.

andy.fingerhut21:08:12

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.

andy.fingerhut21:08:35

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)))

andy.fingerhut21:08:34

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

foo
barbazguh

andy.fingerhut21:08:07

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.

andy.fingerhut21:08:10

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.

andy.fingerhut21:08:08

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.

andy.fingerhut21:08:42

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

andy.fingerhut21:08:00

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)

andy.fingerhut21:08:42

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

andy.fingerhut21:08:23

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

mfikes21:08:09

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

andy.fingerhut21:08:49

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

mfikes21:08:00

It even occurs with the “plain” supported setup of

clj -m cljs.main -re node

mfikes21:08:30

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.

andy.fingerhut21:08:00

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.

andy.fingerhut21:08:04

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.

mfikes21:08:37

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

mfikes21:08:33

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

mfikes21:08:35

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

mfikes21:08:01

lumo is Node-based and somehow gets this right 🙂

andy.fingerhut22:08:34

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

mfikes22:08:55

Welcome to ClojureScript 🙂

mfikes22:08:27

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

andy.fingerhut22:08:33

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.

andy.fingerhut22:08:25

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?

mfikes22:08:23

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 https://blog.fikesfarm.com/posts/2017-07-17-cleaner-clojurescript-react-native-interop.html

mfikes22:08:38

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.

mfikes22:08:11

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

andy.fingerhut22:08:19

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.

andy.fingerhut22:08:42

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

mfikes22:08:52

Oh, cool. 🙂

mfikes22:08:45

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

mfikes22:08:25

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

andy.fingerhut22:08:50

ok, will give that a shot first. thx

andy.fingerhut22:08:16

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

andy.fingerhut22:08:49

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

andy.fingerhut22:08:38

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.

andy.fingerhut22:08:23

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

andy.fingerhut01:08:22

Thanks for the help and suggestions, @U04VDQDDY. I turned them into a proposed patch for ClojureScript: https://clojure.atlassian.net/projects/CLJS/issues/CLJS-3153 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: