This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-26
Channels
- # aleph (2)
- # aws-lambda (18)
- # beginners (81)
- # boot (3)
- # cider (25)
- # cljs-dev (274)
- # cljsjs (10)
- # clojars (25)
- # clojure (65)
- # clojure-austin (1)
- # clojure-brasil (2)
- # clojure-dev (33)
- # clojure-dusseldorf (6)
- # clojure-gamedev (3)
- # clojure-italy (17)
- # clojure-poland (3)
- # clojure-russia (7)
- # clojure-spec (48)
- # clojure-uk (45)
- # clojured (1)
- # clojurescript (26)
- # core-logic (2)
- # data-science (4)
- # datascript (6)
- # datomic (58)
- # defnpodcast (2)
- # docker (1)
- # duct (14)
- # figwheel (2)
- # fulcro (130)
- # graphql (3)
- # leiningen (1)
- # liberator (15)
- # luminus (5)
- # nrepl (1)
- # numerical-computing (1)
- # off-topic (45)
- # onyx (15)
- # re-frame (9)
- # reagent (3)
- # ring (1)
- # shadow-cljs (91)
- # spacemacs (8)
- # sql (23)
- # unrepl (38)
- # videos (2)
- # vim (12)
Here is another example utilizing synthetic index.html
generation via cljs.main
https://twitter.com/mfikes/status/967929140430229505
I'm trying to do a goog.require from a JS file and it causes a "Namespace never provided" error when I do an optimised build.
Same is fine from a CLJS file.
e.g. (ns a.example1 (:require cljsjs.leaflet))
in a/example1.cljs vs goog.provide('a.example2'); goog.require('cljsjs.leaflet');
in a/example2.js
Seems like a bug.
but no you cannot call goog.require
to load foreign libs from JS libraries and expect it to work, because foreign libs are not real Closure namespaces
Thanks David. I expected that from a foreign lib. My confusion was expecting a JS file in the source path to be treated like google closure compatible js.
@olivergeorge the problem is that since foreign libs aren’t real Closure you libs you cannot goog.require
to load them
the fact that we happen to do this very cleverly in the compiler is very much an implementation detail
Thanks for that @dnolen. I did a few experiments based on that. Problem only exists when my Google Closure Compiler Compatible Code requires the CLJSJS bundled Foriegn JavaScript Code (as you describe).
Curious workaround is that my JS lib can require a CLJS ns which does the CLJSJS require.
(for anyone reading along this cljs reference on dependencies helps clarify https://clojurescript.org/reference/dependencies)
It evaluates to the current var content, do you have a more specific example that needs clarification?
@savaki it’s a var
that references foo/bar
(which is bar
in the resolved foo
namespace)
so if foo/bar
was a function, the difference between calling (foo/bar :foo)
and (#'foo/bar :foo)
would be that the latter is only a sort of ‘pointer’ to a symbol, and the former being the actual symbol
Hi. I’m trying to include apollo-utilities
(a JS library) into a browser-targeting CLJS project with :npm-deps
. It builds fine but the generated/transformed out/node_modules/apollo-utilities
directory still contains ES6 and fails loading in the browser. I can see where this is coming from (`"module"` in package.json
of apollo-utilities points to an ES6 file). But I don’t understand the :npm-deps
process well enough yet to tell whether this is expected or whether I’m missing something to make this work. Any ideas?
I just ran into an unusual issue, probably due to my lack of understanding. I’m trying to show a FontAwesome icon and toggle it when it is clicked.
I found that the SVG icon does not work, but the old style ‘web font’ does.
Could this be due to some magic that FontAwesome performs to load and display SVG icons?
I should add this is a Reagent component.
Hi, I'm writing a cljs library, if I'm using clojure.core.async "0.4.474"
, and the library user is using clojure.core.async "0.4.475"
, how can I determine if an object is an instance of core.async/chan
?
see https://crossclj.info/ns/io.replikativ/superv.async/0.2.9/superv.async.html#_chan%3F and the related issue
Thanks 😁
This is a public service announcement: everyone should be using cljs-devtools
. (I am not affiliated)
To me, it is as important as figwheel to a quality dev workflow, perhaps more important. The other day it shocked me to discover a team who were unaware of it. That's a big hole in community communication that we should fill (I'm not sure how, other than this)
https://github.com/binaryage/cljs-devtools