This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-08
Channels
- # bangalore-clj (4)
- # beginners (88)
- # boot (12)
- # cljs-dev (10)
- # cljsjs (1)
- # clojure (284)
- # clojure-denmark (2)
- # clojure-dev (35)
- # clojure-italy (8)
- # clojure-russia (36)
- # clojure-spec (38)
- # clojure-uk (51)
- # clojurescript (145)
- # cursive (6)
- # data-science (1)
- # datomic (8)
- # duct (43)
- # emacs (9)
- # figwheel (2)
- # fulcro (29)
- # graphql (1)
- # immutant (3)
- # instaparse (1)
- # jobs (1)
- # jobs-discuss (1)
- # lumo (16)
- # off-topic (50)
- # onyx (90)
- # re-frame (6)
- # reagent (20)
- # remote-jobs (3)
- # ring-swagger (18)
- # schema (8)
- # shadow-cljs (141)
- # slack-help (3)
- # spacemacs (36)
- # unrepl (7)
- # vim (1)
- # yada (2)
@mikethompson @lovuikeng Are there any examples with deeply nested components?
Managing deeply nested, complex components was one of my main goal with re-alm. Each event/message gets routed to the appropriate component's event handler, where the component updates its own (logical) state.
@caleb.macdonaldblack sorry, can't remember
Given that re-frame recomputes all top level subscriptions every time the DB changes, is nesting state recommended over a single flat DB? For example, say I have a login component that stores an email and a password. I can either structure my app DB nested like this:
{:login {:email ""
:password ""}}
or flat, like this:
{:login/email ""
:login/password ""}
I assume the former is more performant given you'd write your subscriptions like this:
(rf/reg-sub
:login-state
(fn [db _]
(:login db)))
(rf/reg-sub
:email
:<- [:login-state]
(fn [state]
(:email state)))
(rf/reg-sub
:password
:<- [:login-state]
(fn [state]
(:password state)))
Do you guys tend to structure your data nested or flat?We generally nest things rather than putting everything at the top level. You can still use namespaced keywords though