Fork me on GitHub
#re-frame
<
2016-09-11
>
mikethompson03:09:36

@rorydouglas @m9dfukc I've reopened the re-frame issue for this debounced event issue: https://github.com/Day8/re-frame/issues/233#issuecomment-246159519 Let's make sure we carefully detail the requirements, and then we can create a library.

bbktsk12:09:34

n00b here, making sure I understand things correctly: Instead of storing local state in an atom closed over by a form3 component definition I could save the local state to the react’s .state property, right? I mean purely local state that’s accessed only by the component.

bbktsk12:09:59

And another question, why is example for form-2 ( https://github.com/Day8/re-frame/wiki/Creating-Reagent-Components#form-2--a-function-returning-a-function ) using reagent/atom instead of just atom?

mikethompson12:09:46

@bbktsk I try as much as humanly possible to put ALL state into app-db. Everything just works when you do that. Very occasionally, I'm forced to use a local reagent.core/atom. I've never used the .state

mikethompson12:09:49

re-frame uses React underneath ... but that doesn't mean we adopt all its idioms.

mikethompson12:09:14

React is a little too OO for our taste (but we still love it)

mikethompson12:09:02

On your other point: it is REALLY important that your use reagent.core/atom and not clojure.core/atom

mikethompson12:09:56

Reagent components are reactive with respect to changes in a captured reagent.core/atom but changes to clojure.core/atom have no effect

bbktsk12:09:02

@mikethompson I’m writing a Google Chart component and need a place to store the chart object. Only the component uses so it makes sense to store it locally.

mikethompson12:09:38

I'm guessing the data for the chart has to come from somewhere

bbktsk12:09:00

@mikethompson regarding atom vs. ratom: I understand this difference, but please see the code I linked - it uses the ratom to store some local state and there is no way this atom can be accessed/changed from outside the component. It seems to me that the extra functionality of ratom is not needed.

mikethompson12:09:43

Please see my explanation. It has nothing to do with outside access.

mikethompson12:09:56

It has everything to do with the use of the ratom within the renderer

mikethompson12:09:10

A Form2 component returns a renderer fn

mikethompson12:09:56

When that fn renders, Reagent notices that it "depends" on a ratom (`seconds-elapsed` in the example you pointed out)

mikethompson12:09:11

When that ratom changes, Reagent will trigger a rerender

mikethompson12:09:37

So when seconds-elapsed changes value, the render will rerun.

mikethompson12:09:15

If it were a normal standard atom Reagent would not know about the dependency

mikethompson12:09:35

So changes to seconds-elapsed would not trigger a rerender

mikethompson12:09:12

So the component would get rendered once and never again.

bbktsk13:09:37

@mikethompson I’m probably missing something obvious, but in the linked example, it seems to me that the only way seconds-elapsed can change is inside the render method and when that happens, the new value is immediately rendered. Nothing else can access it, nothing else can change it so there’s no point for the extra functionality of ratom. Or is there some other way how seconds-elapsed can be changed?

rorydouglas13:09:31

@bbktsk the seconds elapsed doesn’t change in the render method, it changes in an anonymous function run by setTimeout doesn’t it?

bbktsk13:09:23

@rorydouglas AHA! Thanks! That was the obvious thing I was missing 😎

rorydouglas13:09:23

regarding internal state, i occasionally use a (let [state (r/atom {})] in my form-2 comps, though I often wondered about the state related methods in reagent itself and whether I should be using those instead (it looks like underneath they do the same thing, create a ratom & store it somewhere, though I don’t think it’s stored in .state)