Hi Nuo. `clj->js` already works through an abstraction so it is open to extension. You can override the default behavior in your application extending IEncodeJS to the Keyword. This may help you how to do it: https://twitter.com/fasihsignal/status/740436159214551040
This is already reported previously, and declined because the system is already open to extension: http://dev.clojure.org/jira/browse/CLJS-536 Regards. Andrey On Mon, Jun 13, 2016 at 1:57 AM, Daniel Compton < [email protected]> wrote: > Hi Nuo > > You can raise a ticket about this at > http://dev.clojure.org/jira/secure/Dashboard.jspa. However I suspect that > the default behaviour is unlikely to change, as it could break a lot of > code that relies (implicitly) on the existing behaviour. However there is a > lot of movement around namespaced keywords at the moment with spec, so > perhaps this change could be rolled in here? > > One option I can think of would be to keep the existing arity the same, > but add a new arity with an option {:keep-ns true} or similar. > > On Mon, Jun 13, 2016 at 2:13 AM Nuo Li <[email protected]> wrote: > >> The function clj->js use "name" function to convert a keyword to a >> string, which is not the right choice, since "name" means a different thing >> from what should be placed here. >> >> When we use ClojureScript in developement, as long as we need to deal >> with js object, we have to js->clj (with keywordize true) first, so there >> can be strings like "A/B" in keys which are converted to :A/B. When >> converting them back to js object, :A/B will be converted to "B", which >> causes a lot of problems. >> >> >> >> What I use is the one below, which does the correct conversion. >> >> (defn keyword2string [k] >> (let [ky (if-let [nspace (namespace k)] (str nspace "/" (name k)) (name >> k))] >> (if (empty? ky) >> (subs (str k) 1) >> ky))) >> >> >> I don't know whether it is a known issue (probably for a very long >> time...) I didn't see any fix in github, and I have no idea how to >> contribute to it. >> >> It's likely everyone else who encountered this problem before use some >> approach like defining their own version of clj->js (like me), but I guess >> it is not a good idea to leave a not so correct cljs.core function for the >> ones who hasn't encountered this problem yet. >> >> Thank you~! >> >> Nuo >> >> -- >> Note that posts from new members are moderated - please be patient with >> your first post. >> --- >> You received this message because you are subscribed to the Google Groups >> "ClojureScript" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/clojurescript. >> > -- > — > Daniel > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/clojurescript. > -- Andrey Antukh - Андрей Антух - <[email protected]> http://www.niwi.nz https://github.com/niwinz -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/clojurescript.
