Fork me on GitHub
Drew Verlee00:04:54

Does anyone have any examples of using boot-reload with re-frame? I’m following I’m looking for a way to wrap my head around what boot tasks ill need to compose together to make this happen.


Hi all! I have composite component, which looks like that:

(defn user-view [user]
   [user-info user]
   [user-actions user]
   [(user-packs) user]
   [(add-pack-form) user]])

(defn user-component []
  (let [user (rf/subscribe [:user])]
    (fn []
       (when-let [user @user]
         [user-view user])])))
Also, you can see [(user-packs) user] in the user-view. This is because it contains subscription:
(defn user-packs []
  (let [packs (rf/subscribe [:packs/all])]
    (fn [user]
      (let [packs @packs]
         (for [pack-id (:packs user)
               :let [pack (find-pack packs pack-id)]]
           ^{:key (str "user-pack-" pack-id)}
           [:li (:name pack)])]))))
Is it idiomatic way to pass value of subscription (`user`) from higher order components to lower order? Or each compoment, e.g. user-packs, should subscribe to user value on their own?


@featalion I think components should subscribe to the data themselfs and only pass down the nessesary information for the lower components to subscribe (e.g. an ID or some sort). That way only the required components will be re-rendered (due to subscription changes) and not the entire tree.


@akiroz got it, thanks, make sense. But does it mean, that for a form with 5 fields it would be better to make 5 subscriptions for each field rather than one subscription for the form's map? The whole form is in the scope of one component. And, if so, does computation subscription over form subscription works well? I mean

 (fn [db _]
   (:form db)))

 :<- [:form]
 (fn [form _]
   (:input form)))


I don't think it would help to split the subs this way since any of the subs changing will just re-render the whole component (of course, React would further diff the input field value changes).... but I could be wrong


I personally use 1 map for the whole form.


thanks, I use one map per form as well, but I will investigate on the question ( :


Is it possible to write css pseudoclass attributes in hiccup?


sure, with garden you can compile hiccup-style data to CSS


how would I do that in a reagent project?


this is probably off topic for this channel but you'd do it just like with any other CSS: add IDs or classes to your DOM elements. Use garden to compile a CSS file and load it into your page.


there's a #css channel for this.


Thanks, I'll check both the solution and the channel. Have been missing a cljs css forum 🙂


bit of a warning though, the documantation for garden is not great.... when all fails, using raw CSS selectors in string form will work.


@akiroz cheers - what I was really hoping for was some way to add pseudoclass attributes inline in a Reagent project using Hiccup. In my current project, I already have a .css file that I would like to get rid of in favour of Reagent components with inlined styles.


But using Garden the way that you suggest is similar to what is already in my project - the problem is not that the css is not in hiccup form, but that it's not inlined in components.


A luxury problem, to be sure! But still 🙂


I've asked over in reagent but no one has answered, and my curiosity is getting the best of me. Does anyone have any idea how reagent's :component-function lifecycle key differs from :reagent-render?


grepping Reagent shows :component-function exactly once... and only in a test.


@joshkh, according to “Note: prior to version 0.5.0 you had to use the key :component-function instead of :reagent-render”


oh, hi the-person-whose-code-i-referenced. thanks for solving that mystery.


great component / example by the way


thanks 🙂 I’ve just got a notification in slack when “kishanov” token in URL was mentioned


i started a project a while ago using an uglier approach: use an interceptor to pull a path vec from the end of each event vec and sandbox the app-db appropriately:


just noticed the logging statements, oops! anyway, it means my handler functions can be written as though the app is stand-alone and not worry about concating paths in each one.