Fork me on GitHub
#clojurescript
<
2016-09-16
>
borkdude08:09:26

In the newest ClojureScript, require-macros was no longer needed, right?

joost-diepenmaat08:09:39

IIRC you can do :require just like in clojure

levitanong08:09:31

I think it depends on the library. for core.async, the only thing that works for me is :require-macros

joost-diepenmaat08:09:48

Implicit macro loading: If a namespace is required or used, and that namespace itself requires or uses macros from its own namespace, then the macros will be implicitly required or used using the same specifications. Furthermore, in this case, macro vars may be included in a :refer or :only spec. This oftentimes leads to simplified library usage, such that the consuming namespace need not be concerned about explicitly distinguishing between whether certain vars are functions or macros. For example: (ns testme.core (:require [cljs.test :as test :refer [test-var deftest]]))

joost-diepenmaat09:09:02

if I read that right you cannot require / refer macros directly in a library implementation (need to use :require-macros), but if you do and the macros are in the same namespace as the lib, users of the lib can use :refer and :require for macros as well as functions.

pesterhazy09:09:16

I'm trying to convert ES6 style imports (`import foo from 'bar'`) to clojurescript and often discover that what I get when I call require is an object with a key default. What's that about?

tap09:09:12

Is there any Om Next alternative where I can use datomic pull syntax to describe frontend data query?

reefersleep10:09:09

@tap: Maybe Posh is what you're looking for?

tap10:09:34

@reefersleep Thanks. I’ll a look at it

plexus12:09:24

@pesterhazy not sure if related but reading your question this came to mind http://dev.clojure.org/jira/browse/CLJS-1620

pesterhazy12:09:23

@plexus this is interesting but also surprising. Does this mean that I can (require) js libs with today's cljs compiler?

pesterhazy12:09:58

that's going to be so useful

plexus12:09:50

this relates to using :module-type, so letting Google Closure convert from ES2015 to its own goog.require stuff

plexus12:09:48

yes, it works today, but for a lot of code "in the wild" don't expect it to be a great experience

plexus12:09:12

been playing with it for a few days now, main takeaways: CommonJS and AMD modules are supported, but most schemes that libraries use to "detect" what module system they're in will cause it to fail, see http://dev.clojure.org/jira/browse/CLJS-1777?focusedCommentId=43857

plexus12:09:50

I'm guessing most ES2015 modules don't do funky things like that so there it's probably less an option

plexus12:09:47

the other thing is that for real world projects where code is split in many modules, and has dependencies on other projects, you need to add an entry to :foreign-libs for each of those, and then hope that Closure figures out the imports correctly (and that the code doesn't violate the Closure assumptions to begin with, or you'll get stuff like "Warning: unsafe use of global 'this'")

plexus12:09:29

generating the :foreign-libs could be solved with tooling. GC will have to get better at consuming/converting funky UMD modules, so we can start testing it on real world libraries

plexus12:09:59

and maybe then we find out that most of that code is inherently unsuitable for GC's analysis and processing...

plexus12:09:25

so yeah, "it works, but"

pesterhazy12:09:01

very interesting

pesterhazy12:09:20

well I don't sweat the foreign-libs issue as you can get around it:

(some-> (aget obj "method")
          (.call obj "param"))

pesterhazy12:09:07

(I also use some-> in case the library is not available but that's obv not necessary)

plexus12:09:34

I'm not sure we're talking about the same thing. The correct :foreign-libs is necessary for a successful compilation. If you try to use :module-type but GC can't correctly convert the module, either the build won't work, or you'll end up with a broken result. Not much you can do about that at runtime

pesterhazy12:09:09

oops, I was thinking of externs

pesterhazy12:09:46

I'm obviously still fuzzy on the terminology 🙂

plexus12:09:45

yeah in this case you don't need externs that's kind of the beauty

tomjkidd12:09:19

I'm trying to add unit tests to a lein project, and I am finding stuff, but is there an official way?

tomjkidd12:09:50

Most of the options seem pretty custom

tomjkidd13:09:48

@pelxus thank you, I'll see if I can get it configured...

Jon13:09:42

how can cljs code tell which env it's running in, browser or nodejs?

anmonteiro13:09:30

@jiyinyiyong

(if (and (exists? js/module) (exists? js/module.exports))  
  (do node stuff)
  (do browser stuff))
?

Jon13:09:40

exists? is probably what I need

Jon13:09:10

I thought it was some? not failed

anmonteiro13:09:16

exists? is cljs.core/exists? btw

anmonteiro13:09:33

which is to say, nothing that you need to implement yourself

Jon13:09:14

I can only think of (js* "typeof x") without using exists?

anmonteiro13:09:01

@jiyinyiyong there’s also goog/typeOf, you don’t need to do funky js* stuff

xcthulhu14:09:50

@jiyinyiyong If you find yourself writing a lot of (js* "...") blocks, consider just making a pure .js module. You set it's namespace with goog.provide() and include other ClojureScript or JavaScript files with goog.require().

xcthulhu14:09:09

You'll need to set JSDoc comments as you would an extern file.

plexus16:09:44

what's the way to use a Closure "namespace" from CLJS? i.e. a JS file with goog.provide and all of that?

plexus16:09:15

should it be in :foreign-libs, or in the source directory together with cljs files? or ...?

spinningtopsofdoom16:09:19

IIRC it should be usable just like a regular clojurescript namespace

plexus16:09:34

(note this is not a file that's part of the Closure Library, just some other file that follows the Closure conventions)

spinningtopsofdoom16:09:15

e.g. (ns (:require [goog.object :as gobj])

plexus16:09:40

putting it on the classpath seems to work

martinklepsch16:09:31

@plexus when it's on the classpath it has to follow classpath conventions (e.g. dots indicate directories) — if things don't match in that way you can use :libs (analogous to :foreign-libs)

martinklepsch16:09:17

If you look at the deps.cljs of some of the Closure packages on https://cljsjs.github.io that might be interesting as well

plexus16:09:37

thanks, that makes sense

dnolen17:09:36

@plexus yes if the Google Closure namespace is on the classpath and it’s namespace matches, it just works

dnolen17:09:45

see transit-js

dnolen17:09:02

it’s why we can just package that up in a JAR and use it transparently from ClojureScript

dnolen17:09:15

transit-cljs is just a thin wrapper

plexus17:09:02

that's cool!

dnolen17:09:51

it means that if you need to write some JavaScript, we have seamless in integration for things that follow Closure conventions + classpath conventions

yury.solovyov18:09:14

Hi, how do I use pipeline-async from core.async lib? should I read from channel returned by this function or from to channel that I pass as arg ?

yury.solovyov18:09:18

seems like the latter

jr18:09:07

correct

yury.solovyov19:09:01

yup, that worked

joakimmohn20:09:42

setting up token based auth for my clojure/clojurescript app. How do i set the request header to be the token on every subsequent request after signing in?

exupero20:09:24

You’ll need to retain it in memory in the browser and include it whenever you make an AJAX request.

exupero20:09:22

If you’re using XhrIo, the fifth argument to the .send method is an object of headers.

joakimmohn20:09:50

im using cljs-ajax. and reagent re-frame for application. so i can store it in localstorage and whenever it is present in localstorage i send it with ajax request

joakimmohn20:09:21

this might be what interceptors are for