This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-24
Channels
- # admin-announcements (1)
- # aleph (3)
- # announcements (4)
- # beginners (30)
- # boot (296)
- # cider (21)
- # cljsjs (2)
- # cljsrn (18)
- # clojure (124)
- # clojure-poland (23)
- # clojure-russia (4)
- # clojurescript (73)
- # core-async (58)
- # css (3)
- # datomic (31)
- # editors (4)
- # emacs (35)
- # euroclojure (3)
- # hoplon (104)
- # immutant (8)
- # jobs (3)
- # jobs-discuss (1)
- # keechma (1)
- # ldnclj (33)
- # leiningen (5)
- # liberator (1)
- # mount (20)
- # off-topic (2)
- # om (104)
- # onyx (54)
- # parinfer (80)
- # proton (1)
- # re-frame (59)
- # remote-jobs (1)
- # ring-swagger (9)
- # slack-help (15)
- # spacemacs (7)
- # yada (12)
(ns povon-cljs.views.main.content.section2.core
(:require [povon-cljs.views.main.content.section2.chart-config :as cfg]
[reagent.core :as r]
[cljsjs.highcharts]))
(def Chart
(.-Chart js/Highcharts))
(defn build-chart []
(r/create-class
{:display-name "build-chart"
; The div from :reagent-render should be in the DOM at this point, right?
:component-did-mount
(fn [this]
(println "Component did mount")
(Chart. cfg/chart-config)
true)
:reagent-render
(fn []
[:div#hc-bar.container
{:style {:min-width "310px" :height "400px" :margin "0 auto" }}])}))
(defn section []
[:section
[:div.container
[build-chart]]])
should the div from :reagent-render
be in the dom when :component-did-mount
runs? I’m getting the highcharts error where “the element is not in the DOM when highcharts is being constructed"
if i run the function after the fact from the js console, it works, so my thought is i’m doing something wrong in terms of timing
@hoopes: have you looked over: https://github.com/Day8/re-frame/wiki/Using-Stateful-JS-Components ?
dammit, i knew it would be in the wiki. i’ll study that for a while. not sure how i missed it, i thought i read it all. thanks!!!
And there also: https://github.com/reagent-project/reagent-cookbook/tree/master/recipes/highcharts
hm - isn’t that what i’m doing above in the recipe? reagent-render puts the div in the page, and component did mount does the highcharts construction?
Could the error be because you are doing this:
(def Chart
(.-Chart js/Highcharts))
Sorry don't know anythign about highcharts
@mikethompson: thanks for the advice, any way I can have have a piece of code subscribe to changes and update the db?
I get asked this a bit. The thing to remember is that ONLY EVENT HANDLER CAN CHANGE STATE (sorry for the caps)
Which means we already know where any changes are going to come from
From certain event handlers
I'm talking about a certain kind of event handler that uses a subscription instead of a "message id"
We can then either: 1. add middleware like`onchange` on those event handlers 2. just use functions in the event handler
Hmm. Event handlers don't use subscriptions.
@nberger: Thanks for the fix! Any reasons why that's not triggering an error (arity exception?)
Well, if I want to listen to change in some part of the db (active-module, auth, ...) and update state in other part (error, ask-for-login, ...)
That's still event-handlery, but on-change means I need to wrap every function changing the state
In re-frame, events happen and then state changes. Before an event happens, the app was sitting quietly, in one state.
It is your event handlers who mutate state. Which then triggers the Components to rerender this new state.
So any "step forward" has to happen in an event handler
In your code above, there had to be an event handler which updated the state .... which you want observed, right?
So, if I;m understanding your correctly, you want an event handler to change some state. And then for other changes of state to be triggered as a result of that first change of state.
alos consider the onchange
middleware
https://github.com/Day8/re-frame/blob/master/src/re_frame/middleware.cljs#L197-L235
Ah, cool
We have to be slightly careful of things triggering, things, triggering things (complicated Signal graphs) because they tend to develop cycles and have "glitches".
We want a nice unidirectional flow of data
As an asside, part of what makes re-frame work so nicely is that all the changes you make in an event handler are revealed, to the rest of the logic, all at once (when the event handler returns the new db). There is no piecemeal updating of app-db
. This is to avoid the problems associated with partial updates flowing through the Signal Graph.
I'm only supporting the idea of having events not being only arbitrary names but also paths in the db, or reactions/subscription
When one change triggers another, triggers another, the system can be in odd states for some period of time, as the change ripple through.
Righto. Tell me how you go with on-change
It's just harder to see the data structure, because instead of defining your operations on data you defined them on arbitrary names
Righto. Thanks. Happy to talk further when you have somethng more concrete
I have a question about testing. It says in the wiki that event handlers are pure functions. But they aren't - at the very least, they can dispatch other events. How can I test that an handler is dispatching other events properly?
Perhaps you'll have to use with-redefs
as described here (except in your case, you'll be redefing dispatch
):
https://github.com/Day8/re-frame/wiki/Testing#components---part-2b
My concern is that the internal dispatch
is perhaps done async?
In effect, I'm worried that the with-redef
will have ceased to exist, when the async dispatch
happens (sometime later).
But, for the record, I would push back on your claims. The vast majority of event handlers are, indeed, completely pure. If that's not the case, then you are doing something wrong.
this might be a stupid question, but is it a bad idea to define a generic :get ks
subscription that just calls get-in @db ks
and a generic :set ks v
handler that calls assoc-in @db ks v
?
@jbaiter: not a stupid question (there are none ). We often take a middle ground where we have a handler for a section of the application, and then you pass a key to update the map in that section. For more complex updates, we'll write specific handlers
For subscriptions, we sometimes do the inverse, 1 subscription to the root of an application section, then make a bunch of reactions from that one subscription, refining the data we want in the reaction
@jbaiter: and we do similar things to @danielcompton too