Hello all. Let me ask something quick: I'm having a problem with my subscriptions. Somehow, my subscriptions only worked when i reload the page (i go to the page, back to the previous page and then the data is loaded). Have someone pass through this before? i'm using the 1.0.0-alpha.2 version of reagent with a custom compiler with the function-components option set to true. I don't know if this interfere in something
(defn policy-details
[]
(fn []
(let [policy-details (subscribe [::subs/policy-details])]
[policy-details-view @policy-details])))
(defn policy-details-view
[policy-details]
[theme {:color-primary "#e6ac00"}
[print-pdf]
[form {:namespace :policies:*:policy-details:show
:class-name (:container style)}
[page-title {:icon [pdf]
:label (str (:policy-name policy-details) " | " (:policy-number policy-details))}]
[:section {:id "policyheader"}
[:div {:class-name (:itempolicyheader style)}
[start-date]
[label nil " Start Date "]
[:b (:start-date policy-details)]]
[:div {:class-name (:itempolicyheader style)}
[end-date]
[label nil " End Date "]
[:b (:end-date policy-details)]]
[:div {:class-name (:itempolicyheader style)}
[calendar]
[label nil " Next Settlement "]
[:b (:next-settlement policy-details)]]]])
Nothing incriminating at all, except that you can remove the inner function in policy-details
. But it shouldn't change anything.
(defn policy-details
[]
(let [policy-details (subscribe [::subs/policy-details])]
[policy-details-view @policy-details]))
I don't know if the fact of using a custom compiler is responsible for it
It shouldn't be. But I cannot really say anything for certain without an MRE.
Another example (reg-event-fx :policies:*:policy-selection:requested (fn [{:keys [db]} [_ & args]] (println ":policies:*:policy-selection:requested" args) {:db db :dispatch-n [[::customers/needed] [::agents/needed]]}))
(defn policy-selection
[]
(dispatch [:policies:*:policy-selection:requested])
(let [agents (subscribe [::agents/dropdown-options])
customers (subscribe [::customers/dropdown-options])
search-policies (fn [param value]
(dispatch [:policies-load param value]))
value-of (fn [key]
@(subscribe [::subs/attribute-value :policies:*:policy-selection:list key]))]
(fn []
[policy-selection-view {:agents @agents
:customers @customers
:action search-policies
:value value-of}])))
Don't use subscribe
in some callbacks that aren't called during the render phase, like view-of
might be.
But again, it shouldn't really affect anything, it's just a matter of potential memory leakage.
How would you code that value-of part? My intention is to avoid calling the same subscription with only one different parameter
It depends. If value-of
is called only during the rendering and not in run time when e.g. a user interacts with the component somehow, then your code is fine.
If it's for interactions, then you would have to subscribe to all the data that's required for :value
but that doesn't depend on key
and then create value-of
based on that data, so there no longer a call to subscribe
in value-of
.
The problem definition is very vague. What does "subscription is not working" mean? What does "the data is loaded" mean?
Sorry, let me explain better
I have an event that is dispatched when i click into a link and get's data from a service and show another page. In this another page, i have a subscription to get that data and fill the components with data.
What happens is that the data is not being showed at ti first time. I had to go back to the previous page and then click again so the data is showed in the componentes
I'm afraid these additional details have only muddled the water. :) There are too many moving parts and even more vagueness now. Can you create a minimal reproducible example?
I'll try
Another example is: i fill a select with data from a subscription. The data is showed in the select only when i back to the previous page and load the page that contains the select again.
We launched http://Pitch.com publicly today, front end is written with re-frame (over 125K lines of Clojure/ClojureScript all told) - thanks @mikethompson for making something that works so well at a large scale!
16💯415🚀8🎉That's awesome to hear, seems the launch is going great so far, lots of love all over Twitter ❤️ Would be great to have a breakdown of what issues you hit with cljs/reagent/re-frame at that scale. Basically a development post-mortem 🙂
2👍Good idea!
So with a separate ns for each component and page, where do you get your reuse, particularly of components?
Not sure if this is exactly what you're going for @jmckitrick, but here's a snippet of what it would look like for us:
(ns example.callback-button
(:require [reagent.core :as r]))
(defn CallbackButton
[]
(let [num-times-clicked (r/atom 0)]
(fn [{::keys [callback text]}]
[:button {:on-click #(do (swap! num-times-clicked inc)
(callback))}
(str text " " @num-times-clicked)])))
(ns example.main-page
(:require [example.callback-button :as cb]))
(defn Component
[]
[cb/CallbackButton #::cb{:text "A button"
:callback #(print "A callback")}])
(defn AnotherComponent
[]
[cb/CallbackButton #::cb{:text "Another button"
:callback #(print "Another callback")}])
With most of the complexity of the component in the respective ns, and other pages / components simply pass the high level info needed
wow congratulations
looks great
> So with a separate ns for each component and page, where do you get your reuse, particularly of components?
Not sure I understand the question. You have e.g. a my-proj.calendar
ns, and you use it just as is, as a whole.
If you need to share e.g. a single event handler function out of that ns, then you have to think what kind of dependency that is. Is it something that belongs to the calendar but is just used some place else, or is it something just common for different things? If the former, you don't extract that function and just keep using my-proj.calendar
. If the latter, you extract it into my-proj.common
or whatnot.
can u show a small piece of code with the component and the subscription in it?