In clojure if I want to intern a var in another namespace I can use the intern
(intern 'other-ns 'my-var (fn [x] x))
I want to achieve the same thing in clojurescript, where I define a var/function in one namespace and intern it in another namespace.
I need this because I'm writing code in cljc and I'm interning a var in clojure, and I also need it to be compatible with cljs
Interning is not supported in ClojureScript: "intern not implemented - no reified Vars"
Related
I Javascript's version of react I can use
this.props
but what can I use to gave props in
:reagent-render
callback?
I am trying to do as done here in Chart.js line 14.
To answer your question, you can access the component and props in reagent-render by doing something like this
(ns chartly.core
(:require
[reagent.ratom :as ra]
[reagent.core :as r]))
(defn data-fn [implicit-this]
;; use implicit-this as needed, which is equivalent to "this"
;; From create-class docs -
;; :component-did-mount (fn [this])
)
(defn chart-render []
(let [comp (r/current-component) ;; Reagent method
r-props (r/props comp) ;; Reagent method
js-props (.-props (clj->js comp))]
(js/console.log "PROPS" r-props) ;;-- etc...
[:div {:style {:width 100}}]))
(def data (ra/atom {})) ;;--> see more info on reagent-atom
(defn chart-component []
(r/create-class
{:component-did-mount data-fn
:display-name "chart-component"
:reagent-render chart-render}))
To use -
[chart-component]
However, this is anti-pattern and will be quite difficult to manage, since you are trying to update data prop internally with component-did-mount, which, on completion, would need to manually signal the React component to update itself.
One of the features of Reagent is that is offers to detect changes and updating the component, usually using atom. See Managing State in Reagent for more info.
What you are looking to do is exactly what the Re-frame Framework is helping to manage. You set-up a data-store, and when the store changes, it signals to subscribers (React elements) to update accordingly, and you don't have to handle the signal changes yourself.
There are some edge cases where tapping into the lifecyle events are necessary, especially with charts and other drawing libraries, but I might recommend re-visiting if you find reagent atoms and/or the re-frame library insufficient for your needs. Hope this helps.
As far as I see, you accept some Hiccup data from a user as a string, right? And then try to evaluate it into user namespace, where only reagent library is loaded?
First, the more you build your further code to evaluate, the more difficult to understand it becomes. You could use something like this:
(binding [*ns* user-ns] (eval (read-string user-data)))
Also, to prevent wrong input, it would be better to validate user's input either with Schema or clojure.spac libraries. Since read-string returns a data structure, it might be checked with those two as well. So you would see an error before starting to evaluate something.
I'm relatively new to ClojureScript and having never worked in a lisp-like language before, I must say that the documentation is rather... lacking. I just want to transform the following JavaScript statement into ClojureScript:
var obj = new namespace1.namespace2.SomeObject();
I know that you can create new instances of an object in cljs by writing something like
(SomeObject.)
but trying
(def obj (namespace1/namespace2/SomeObject.))
didn't compile. What should I be doing instead?
Have a look at this answer, it is exactly the same question:
https://stackoverflow.com/a/23653459/1400662
Pasted here:
Using js/a.b.c.d is a bad practice and is likely to break in future versions of the compiler (because it is not a clojure compatible version of interop from what I know)
The good way would be:
(def LatLng (.. js/google -maps -LatLng))
(LatLng. 100 100)
What is an idiomatic way to handle application configuration in clojure?
So far I use this environment:
;; config.clj
{:k1 "v1"
:k2 2}
;; core.clj
(defn config []
(let [content (slurp "config.clj")]
(binding [*read-eval* false]
(read-string content))))
(defn -main []
(let [config (config)]
...))
Which has many downside:
The path to config.clj might not always be resolved correctly
No clear way to structure config sections for used libraries/frameworks
Not globally accessible (#app/config) (which of course, can be seen as a good functional style way, but makes access to config across source file tedious.
Bigger open-source projects like storm seem to use YAML instead of Clojure and make the config accessible globally via a bit ugly hack: (eval ``(def ~(symbol new-name) (. Config ~(symbol name)))).
First use clojure.edn and in particular clojure.edn/read. E. g.
(use '(clojure.java [io :as io]))
(defn from-edn
[fname]
(with-open [rdr (-> (io/resource fname)
io/reader
java.io.PushbackReader.)]
(clojure.edn/read rdr)))
Regarding the path of config.edn using io/resource is only one way to deal with this. Since you probably want to save an altered config.edn during runtime, you may want to rely on the fact that the path for file readers and writers constructed with an unqualified filename like
(io/reader "where-am-i.edn")
defaults to
(System/getProperty "user.dir")
Considering the fact that you may want to change the config during runtime you could implement a pattern like this
(rough sketch)
;; myapp.userconfig
(def default-config {:k1 "v1"
:k2 2})
(def save-config (partial spit "config.edn"))
(def load-config #(from-edn "config.edn")) ;; see from-edn above
(let [cfg-state (atom (load-config))]
(add-watch cfg-state :cfg-state-watch
(fn [_ _ _ new-state]
(save-config new-state)))
(def get-userconfig #(deref cfg-state))
(def alter-userconfig! (partial swap! cfg-state))
(def reset-userconfig! #(reset! cfg-state default-config)))
Basically this code wraps an atom that is not global and provides set and get access to it. You can read its current state and alter it like atoms with sth. like (alter-userconfig! assoc :k2 3). For global testing, you can reset! the userconfig and also inject various userconfigs into your application (alter-userconfig! (constantly {:k1 300, :k2 212})).
Functions that need userconfig can be written like
(defn do-sth [cfg arg1 arg2 arg3]
...)
And be tested with various configs like default-userconfig, testconfig1,2,3...
Functions that manipulate the userconfig like in a user-panel would use the get/alter..! functions.
Also the above let wraps a watch on the userconfig that automatically updates the .edn file every time userconfig is changed. If you don't want to do this, you could add a save-userconfig! function that spits the atoms content into config.edn. However, you may want to create a way to add more watches to the atom (like re-rendering the GUI after a custom font-size has been changed) which in my opinion would break the mold of the above pattern.
Instead, if you were dealing with a larger application, a better approach would be to define a protocol (with similar functions like in the let block) for userconfig and implement it with various constructors for a file, a database, atom (or whatever you need for testing/different use-scenarios) utilizing reify or defrecord. An instance of this could be passed around in the application and every state-manipulating/io function should use it instead of anything global.
I wouldn't bother even keeping the configuration maps as resources in a separate file (for each environment). Confijulate (https://github.com/bbbates/confijulate , yes - this is a personal project) lets you define all your configuration for each environment within a single namespace, and switch between them via system properties. But if you need to change values on the fly without rebuilding, Confijulate will allow you do that, too.
I've done a fair bit of this over the past month for work. For the cases where passing a config around is not acceptable, then we've used a global config map in an atom. Early on in the application start up, the config var is swap!ed with the loaded config and after that it is left alone. This works in practice because it is effectively immutable for the life of the application. This approach may not work well for libraries, though.
I'm not sure what you mean by "No clear way to structure config sections for used libraries/frameworks". Do you want libraries to have access to the config? Regardless, I created a pipeline of config loaders that is given to the function that setups the config at start up. This allows me to separate config based on library and source.
How can I get the Clojurescript namespace I am in from within a clojurescript program? I want to do this do provide certain debug information (it only needs to work in dev mode)
Namespaces are not first class in ClojureScript as they are in Clojure. There's absolutely no way to get the namespace at runtime. It is possible to get this information at macroexpansion time if you're not afraid of accessing some the ClojureScript compiler internals. There should probably be an API for this - but we're not there yet.
You can get the name of the current namespace with this trick, which takes advantage of :: creating a namespaced symbol for you in the current namespace:
(namespace ::x)
You probably don't want to use that value for anything, because if the code is compiled the internal representation will change. If you want to live dangerously, then in the browser you can then access the js object that holds the namespace like this:
(reduce (fn [ns n] (aget ns n))
js/window
(clojure.string/split (namespace ::x) #"\."))
During macro-expansion you can access &env and retrieve namespace information from the :ns key like this:
(:ns &env)
(:name (:ns &env))
This only works at macro-expansion/compile time and not at runtime.
You can try this
(apply str (drop-last 2 (str `_)))
I'm integrating some ClojureScript code with a JS library call that takes a callback function. The JS library passes data to the callback using JavsScript's "this" keyword.
I can get it to work using (js* "this"). For example:
(libraryCall (fn [] (.log console (js* "this"))))
Is there a way to get at the "this" context from ClojureScript without resorting to js*?
Use the built-in this-as macro. It takes a name and a body, and evaluates the body with the name bound to JavaScript this.
e.g.
(libraryCall (fn [] (this-as my-this (.log js/console my-this))))
Great question... had to dig into the compiler code to find it, it's not well advertised at all.
I'll add it to the book.