Fork me on GitHub
#clojurescript
<
2018-11-24
>
polymeris00:11:57

I didn't find any library to subscribe to GraphQL from cljs/Node (all of them either use only HTTP or asume you are in the browser), so came up with this, maybe someone finds it useful: https://gist.github.com/polymeris/d20a5a2aad02fa83f36ee0b57ed96496

darwin00:11:06

any ideas how to get around https://dev.clojure.org/jira/browse/CLJ-1625? I wanted to have all protocols in one namespace[1], but that does not work when protocols happen to have same method names 😞 [1] https://github.com/binaryage/chromex/blob/master/src/lib/chromex/protocols.cljs

thheller09:11:27

@darwin having the same name in the same ns is never gonna work. how would the user even distinguish what to call?

darwin11:11:54

@thheller via protocol identifier?

thheller11:11:46

but you call (chromex.protocols/subscribe! ...)? how would there be two or more?

darwin11:11:38

well I’ve never had deep thought about it, I was using protocols with this pattern, and never hit this problem with same names

darwin11:11:39

I was thinking that protocol name is somehow involved in the lookup and it happens under the hood, e.g. chromex.protocols/subscribe! is just a sugar for chromex.protocols/IChromePort:subscribe! if not ambiguous

darwin11:11:44

or something like that

thheller11:11:08

still requires it to be unique (per ns)

darwin11:11:36

no, in case of non-unique names, you’d use full qualification with protocol name in it

thheller11:11:37

the names are unique internally so you can have the same name from different namespaces

darwin11:11:42

nevermind, now I know how it works, and I will have to put procotols into unique namespaces

thheller11:11:00

just choose unique function names in the first place

thheller11:11:08

then you don't have that issue at all 🙂

darwin11:11:23

I cannot in this case, the names are following API names

thheller11:11:10

well you already seem to be bending those rules with subscribe!?

darwin11:11:37

not using -subscribe!?

thheller11:11:39

its not a valid JS API name?

darwin11:11:07

well, I just have a convention how to translate API names into clojure protocol names, I just want it to be consistent

darwin11:11:22

I didn’t want to say, I take them literally

darwin12:11:16

and even without this case, I might strongly want to “reuse” nice names even if I were free to pick my own names

darwin12:11:50

now I have a secondary problem, I decided to bit the bullet and move protocols into separate namespaces, but wanted to produced user-friendly error for someone using my lib and having code using old protocols, something nice with explanation where to find replacements

darwin12:11:04

I was unable to find any solution to this

darwin12:11:59

my first approach: I wanted to emit an error when someone requires chromex.protocols, it worked, except in debug builds all cljs files are compiled, and that was triggering the error even if nothing was using the namespace

darwin12:11:41

my second approach was to mark protocols somehow as “moved”, or forward them to proper places, didn’t find a solution

thheller12:11:56

(ns chromex.protocols) (throw (some-nice-error))

thheller12:11:10

only breaks at runtime though

thheller12:11:31

other than that you can just "forward"

darwin12:11:47

yeah, I wanted compile-time error, but maybe adding this won’t hurt

thheller12:11:00

(ns chromex.protocols) (defn subscribe! [target ...] (something.else/subscribe! target ...))

thheller12:11:17

as far as the calling is concerned that is about equal

thheller12:11:37

not sure if users actually implemented the protocols are used them directly

darwin12:11:38

aha, interesting

darwin12:11:55

no, users are expected only to call stuff, if I recall correctly

thheller12:11:29

from the users perspective a protocol call looks just like a function call so you can swap them easily

darwin12:11:12

thanks for the hints, I think this will be good solution, I will forward all existing protocol methods with a warning, and if someone used protocols for implementation they get some standard compiler warnings about missing protocols and will have to investigate it themselves

souenzzo15:11:20

why cljs.core always use deftype and never defrecord ?

thheller15:11:05

you don't always need to extra features defrecord provides so deftype is better for those cases

mfikes15:11:09

Also, stepping back a little, cljs.core is really defining the fundamental implementation of types, where it is appropriate to use deftype. There's a mini Twitter discussion on the subject here https://twitter.com/mfikes/status/1017840912855117825

👍 1
alza18:11:54

Can anyone explain this difference, Clojure vs ClojureScript? With Clojure:

user=> (do (print ".") (print "."))
..nil
With ClojureScript (on NodeJS):
cljs.user=> (do (print ".") (print "."))
.
.
nil
On ClojureScript, where are the newlines coming from? I'm using print not println

mfikes19:11:07

@alzadude Normally setting *print-newline* to false would be sufficient, but there may be some limitation to the shipping Node REPL.

lilactown19:11:06

in Lumo, (do (print ".") (print ".")) acts just as Clojure

souenzzo19:11:47

@mfikes

$ clojure -Srepro -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.439"}}}' -m cljs.main --repl-env node -e '(do (print ".") (print ".") (prn *print-newline*))'
.
.
false

souenzzo19:11:06

with-out-str works as expected. Can be something with JVM<>Node

~ clojure -Srepro -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.439"}}}' -m cljs.main --repl-env node -e '(prn (with-out-str (do (print ".") (print ".") (prn *print-newline*))))'
"..true\n"

thheller20:11:03

@alzadude it is printed using console.log which always adds a newline