This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-27
Channels
- # bangalore-clj (2)
- # beginners (37)
- # boot (16)
- # cider (17)
- # clara (4)
- # cljs-dev (351)
- # cljsrn (16)
- # clojure (219)
- # clojure-belgium (4)
- # clojure-dev (3)
- # clojure-france (2)
- # clojure-italy (24)
- # clojure-russia (23)
- # clojure-spec (55)
- # clojure-switzerland (3)
- # clojure-uk (89)
- # clojurescript (121)
- # cursive (2)
- # datomic (29)
- # devops (2)
- # graphql (8)
- # hoplon (15)
- # immutant (5)
- # lein-figwheel (4)
- # liberator (3)
- # luminus (18)
- # off-topic (9)
- # om (6)
- # onyx (31)
- # pedestal (48)
- # precept (9)
- # re-frame (19)
- # reagent (63)
- # ring-swagger (69)
- # robots (1)
- # slack-help (14)
- # spacemacs (12)
- # sql (2)
- # test-check (4)
- # unrepl (28)
- # untangled (5)
- # yada (3)
I just upgraded to 1.9.655 and I'm getting this error with advanced optimisations in a project that uses schema-tools. The property it points to is default
:
kesäkuuta 27, 2017 11:09:15 AP. com.google.javascript.jscomp.LoggerErrorManager println
WARNING: /Users/miikka/.boot/cache/tmp/Users/miikka/redacted/yzt/ko6id6/js/main.out/schema_tools/core/impl.js:222: WARNING - Keywords and reserved words are not allowed as unquoted property names in older versions of JavaScript. If you are targeting newer versions of JavaScript, set the appropriate language_in option.
return (!((other55787 == null))) && ((this55786__$1.constructor === other55787.constructor)) && (cljs.core._EQ_.cljs$core$IFn$_invoke$arity$2(this55786__$1.schema,other55787.schema)) && (cljs.core._EQ_.cljs$core$IFn$_invoke$arity$2(this55786__$1.default,other55787.default)) && (cljs.core._EQ_.cljs$core$IFn$_invoke$arity$2(this55786__$1.__extmap,other55787.__extmap));
I thought it was safe to use JS reserved words as identifiers in ClojureScript. Is this a regression?
(The problem is that this record has a field called default
: https://github.com/metosin/schema-tools/blob/e838be8cbeed88a08b41de3acd755e7ae61509ec/src/schema_tools/core/impl.cljc#L53)
@miikka That was discussed yesterday. There is a ticket on specter. Maybe schema-tools should also get a ticket
Meh. default seems like a perfectly good field name to me but I guess it can't be fixed.
@miikka I believe it could be fixed by generating js code which would access properties (fields) by string names, but that is quite some work which would need extensive testing and could introduce new problems.
hi, is it possible to enable source map for source file references in stack trace in chrome console? It would be much easier to find source of exception.
@pradyumna if source maps are enabled that’s just how it works
@pradyumna How do you output the stacktraces to the console?
The exception is thrown by router.cljc and that shows the source mapped link to that file correctly
When I expand the exception to see the stack trace then those are showing link to js file
I don't know what your code looks like, but if you dump them with (js/console.log "%s" ...)
it won't work. You gotta use (js/console.log "%o" ...)
I'm a bit confused about req vs req-un in spec. If I have the following in the same file spec fails: (s/def ::received-blob-count int?) (s/def ::cooked-blob-count int?) (s/def ::transformers (s/keys :req [::received-blob-count ::cooked-blob-count ::gg/gauge-vals])) gives this error msg: In: [:transformers] val: {:received-blob-count 0, :cooked-blob-count 0, :gauge-vals nil} fails spec: :etl-service.specs.app-db/transformers at: [:transformers] predicate: [(contains? % :etl-service.specs.app-db/received-blob-count) (contains? % :etl-service.specs.app-db/cooked-blob-count) (contains? % :etl-service.specs.gauge/gauge-vals)] when does it make sense to use req as opposed to req-un, I didn't think req-un would be necessary for things defined in the same namespace.
ClojureScript 1.9.660 released https://clojurescript.org/news/2017-06-27-faster-compilation-runtime-and-spec-caching-fixes
Reagent 0.7.0 released https://github.com/reagent-project/reagent/blob/master/CHANGELOG.md#070-2762017, it fixes a warning introduced in Cljs 1.9.660
@dealy req
in a spec validates for namespaced keys as opposed to req-un
which validates for keys with the same name. So when you try to validate the response map with spec containing req
it fails as the keys are not namespaced
I typically use req-un
in validating maps that I get as part of external request/response.
yea, that's the way I have my code now, but some of the examples I saw had req with local unnamespaced keys. It is kinda confusing between the docs and some of the examples I was reading.
For data being passed around between namespaces of the same app req
can be leveraged if you have multiple specs that are named same so that you can differentiate them by the namespaces.
Does anyone know how you'd do something like this es6: class Clock extends Component
in ClojureScript?
@dealy can you point the example you are mentioning? sounds like a bug in docs if that's the case
@mobileink if you count CLJS as goog?
I also have (:require ["react" :as react])
support in shadow-cljs
but that isn’t “official” yet for CLJS
it's all about namespacing, yeah? goog.provide
emulates namespaces, module.exports
piggiebacks on that, and :require
only understands namespaces? (fyi i'm working on docs.)
the javascript module support just takes a file and scope all references in that file
so, in contrast to clj, your pgm text can reference names that are not explicitly included (via :require or :import), so long as your html <script>s them in, so to speak?
if i want to use a js lib that has e.g. foo.bar.baz, i always need to put it in the js
namespace, i.e. js/foo.bar.baz
?
iow, anything that is not modularized via goog.provide
or module.exports
must be qualified by js/
?
maybe #off-topic , but this strikes me as a (minor) flaw. in clj your program text cannot ref names unless you have explicitly authorized (via :require or :import). shouldn't cljs do the same?
iow js/foo
should fail unless you have explicitly introduced foo
somehow, in the pgm text rather than in an html file.
@mobileink usually we wrap JS stuff, so you can have something like (def foo js/foo)
, then you can work on top of it
breaks how?
well, as mentioned, any name you want to ref in clj text must be explicitly introduced in the same text.
true! but not for clj code, only java (foreign) code, no? but alas js does not have such animals, and anyway my guess is that the majority of code uses :import.
@mobileink no that's not the case. In clj you can use the fully qualified name for any Java class anywhere in the program text and it will be resolved/loaded on the fly. It works just like Java code.
And while perhaps most code uses :import
, there exists a lot of code that doesn't. Especially for one-off invocations.
@mobileink it’s just not a good idea
when you start thinking about higher level stuff, like polyfills what you’re suggesting could only lead to more not less problems
understood. but that's changing, no? since i'm about to go off on tangents i'm switching to #off-topic
if by changing - you mean this was changed by the BDFL Rich Hickey and he probably thought about it at length
there are really very few choices in ClojureScript that weren’t put in place 6 years ago
for the RSS lovers https://clojurescript.org/feed.xml
here' a little motivation. i rilly do not like mixed language pgmming. i don't want to do even a little bit of html. that's just me, i get it. (see miraj). in cljs, to use js libs, i have to muck with html. i know, trivial, but still, it ruins the aesthetics. in clojure, i never have to do this. to make a seamless dev experience, cljs should (in nutty principle) act just like clj. you wanna use sth, then :require or :import it. i do sth like this in miraj, but have no idea if it would work generally.
ClojureScript is just about running where JavaScript runs - sorting out all the other stuff is for the community and they’re doing an amazing job at it
the other thing is there are some old decisions and it’s important to understand they just aren’t going to change
dnolen: running code always wins. how depressing for those of us with great theories.
lots of people in the community have already invested time / money / trust - ClojureScript just isn’t a new project that barely works anymore 🙂
dnolen: sure, it works great in practice - but how does it work in theory? (old uchicago joke, hahaha)
i am an admitted unreasonble outlier - all progress depends on me! haha that was a joke, really. seriously i am not asking for cljs to change, i am perfectly happy with it. but inho it's useful to think crazy once in a while.
more specifically, i'm thinking about how to doc cljs, contrast it with clj, etc. in a comprehensive way.
philosophical stuff is best left for books - official site doc’ing is just about documenting differences or things that will trip up users just starting out - we should stay focused on that
dnolen: completely agee, but speaking of which, the doc pr i subbed today - i don't know what the protocol is but i'd like to just invite everybody to pitch in. ok? i understand that my idea of good docs may or may not match that of you and your colleagues, np.
PR looked fine from a high level - can’t give feedback today but I definitely will this week - good rule of thumb is to follow Clojure style & tone for reference stuff - Guides are more flexbile - clojure.spec is a good example
dnolen: running code always wins. how depressing for those of us with great theories.