This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (7)
- # boot (48)
- # clojure (50)
- # clojure-portugal (1)
- # clojure-russia (10)
- # clojure-spec (29)
- # clojure-uk (9)
- # clojurescript (116)
- # core-logic (1)
- # cursive (12)
- # datascript (2)
- # datomic (7)
- # defnpodcast (8)
- # dirac (80)
- # emacs (486)
- # hoplon (5)
- # instaparse (3)
- # keechma (1)
- # luminus (3)
- # lumo (35)
- # off-topic (65)
- # om (6)
- # onyx (6)
- # perun (42)
- # re-frame (5)
- # reagent (5)
- # rum (2)
- # untangled (170)
- # vim (13)
I think I have a pretty good design, but I'm not sure where to take it from here.
Users login -> sends ajax request to server -> user gets back a token, on subsequent requests for special actions (send posts to the server) it uses the token to make sure it's the right user on the serverside... So that's grand and dandy... but what's a good way to persist state on the client side, cookie style?
Someone mentioned LocalStorage as a valid option, the data i'm working with is not all that sensitive and localStorage may prove to be very convenient for this.
do you have an easy way to convert ~400MB xml (wiikiquote dump) into json? 🙂 or something even better?
But that's the way part the parsing and getting the data as Clojure data structures is the only hard part imho
In particular, I'd like a cljs map where the keys are weak references, (and if they get collected, the values can vanish -- I'm fine with that)
if not that, a cljs set with weak references would be fine too -- when gc-ed, the items just vanish from the set
suppose I can write some functions that make sense in both clojurescript and clojure
is it always better to just put them in cljc files so we that I can run tests more easily with cider & co?
@andrea.crotti: in theory yes, in practice, I found myself constantly wasting time battling #?(+clj / +cljs), dealing with different :requires and other stupid things that just slowed me down
the one advantage of *.cljc files was that it REALLY forced me to separate pure functions from DOM manipulating functions, which made things cleaner, but it the other parts were a constant battle
actual: #object[TypeError TypeError: undefined is not an object (evaluating 'frontend_cljs.core.get_final_score.call'
oh interesting .. last time i checked weak reference didn't work at all. guess I was wrong then
do you have a browser-repl of some sort where you can use (in-ns ...) and explore around?
uu right `frontend-cljs.core-test> (in-ns frontend-cljs.core) java.lang.UnsupportedOperationException: nth not supported on this type: Symbol `
@thheller: OT, how do you do the inline-pre, I only know how to use the three backticks, which causes a entire pre-div @andrea.crotti: I realize this is useless, but with cljs, especailly incremental compilation, sometimes, if I just nuke all the cached stuff it and it rebuilds everything, it just works
mm wtf I commented out some stuff, then it gave the actual right error, which was a simply arity mismatch
dunno if this is still true for CLJS but sometimes a cached file will not be recompiled, so warnings won't show
Can we please revisit CLJS-536? Clojure added more support for namespaced keywords into reader macros, specs use them heavily, so this lossy behavior of clj->js is very surprising
@wagjo as David mentioned in the comments. you can achieve this behavior with IEncodeJS
yeah seems fair, curious though when you'd ever do
clj->js->clj seems a very lossy process overall? not just for keywords
> general question to the node.js folks: did you use a template (lein/boot)? if yes, which one?
symbols preserve their namespace when transformed with clj->js, I think we should consider the lossy keyword behavior a bug, and not as a feature which should be left supported for existing libraries.
then you would get it only for half of the identifiers, symbols would be left with their namespace. I don't see how this should be an intended behavior
symbols are used much less frequently than keywords, I'm not sure if the comparison is fair
so were namespaced keywords, before spec. Current popularity of some type should be relevant.
Let me give you and alternative view. clj->js is very similar to producing json object from a clojure's one. Most of json generators do keep keyword namespace, e.g. chesire https://github.com/dakrone/cheshire/blob/master/src/cheshire/generate.clj#L140 . This makes clojurescript behavior differ from a clojure, as in clojurescript world (correct me if I'm wrong), the idiomatic way to generate json is with
my point is that you shouldn't, without a pressing need, resort to breaking existing code
Hi there! Looks like I found a bug in cljs.spec, not sure where to report it. Is it appropriate place for bug reporting?
yes I think so, and ultimately there's alsoa jira, http://dev.clojure.org/jira/browse/CLJS
If I want to make a clojurescript library with logging that can be turned on and off easily by users of the library... Any suggestions?
@fenton really depends on many factors, I guess, 1) you can roll your own logging subsystem as part of the library 2) try to use
goog.log if you are ok with string-only logging 3) bring in some dependency, maybe timbre?
Ok, just was curious if there was some industry standard evolving. Any experience with Klang versus timbre?
no experience, I will be rolling my own solution (not finished ATM): https://github.com/binaryage/clearcut
the main goal is to design something with cljs-devtools in mind and also something which will allow exactly same code for clj and cljs
I will also consider eliding logs based on some identifier (e.g. logger name) in addition to log-level filtering
^ shaping very nicely, sorry did not have time to contribute, atm quite busy, but I am following...
not very nicely... got sidetracked with some other tasks and haven’t done any progress in more than 3 months 😞
Random thought bubble on cljs debugging https://gist.github.com/olivergeorge/a58e9176846f9c109d004ce00cfe4fae
Preamble: I'm sorry if this question comes up frequently. I did a little searching, but nothing came up 🙂
I know the Google Closure library has
XhrIo. Should I just be content with what Google Closure offers me?
I suppose I could just wrap some
XhrIo functionality with my own
My first thought was that it would be nice to use ES6/7 features from my ClojureScript code, and have things "just work" in all browsers via some code manipulation in the compilation process.
XhrIo works pretty much in every browser, why use something that may not be supported