This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-06
Channels
- # bangalore-clj (2)
- # beginners (55)
- # boot (32)
- # bristol-clojurians (4)
- # cider (16)
- # clara (13)
- # cljsrn (6)
- # clojure (110)
- # clojure-india (1)
- # clojure-italy (69)
- # clojure-spec (32)
- # clojure-uk (15)
- # clojurescript (102)
- # community-development (6)
- # cursive (1)
- # datomic (9)
- # docs (2)
- # duct (1)
- # emacs (39)
- # events (3)
- # fulcro (131)
- # garden (1)
- # immutant (4)
- # jobs (1)
- # jobs-discuss (5)
- # keechma (1)
- # lein-figwheel (6)
- # leiningen (6)
- # mount (6)
- # nrepl (2)
- # off-topic (69)
- # om (54)
- # parinfer (7)
- # re-frame (63)
- # reagent (13)
- # remote-jobs (1)
- # shadow-cljs (90)
- # spacemacs (8)
- # specter (6)
- # sql (16)
- # testing (1)
- # unrepl (3)
- # vim (4)
- # yada (1)
just got prerendering for my re-frame app working with chrome headless
yay! was worrying about SEO 🙂
@joelsanchez I'm sure it would be interesting to many people if you could package your work into a repo or blog
sure, will try to do so
=> https://medium.com/@joelsanchezclj/prerendering-a-re-frame-app-with-chrome-headless-bb875de31fd0
👍 PR to add it to /doc/ExternalResources.md
in re-frame? If so, there's a prerendering section at the bottom.
yes, I PR'd it yesterday, daniel merged it
Then add to https://github.com/Day8/re-frame/blob/master/docs/External-Resources.md
Something like this:
(reg-event-db
:indexinfo-update-chart-data-by-active
indexinfo-interceptors
(fn [indexinfo [_ active]]
(let [{:keys [cate active ktype]} (:chart indexinfo)
data (get-in indexinfo [:data :line])]
(-> indexinfo
(assoc-in [:chart :use-data :line] (case active
:all data
(indexinfo-cut-data data active)))))))
I have a large app-db
(with about 200 lines definition and max-depth of 5 or 6 level, in which many keys have large scale data) and the assoc-in
data is also large, for example a vector of 4000 items. I have some basic profiling using goog.debug.Trace
and the indexinfo-cut-data
runs about 200-300ms, but the whole event handler runs for seconds. I doubt the assoc
operation is slow, and want to improve the performance of this handler.
I want to know, what kind of operations about ratoms
are slow? Are there any related performance guidelines? Thanks.Does anyone know of an example of using re-com components with drag-n-drop events?
@cmal first, use re-frame-trace
to figure out where the time is going. Perhaps use chrome Flamecharts too. It won't be anything to do with atoms. To reset!
an atom takes 0ms. It is a trivial operation.
Also read: https://github.com/Day8/re-frame/blob/master/docs/Performance-Problems.md
@danielglauser I've done it but I don't have any public code
I used to point people to this resource: https://www.refheap.com/73581 (Reagent + HTML5 DnD)
But it has disappeared
@mikethompson Thank you very much for you help!
@danielglauser I have done a copy and paste of some working code which might give you "ideas". I remember the pain of DnD. https://gist.github.com/mike-thompson-day8/09b173d52575383841bd1fb5dbbe7ae1
I see, the component takes a long time to compare the props, which is a large data structure.
@mikethompson Thanks! I think this example will really help. It was mostly what I was thinking but there’s a few subtile points that I missed.
I added [day8.re-frame/trace "0.0.0-react16"]
to shadow-cljs.edn
, if [day8.re-frame/trace "0.0.0-react16"]
works in project.clj
, it maybe because of shadow-cljs
[day8.re-frame/trace "0.1.18-react16"]
Note: if you are not using react16 then leave that bit off
[day8.re-frame/trace "0.1.18"]
Also make sure you have [re-frame "0.10.4"]
@timok Have you read the docs? For example: https://github.com/Day8/re-frame/blob/master/docs/Testing.md
@mikethompson yes I did but there it's only reg-event-db. I guess it's anyway not so important for my usecase because I have mostly ajax-requests in there anyway and that's then more an integration test...
@timok If it's a unit test and you have broken out the handler function into its own defn
it can be as simple as:
(deftest my-handler-test
(testing "my-handler does a thing"
(let [cofx {:db {:foo :bar}}
event [:some-event "param1" "param2"]]
(is (= (my-handler cofx event)
{:db {:foo :updated-bar}
:some-other-effect [1 2 3]})))))
@U0J30HBRS does this mean I would not use the handler in reg-event-fx, but would extract it like in the reframe-docs mentioned with the reg-event-db?
Sounds like you're on it! You could paste some code here and I can confirm if it's what I meant :)
this would be like I understood it, I guess it might be better to put the destructuring into the handler-function to test this logic as well, right? https://gist.github.com/TimoKramer/14ec4c5b4ab005e12265cb8687bbfe2e
Look good! But yes, I tend to give all my event handling functions the [cofx event] type of signature (with destructurings and stuff) and just use the function var in the reg-event-fx.
So in your case, :set-active-page
would look like
(reg-event-fx
:set-active-page
set-active-page-handler)
Hi! I’m trying to debug what is causing a re-render of my whole application when a part of app-db is being updated. I looked at re-frame-trace and I’m seeing a input-signal on every redrawn component that is not of form “rxNNN” but “ra68", what is “ra68”? How can I track it down?
For instance the language field is not touched at all, the subscription is
(re/reg-sub-raw :language (fn [app-db _] (reaction (get @app-db :language))))
and the language-selection component still gets redrawn even though the value does not changeAccording to interop.cljs raNNN
is an RAtom
@mikko I think you may look at https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md
If you directly rely on the top-level app db, then any change to it will trigger your reaction
@mikerod thanks! Actually I found the bug, there was a rogue reference to the re-frame.db/app-db (that what’s the ra68 was!) directly in a place I was not expecting it. That was referenced “all over the place” causing re-renders every time app-db was updated.
This was not a waste of time since now I know a bit more on the internals of Reagent and Re-Frame. 🙂
@mikko good that you found it. Yeah, it can be tricky if you end up having a subscription that is dependent on the top-level and you can’t find it
What do you want to accomplish? I'm not sure I understand what you mean by "referencing".
using the :ref tag attribute to reference, for example, the contents of an input tag when pressing the “submit” button.
Generally, either re-frame events and subscriptions, or reagent atoms are used for setting and getting values of fields
Had a look on the todomvc and everything is clear now. I mistakenly thought that using reagent atoms were an antipattern
Cool! Ratoms are ok for state that's strictly local to a component. As soon as you feel like the state is part of a shared domain it's probably time to make it part of app-db.
@mikko when you saw the subscription in the subs panel, did it show as a layer 2 subscription?