This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-23
Channels
- # admin-announcements (1)
- # announcements (1)
- # beginners (222)
- # boot (210)
- # cider (26)
- # cljs-dev (50)
- # cljsrn (19)
- # clojure (243)
- # clojure-art (12)
- # clojure-finland (1)
- # clojure-poland (43)
- # clojure-russia (46)
- # clojure-sg (13)
- # clojurescript (60)
- # core-async (14)
- # css (11)
- # datomic (9)
- # devcards (9)
- # dirac (2)
- # editors (13)
- # emacs (5)
- # euroclojure (1)
- # events (3)
- # hoplon (76)
- # immutant (10)
- # job (1)
- # jobs (2)
- # keechma (1)
- # ldnclj (33)
- # lein-figwheel (1)
- # leiningen (20)
- # luminus (26)
- # mount (31)
- # om (105)
- # onyx (56)
- # parinfer (29)
- # perun (12)
- # proton (1)
- # re-frame (14)
- # reagent (5)
- # sydney (1)
- # yada (15)
When you're building full-stack apps, do you distribute the front-end with a CDN, and if so, do you develop the front and back-end's in the same repo, or separate them?
@futuro about #2 in my experience it is better to have separate project, and usually yes the frontend content in in a sort of CDN but to make it super fast there are modules, server-side rendering, very nice tricks 😉
@richiardiandrea: Cool, thanks for the tip
@futuro: NP! in a project I had both together and ended up with all sorts of dependencies problems, than switched to boot and thanks to its pods the pain healed a bit 😄
It seemed like there could be benefits to having both in one project; one less directory to move around in, similar project.clj; but I wasn't entirely sure
Agree, but it's always good to ask so that you have an idea For example in boot I had a lot of fun dispatching on a multimethod, calling for instance boot -e flavor=backend build --type prod
or analogous for frontend. Leiningen gives you less flexibility but more of a declarative approach. But it can get big: https://github.com/Lambda-X/replumb/blob/master/project.clj
Hm, not long ago I read about a cljs librarie for games, a wrapper around a js library. But I cannot recall its name. Any ideas?
@sveri is it chocolatier? https://github.com/alexkehayias/chocolatier
@msuess: checkout this one too! https://github.com/infinitelives/
Noob debugging advice please: if i'm seeing an error in the compiled and deployed cljs, that's totally absent from local version, how should I got about debugging it? Error message from the compiled version is, "Uncaught Error: Vector's key for assoc must be a number."
I mean @sonelliot
@dnolen Yes thanks, is there a way to get more info from the compiled version when one cannot reproduce it locally?
@limist: you can build source maps and make those only visible to yourself a la http://blog.getsentry.com/2015/10/29/debuggable-javascript-with-source-maps.html
I am trying out devcards and as soon as I add this expression: [devcards.core :refer-macros [defcard]]
or this (:require-macros [devcards.core :refer [defcard]])
section I get this error: Uncaught TypeError: Cannot read property 'render' of undefined
in my browser console.
Any ideas what is going on here?
some code is trying to access render property on a javascript object which happens to be null/undefined, for example this code would do that (.-render (call-function-returning-nil))
a pro-tip: cljs-devtools with :sanity-hints enabled could help you locate exact source code location when that happened: https://github.com/binaryage/cljs-devtools#an-example-of-a-sanity-hint
@darwin: Thanks for the suggestions. Still, there must be something missing in my project or I have some misconfigured dependencies.
is there a semantic difference between (:require-macros [foo.bar :refer [baz]])
and (:require [foo.bar :refer-macros [baz]])
for a dep with a foo/bar.clj
and foo/bar.cljs
?
seems to me like the latter (`:require`) form should always be preferred as safer, but I'd never hit a problem with this til now
@dnolen Wouldn't the latter also :require
the foo/bar.cljs
namespace, while the former wouldn't, necessarily? or am I misunderstanding?
requiring is about loading, the :refer
stuff is all syntactical convenience nothing more
@pandeiro: but I don’t really understand at all what you’re trying to actually ask
@dnolen: Case in point (easier), re-frame uses a pattern where it loads a macro from reagent.ratom
; However if the reagent.ratom
CLJS namespace is not also required, that will spit out undeclared var warnings
It doesn't show up most times, b/c in most namespaces, re-frame or reagent are also being required, bringing in the reagent.ratom transitively
But if they are not there, the CLJS namespace of the same name only gets loaded using the second syntax I showed, not the first
@pandeiro: FWIW, if you do (doc ns)
, an example showing exactly how the :refer-macros
inline macro specification desugars appears at the bottom.
If you are ever really curious, you can invoke the (undocumented internal) desugar function yourself. Here is it being done with Planck:
cljs.user=> (require 'cljs.analyzer)
nil
cljs.user=> (cljs.analyzer/desugar-ns-specs {:require '[woz.core :as woz :refer [woz-fn] :refer-macros [app jx]]})
((:require (woz.core :as woz :refer [woz-fn])) (:require-macros (woz.core :as woz :refer [app jx])))
Captured the above in a gist in case anyone is interested in it: https://gist.github.com/mfikes/faea7393d04b92a43388
I think David started on it a little before mid-2015, and truth be told, most of the bugs were addressed fairly quickly. But it took a while to squash the long tail of tiny known bugs.