This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (3)
- # architecture (2)
- # beginners (54)
- # boot (85)
- # braveandtrue (8)
- # cider (21)
- # cljs-dev (56)
- # cljs-site (5)
- # cljsjs (15)
- # cljsrn (9)
- # clojars (4)
- # clojure (99)
- # clojure-austin (1)
- # clojure-russia (36)
- # clojure-spec (53)
- # clojure-uk (29)
- # clojurescript (161)
- # datomic (8)
- # hoplon (3)
- # immutant (48)
- # jobs (1)
- # jobs-rus (1)
- # leiningen (10)
- # om (23)
- # om-next (1)
- # onyx (22)
- # parinfer (3)
- # planck (13)
- # protorepl (8)
- # re-frame (46)
- # reagent (2)
- # remote-jobs (1)
- # respo (1)
- # specter (5)
- # testing (12)
- # untangled (50)
- # yada (13)
@xcthulhu: JS, and particularly the browser environment, is hackable enough so that as soon as untrusted code enters your VM, say goodbye to security
@xcthulhu: any sort of js injection is bad not restricted to cljsjs, you should look into the
Content-Security-Policy http headers if you really want to lock things down
in my experience the biggest issue however are plugins the user already have installed
@thheller: Avoiding globals like window.React or window.crypto is a measure you can take but it looks like nobody bothers much.
@xcthulhu: how is that a factor? if someone can execute code on your page they can do anything, they don't
React for that?
It depends on the app; you might not store anything of value in cookies, and just make the user enter a password via a form.
For sure, but I seriously have crazy clients that ask me to handle digital currency in the browser. I told the last client "No" but I've been racking my brain on how to do this.
I can lock down most stuff by just doing doing authentication via ECDSA and encrypted commumication with ECDH for shared secrets
You would still not want to hand the server your password for your digital currency because the server can get hacked too.
But I guess when it comes to trying to tighten up injection attacks against React or
window.crypto nobody seems to worry
Okay, so my last client wanted to make a "Decentalized Facebook" where you can tip your friends with digital currency
Like I said, I told them "No" but a lot of these security measures assume a trusted central entity...
well anyways, in the context of http and clojurescript (or js) use https + no outside scripts +
Content-Security-Policy for the paranoid
I still would prefer if React wasn't a global object but I guess nobody else seems to care.
if you can't you can't, all the "hacker" would need is to open a dev console and look up the name it is using instead
ClojureScript 1.9.211 released https://groups.google.com/d/msg/clojurescript/KIX2ll89Ohk/3DJWEGk6DAAJ
@alexmiller: I somewhat understand that you’d want the paragraph
since Clojurescript in a way is a Clojure, but to me it would have read better if it’d said Clojurescript instead of Clojure.
Why Clojure? Clojure is a dynamic, general-purpose programming language supporting interactive development. Clojure is a functional programming language featuring a rich set of immutable, persistent data structures. As a dialect of Lisp, it has a code-as-data philosophy and a powerful macro system.
it’s really explaining the first para, so I don’t think ClojureScript would make sense there
but I understand that it may be a little weird seeing that at the top of the cljs site
I appreciate that this is hard to write in a way which doesn’t confuses the simple likes of me, and I have no clue about how to write it clearer while still keeping it concise and correct.
@alexmiller: this is great, but one small annoyance: "Using ClojureScript on a Web Page" begins with an error "You will not see "Hello world!" but instead you will likely see an error like the following:" which I think will put newbies off 3:02 it would be better to show them how to do it right, then point them to common errors and how to fix them afterwards
all content was copied over from the ClojureScript wiki page and there are many that probably need updating
if you’re submitting a PR, you will also need to sign the Contributors Agreement - see http://clojurescript.org/community/contributing_site
I want to load some EDN data to configure my re-agent app at runtime. As far as I can see there’s nothing built-in to CLJS to do this (no slurp for example) so I need to find a CLJS HTTP client and make a request. Is that right?
if for some reason you want something that appears more idiomatic sure 3rd party library - but Google Closure is just fine for this
Thanks @dnolen I guess a thin wrapper over Closure would be nice, if not I’ll use it direct. thanks for the pointer.
@anmonteiro: at parity with the caveat that
cljs.spec.test is a bunch of macros instead of fns
I encourage everyone to kick the cljs.spec tires that are there - the sooner issues get flushed out the better
Is there any standard practice for how to instrument a cljs app only during development? I'm imagining conditionally calling
instrument if it's running without optimizations but not sure how to determine that.
@sekao: there isn’t but I can certainly imagine a number of ways to do it - either via custom builds (like test builds) or some component like approach
I was looking at the cljs JIRA and one of the latest issues is http://dev.clojure.org/jira/browse/CLJS-1710, which talks about how there is no
double-in in cljs spec. which I thought was because all numbers are doubles and thus double-in doesn’t make sense. I checked the source and I noticed there is an
int-in though, which I thought was weird, why is this?
goog.math.Integer or a
goog.math.Long. now to go figure out what those are...
@dnolen or anyone interested in instrumenting only during dev: it looks like with boot-cljs you just need a separate
prod-resources that contain separate
main.cljs.edn files. that config lets you specify
:init-fns, so the dev one can just include a call to
cljs.spec.test/instrument. seems to work!
@chris: Be careful with
goog.math.Integer, multiplication is currently broken upstream and pending a patch: https://github.com/google/closure-library/pull/741
anyone experiencing an error when instrumenting a multi-arity function? i saw that it was reported already but it is marked as resolved. i’m getting the same error in 1.9.211: http://dev.clojure.org/jira/browse/CLJS-1663
@dnolen: np, i made a gist with more specifics: https://gist.github.com/oakes/82c8b254fa2c4fecbc85d50b94d91d9a
i’m happy to file an issue on jira, i just hesitated since i saw there already is one that is closed
is there a good way to kinda turn on a global flag? e.g.
(def ^:dynamic *profile* nil) … I know I can
binding it … but if I just wanted to make it
true for awhile 🙂
There are also
:closure-defines but that's compiler settings so you need to restart compiler for changes
intermittently I’m unable to call
js/console.log continues to work. I am using (enable-console-print!). Any guesses?
nvm. this is the issue https://github.com/adzerk-oss/boot-cljs/issues/126
@uwo: Could you try
0.3.3, it is possible that the cause is that piggieback by default redirects all output to REPL instead of console, 0.3.3 overwrites this default.
@juhoteperi: it took me a moment to ensure that I was using
0.3.3. It doesn’t appear to fix the issue
not sure if everyone is familiar with “namespaced maps”, but it is a new syntax that was added this week to cljs
i’m trying to keep a clear and comprehensive syntax reference here: http://cljs.github.io/api/syntax/
A quick search for how to use clojure libraries (specifically datomic-backed libs) with clojurescript didn’t turn up anything definitive. Anybody have advice?
(Currently I have routing and other api-esk libs running via nginx-clojure that serves templated pages which wraps the datomic queries and I would like to include my reagent stuff so I can serve all the content from the same place and re-use the datomic libs which are in a clojure namespace)
This is the closest I came but its from March 2014 https://8thlight.com/blog/andrew-zures/2014/03/08/combining-clj-and-cljs-libraries.html
Can you explain what you’re trying to do a little further? Not quite sure I understand
Sure,to start with I’m planning on using nginx-clojure for everything. I’ve written a set of api’s that deal with application logic in general and have written a few nginx handlers to serve up templated pages that are backed by a aws ddb datomic store. Since most of the app really is going to be in reagent I’m looking for a way to re-use my internal api libs (that currently are clojure/datomic) in the clojurescript part
Not sure its really relevant that I’ve specified handlers and routes for the handful of templated pages since the api’s I want to use are underneath them
Cool, one way to do this is to have
src/cljs directories for each type of file