This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-21
Channels
- # bangalore-clj (1)
- # beginners (60)
- # boot (30)
- # cider (7)
- # cljs-dev (10)
- # cljsrn (2)
- # clojure (163)
- # clojure-conj (10)
- # clojure-france (1)
- # clojure-greece (2)
- # clojure-italy (7)
- # clojure-russia (41)
- # clojure-serbia (22)
- # clojure-spec (41)
- # clojure-uk (41)
- # clojurescript (178)
- # cursive (36)
- # datascript (1)
- # datomic (23)
- # dirac (38)
- # graphql (12)
- # hoplon (20)
- # immutant (32)
- # instaparse (3)
- # keechma (1)
- # lein-figwheel (18)
- # leiningen (8)
- # liberator (1)
- # luminus (30)
- # lumo (29)
- # off-topic (18)
- # om (17)
- # pedestal (7)
- # planck (37)
- # precept (1)
- # re-frame (67)
- # ring-swagger (2)
- # timbre (1)
- # untangled (8)
- # vim (2)
(defn foo [kw]
... @some-r-atom ...)
(def foo-view
[foo :bar])
(rc/render foo-view app-div)
Now when @some-r-atom changes, I expect the div to re-render.
Is that correct? (Because it's not re-rendering)
@qqq yes, that’s how you should expect reagent & ratoms to work
generally if you’re not seeing that, then 1.) verify that you’re actually using reagent.core/atom
, not just the regular clojurescript atom and 2.) inspect the atom in your repl to verify that the change you expect is actually being made to the atom
@tanzoniteblack : will try that advice; thanks!
other random things that might cause that: use defonce
to create global atoms, so you’re not wiping state out when re-evaluating the NS in your repl (or figwheel)
😄 that would do it
a [func arg1 arg2 arg3] is re-rendered whenever: (1) a prop (arg1, arg2, arg3) changes OR (2) an r-atom taht func de-refered changes right ? and those are the only two conditions under which it re-renders
those are the only 2 things that you should count on to cause a re-render, yes
(however, I’m not familiar enough with reagents internal to guarantee that there is no other way in which a re-render might occur if react so felt like it for some reason)
@qqq be sure to read the tutorials in the last section of this page: https://github.com/Day8/re-frame/wiki Specifically: https://github.com/Day8/re-frame/wiki/When-do-components-update%3F
In reagent you have components that render subcomponents. Do you always structure your main components to “flow” data down to the subcomponents? The other option is to tie certain subcomponents to global state, so their data comes directly from an atom instead of their parent. this probably isn’t much of a problem when that subcomponent is only appearing once in the page, but makes them less reusable. So question is: is it ALWAYS better to gather all data from some component and flow it down to the subcomponents? this is very obvious when you want a reusable component, but for other things like rendering part of a page, it doesn’t seem really necessary to flow all data down when you can access a piece of info directly. Would you render a full page like this as well?
my current style is: (1) have a bunch of objects, they can only talk to each other via message passing
so there's "no global flow of state", but a bunch of objects, each of with it's own state
@naomarik I don't there's a single idiomatic way. Sourcing/subscribing to data at a higher level and then passing it down is often a good idea. But it can get a little laborious and inefficient in some cases. So, "it depends".
But unlike @qqq i would avoid going the objects sending messages approach - actors approach, I assume.
Did that for years. Love not doing it now. In fact, designed re-frame to avoid it.
The moment one says "It depends" ... that does beg the question "on what". So I'm sitting here wondering if there are any guides I know
i’m feeling the way that i’m starting to do certain things is passing IDs of relational entities down to child objects from the top, then i have all the info i need to subscribe to data from those subcomponents
Yeah, that is certainly a pattern
is there a lot of overhead of passing loads of data down? i’m not sure so this is why i started doing this
like if a subcomponent 5 levels down needs the data, you wouldn’t pass that all the way down from the parent would you?
Very little overhead. Because often the "id" being passed this time is the same as lat time. Ie. same prop
Remember that "props" must be =
tested to "last time"
so pretend you have frame1>frame2>…. all the way to a table that loops through the items, there’s no overhead of passing the data all the way down through the parent components?
That does sound a problem
this is why i started just passing references down, so the table itself knows what to fetch
I assuming these large vectors are changing in small ways
So that does seem like the eventual child should subscribe
so maybe a good pattern to follow is to just throw references down so the child can subscribe to it knowing the IDs it needs — like you said
Rather than having the data being passively passed through multiple layers
that way you just have a map of N keys which wouldn’t typically be larger than 10 for the most extreme cases
i think the other useful thing to have a discussion about is how you structure the client-side data to be able to do things like accept new info from the server and have it normalized so things aren’t repeated. i keep feeling the best solution to this is datascript. at the moment my client side DB is a map of {<table-name> {<pkey> <data>}} and this allows me to just assoc anything i want into it as i receive new information from the server. the downside is it’s a bit annoying to do filtering/data joining whenever i want a bit of information. i’m not sure what other patterns exist
before i did this, i was just building data structure that was easy to use for my UI hierarchy and it was a nightmare whenever my UI changed or needed to pull something a different way.
i feel that either datalog or querying my data in a graphql style would eliminate some friction i’m having with my subscription queries
hi, is there any roadmap for re-frame?
is there any way to get the value of a subscription into an event handler besides passing it in as part of the dispatch?
I mean in theory I could recalculate it from the app-db, but in this particular case that's expensive and somewhat convoluted
@mattly it's no FAQ (if not, should be)
(defn my-subs [foo] bar,,,)
(reg-sub :my-subs my-subs)
(reg-event-xx :my-event (fn [_ _] (subs/my-sub ,,,)))
There is no sugar to do that. There is already a bug with the tittle "an easier way to access subs from events"
what I'm doing right now (this is really hacky but) is I have a subscription that pulls in the necessary stuff and returns a function that calls dispatch with the needed values from the event and the subscription values
1) in the actual DOM event handler, I might need to .preventDefault
the event based on the app state and the event value
I can't do that in the dispatch handler because the react-wrapped event has "gone away" by that point, so to speak