Fork me on GitHub

i wonder if there is a recommendation when to dereference an atom in a let block and when not to? especially in regards to hiccup


@michael.heuberger If you are referring to A) deref an atom in the let block, or B) deref it inline in the hiccup ... my recommendation is A) to deref in the let block. It is of course just preference, but I find it easier to parse a component if all of the ratom dependencies are listed at the top of the component in a let block. Here is an example of the difference:


hey @gadfly361 what do think it’s best putting all the state in huuuge atom or having many different atoms tracking different states


does anyone have some example / docs around r/atom and r/make-reaction?


i’m trying to figure out how to do something lower-level r/atom offers, I think - I want to be notified when an atom changes so that I can invoke another function immediately following… seems like something make-reaction should do, but there’s just no docs that I can find.


@lwhorton: tried add-watch?


oh , hah...


funny how that works, knew it would be something simple, thanks @oahner


@stbgz: Any idea how big your data will be? re-frame puts everything in on big ratom and it seems to be able to grow to a pretty decent size and still perform well.


@stbgz: i reallt enjoy 98% using the big atom. Sometimes ill use a local atom for toggling a class or something simple like that (when making a generic, reusable component) ... otherwise, everything in a single atom is very convenient, especially for logging / debugging / testing.


@gadfly361 @stbgz My rule of thumb is, big atom holds everything that is a shared state. For instance if I have a form, I will usually store it in the local atom, because it’s not part of the shared state until the user submits the form. Also, like @gadfly361 said, I also tend to locally store any kind of bookkeeping that’s related to the component UI state (class toggles, etc.)


Hello, does anyone know how can i get props inside :component-will-receive-props? Or is there better way to implement it with reagent?


nevermind, got it, it's (nth in-props ...)


do we have to worry about components with local state ratoms after unmount?


i.e. if I have a settimeout that simply does a (reset! some-local-state :foo), and a component is unmounted before the timeout finishes - what happens?


I recently built a simple app with reagent and got some pretty terrible perf on mobile. When I hit a control or type something it takes a noticeable amount of time to react. I reduced the number of components by replacing {some-component …] with (some-component …) in key places. This got me back to a reasonable performance. What are some important things that I should know or that I should avoid to get good perf with reagent?


@lwhorton Yes and no... most things like what you describe wont really matter, but there are some cases where you don't want the action to complete if the component is no longer mounted... I use some helpers that take care of only doing things while the component is mounted in Reanimated, here is an example:!/examples.core/interval-example The relevant part is [anim/timeout ...] and [anim/interval ...] behave just like the JS versions except they don't fire when their parent component is unmounted. Feel free to use a similar approach (or just include reanimated as a dependency).


There's also a watch that only watches while mounted which I've found useful.