For example:
(defn starrating []
(reagent/create-class
{:reagent-render
(fn []
[:div
[:input {:type "checkbox"
:on-click #(do (re-frame/dispatch
[:set-star-rating
(-> % .-target .-checked)])
(get-data-from-server))}]])}))
(defn get-data-from-server []
(let [star (re-frame/subscribe [:star-rating])]
(ajax/GET (str "http://192.168.0.117:8080/json/searchhotels.json"
"?star=" #star)
{:response-format :json
:keywords? true
:handler success-handler
:error-handler error-handler})))
In the above example the checkbox is not set.
When the checkbox is ticked, the star variable is set to true
But after this, when we call subscribe to get the value in star it is returning previous value i.e false
It will call: http://192.168.0.117:8080/json/searchhotels.json?star=false
When you un-check the checkbox, the request becomes
http://192.168.0.117:8080/json/searchhotels.json?star=true
Why re-frame.core/subscribe is returning previous set value?
re-frame has a data cycle: db -> subscriptions -> view -> dispatch events -> db. That's the most important thing to understand here.
Try setting your checkbox value in starrating with a subscription from app-db, so that the data flows from app-db into your view.
Also try putting get-data-from-server inside an event handler, so that your view is not handling all of the mechanics of querying, but rather is just dispatching events, without the knowledge of what needs to happen to respond to them.
There's a bunch of good documentation on this at https://github.com/Day8/re-frame/tree/master/docs
Subscriptions are reactions meant to be use with reagent components.
Dispatch is asynchronous. Use dispatch-sync if you want it synchronous.
Look into https://github.com/Day8/re-frame-http-fx to make ajax calls while keeping your event handlers as pure functions.
Read the docs, re-frame has very good documentation. Readme.md in github. Have a look at example apps in the repository for examples.
Related
From the Reagent introduction, a simple timer component:
(defn timer-component []
(let [seconds-elapsed (r/atom 0)]
(fn []
(js/setTimeout #(swap! seconds-elapsed inc) 1000)
[:div
"Seconds Elapsed: " #seconds-elapsed])))
and below it reads
The previous example also uses another feature of Reagent: a component
function can return another function, that is used to do the actual
rendering. This function is called with the same arguments as the
first one.
This allows you to perform some setup of newly created components
without resorting to React’s lifecycle events.
Can someone remind me of the underlying principle here? Why do we need this anonymous function? Why not just
(defn timer-component []
(let [seconds-elapsed (r/atom 0)]
(js/setTimeout #(swap! seconds-elapsed inc) 1000)
[:div
"Seconds Elapsed: " #seconds-elapsed])))
From what I remember, Reagent calls timer-component every time it wants to render - potentially setting up the same piece of state (seconds-elapsed) over and over again.
By returning that anonymous function instead, it tells Reagent "use this to render timer-component". This way your state setup is separated from rendering, and like your doco quote says, its a way to perform state setup without using Reacts lifecycle events.
Hope that makes sense
Tl;dr: The anonymous function that is returned is the render method, which every component must have. You can elide the anonymous function if you use the with-let macro in Reagent.
The indispensable part of a React component is a render function, which takes a single object argument and returns a React element. The difference between render
and the component constructor is that, while both methods are called upon construction, render is called on each update. (For instance, if someone calls the setState method of the component).
In the above example, the difference between the inner, anonymous function and the outer timer-component function is the same as between render and the constructor. Notice that the anonymous function closes over the variables bound in the let clause, which allows it to be stateful. If timer-component itself were the render function, then it would be called on every update, and seconds-elapsed would be endlessly reset to zero.
See the doc on the Reagent repo called "Creating Reagent Components".
In the following code I'm dispatching two on-click events:
;; event
(reg-event-db
:some
(fn [db [_ some-val]]
(prn "The db is" db)
(assoc db :some some-val)
))
;; another event
(reg-event-db
:another
(fn [db [_ another-val]]
(prn "The db is" db)
(assoc db :another another-val)
))
;; button
[:input {:type "button" :value "Button"
:on-click #(do
(dispatch [:some :some-val])
(dispatch [:another :another-val]))}]
But instead of printing the db map, it prints "The db is" #object[Object [object Object]], and then
Error: No protocol method IAssociative.-assoc defined for type object: [object Object]
What am I doing wrong? I also tried doing #(dispatch [:some :some-val :another another-val] but that gave the same error. In general, how to correctly dispatch two events?
This is correct:
(do
(dispatch [:first-event :some-value])
(dispatch [:second-event :other-value]))
This is not correct:
(dispatch [:some :some-val :another another-val])
In this example, you are dispatching one event with 3 arguments:
:some is the event name,
:some-val is the first argument,
:another is the second argument,
another-val is the 3rd argument.
The error you are encountering doesn't come from the way you dispatch events, but rather from your db state. Let's dissect it step by step:
If (prn db) outputs #object[Object [object Object]] it means db is a JavaScript object.
If (assoc db …) fails with No protocol method IAssociative.-assoc defined for type object: [object Object], it means the db value does not support the assoc function. The assoc function is defined by a protocol (think interface) and this protocol is implemented on maps. So here, db is not a map.
Why would db be a JavaScript object instead of a Clojure map?
When you use (reg-event-db :event-name handler-function), the value returned by handler-function will replace the db state. If by mistake you return a JS object, it will become the new db value, and this new incorrect db value will get passed to subsequent event handlers. So it's highly probable that one of your event handlers is returning a JavaScript object.
How I would solve this situation:
use (js/console.log db) instead of (prn db). You'll be able to see what's inside this js object. prn doesn't know how to print js objects properly.
make sure cljs-devtools is installed and running. It allows you to explore complex objects in the console. Next time this issue arises, you'll immediately see what's the problematic value instead of an opaque string representation.
use reg-event-fx instead of reg-event-db. While a little bit more verbose, it will make more explicit to the human eye what value you are putting in db.
if you want to go further and ensure this never happens again, take a look at Re-Frame Middlewares. In your case, middlewares would allow you to act on handlers returned values, and potentially reject it if it doesn't match your expectations.
I use an (if) condition as form-2 render-function in this way:
(defn bro [dex]
(let [yo (inc dex)]
(if true
[:div (str yo)])))
instead of this way:
(defn bro [dex]
(let [yo (inc dex)]
(fn [dex]
(if true
[:div (str yo)]))))
Is a problem if i use an (if) statement instead of an (fn) function?
And what happens when the statement gone false? The render function returns with nil?
No, this won't work as you expect. To understand the difference, consider the following two components:
(defn test-component-if []
(let [a (atom 1)
_ (.log js/console "let in -if")]
(if (odd? #a)
[:div
[:p "odd"]
[:button {:on-click #(swap! a inc)}
"inc"]]
[:div
[:p "even"]
[:button {:on-click #(swap! a inc)}
"inc"]])))
(defn test-component-fn []
(let [a (atom 1)
_ (.log js/console "let in -fn")]
;; I dub thee test-inner
(fn []
(if (odd? #a)
[:div
[:p "odd"]
[:button {:on-click #(swap! a inc)}
"inc"]]
[:div
[:p "even"]
[:button {:on-click #(swap! a inc)}
"inc"]]))))
test-component-fn works as expected, while test-component-if does not. Why is that? Well when a reagent component can return one of two things (I'm ignoring "type-3" components, as that hooks into react knowledge). It can return
a vector
another function
If it returns a vector, the function itself becomes the render function, in our case test-component-if. When it returns a function, the function that was returned, not the original function, is the render function. In this case, what I have dubbed test-inner
When Reagent calls a render function, it tracks the atoms that function accesses, and whenever that atom changes it calls the render function. So what happens when we use test-component-if?
Reagent calls test-component-if
Our let clause binds a new atom a to 1.
A vector is returned
We click the button
The atom a is incremented
Reagent sees the change to a and calls test-component-if
Our let clause binds a new atom a to 1. (A different atom than our previous a)
Ooops!
So a is always 1. You can verify this by looking at the console, and seeing that the message is printed every time you click the button.
Now how about test-component-fn?
Reagent calls test-component-fn
Our let clause binds a new atom a to 1.
test-component-fn returns test-inner which closes over a
Reagent calls test-inner
We click the button
a is incremented
Reagent sees the change to a and calls test-inner
Repeat as many times as you want.
You can verify that let only gets executed once again on the console. Click the button as many times as you want, the message will only be printed when it's first rendered.
In terms of an if without an else clause, this will indeed return nil. It's convention to use when instead of if in such cases, which makes it clear the lack of an else is intended. It also has the advantage of including an implicit do. As for what Reagent will do when it encounters that nil, in most cases it will silently remove it and display nothing.
Is a problem if i use an (if) statement instead of an (fn) function?
I think you meant to use an if inside an fn function, but either way it's not a problem.
And what happens when the statement gone false? The render function returns with nil?
Reagent handles these gracefully, a nil will be skipped (no corresponding child is created). If you see the TODOs app example in the official docs, you'll see source has code like the following:
(when (pos? done)
[:button#clear-completed {:on-click clear-done}
"Clear completed " done])]))
In this case, if done is not a positive number, the return value of this expression is nil and the button to clear the completed tasks is simply not added to the DOM.
I have component created with reagent/create-class which gets atom created by subscribe. I am adding a watch on :component-did-mount in order to call component (js) function on request, which is triggered by change in the atom (there is a server round trip). It looks somewhat as following:
(defn editor [text issue-hints]
(let []
(reagent-core/create-class
{:component-did-mount
#(let [editor (js/SimpleMDE.
(clj->js {...}))]
(do
...
(add-watch issue-hints :watch-issue-hints (show-hint (-> editor .-codemirror)))
...))
:reagent-render
(fn [this] [:textarea])})))
(defn edit-panel [text]
(let [test (re-frame.core/subscribe [:issue-hints])]
[box
:class "issue-detail"
:size "auto"
:child [:div.issue-detail [editor text test]]]))
It works well when debugging the project, but once uberjar file is run, watch handler never gets called. What is the most strange thing to me is that if at least dummy reference to subscription atom is added, it works well again (eg. dummy #issue-hints in same let as subscription). Server round trip looks good.
Can someone give me explanation and/or suggestion for more reasonable fix/workaround?
It looks like you need two params in :reagent-render, not one -
:reagent-render
(fn [text issue-hints] [:textarea])}))) ---> Not "this", but should match initial args
When you only pass one arg, and it is not derefed in the component-did-mount fn, it won't receive the subscription on subsequent changes.
Further, I don't think that you need to explicitly use add-watch, as that is what the re-frame subscription is giving you ootb. By using the deref syntax #issue-hints, the element will be notified any time a change happens to issue-hints, and you should be able to watch the state from the app-db.
If you add the 2nd arg, my guess is that you could drop the add-watch and it should work as expected.
Here are the docs and if you look at the code sample, you see the repetition of the args...
----- Edit: Will Form-2 work? -----
(defn editor [text issue-hints]
(let [hints #issue-hints
editor (js/SimpleMDE. (clj->js {...})] ;;-> This will not be dynamic, so consider moving to returned fn if necessary
(fn [text issue-hints]
(if hints
[:textarea (special-hint-handler hints)]
[:textarea]
))))
So based on the comments, this would give you a watcher on issue-hints, and you could respond accordingly. The subscription does not necessarily need to be used on the DOM.
There are certain events that do not result in app-db changing. They only change the dom, e.g: init a custom scroll, getting the selected text, etc. How should I deal with them in re-frame, since the event handler requires to return a new app-db? I am getting around by returning the existing db, but it does not seem right. Is there a better way to do it? A few of my handlers look like this:
(re-frame/reg-event-db
:init-link-viewer
(fn [db [_ highlights]]
(utils/load-highlights highlights)
(utils/init-selection)
db))
You can use the reg-event-fx function to register an effect handler which returns an effects map (as opposed to reg-event-db which only returns db). Your effects map can be empty, and doesn't need to return a db. See Effects for more info on this.
You could rewrite your event as:
(reg-event-fx
:init-link-viewer
(fn [db [_ highlights]]
(utils/load-highlights highlights)
(utils/init-selection)
{}))
However you may want to take this further, and return your side effects as data. This means that your event handlers are easily testable, and decouples the event from it's side effects. This will mean that you need to write and register effects handlers as well. This could look something like:
(reg-event-fx
:init-link-viewer
(fn [db [_ highlights]]
{:load-highlights highlights
:init-selection true}))