Fork me on GitHub
#rum
<
2016-12-19
>
kauko06:12:18

The only problem with using re-frame with Rum is that re-frame has a hard dependency on Reagent's atoms and reactions

kauko06:12:31

You'd have to rewrite the internals of re-frame to use something else

kauko06:12:23

There are a number of libraries already that you could use to replace Reagent if you want to do that

kauko06:12:12

It seems most libraries that give your client code some structure depend on Reagent for the atoms/reactions. It's a shame, but understandable. I know only of @metametadata's excellent #carry library which doesn't rely on Reagent šŸ™‚ https://github.com/metametadata/carry

kauko06:12:29

All of these libraries are quite similar. One big difference, if we compare carry and re-frame, is that Carry doesn't have global state, instead all view-functions get their data as an argument. Re-frame's global state has the disadvantage of added "magic", but it can have better performance due to how React works.

kauko06:12:48

If I understand React correctly, because re-frame components don't get arguments, we can completely skip the should-component-update calls, and we avoid situations where we re-calculate a component because its arguments change, but in fact it wouldn't have to change.

kauko06:12:10

When we give the model as an argument, the least React will have to do is call should-component-update on our components. Needless re-calculations are avoidable, but due to programmer error we'll likely have some.

kauko06:12:55

By re-calculation I mean that React calls the render functions to get the new hiccup, or whatever format we use šŸ™‚

pbaille07:12:11

@metametadata, yes several instances of pure-frame that talk to each other sounds great

pbaille07:12:06

@metametadata, from your first comment, it is not clear but I think pure-frame has no global state, thatā€™s the point

pbaille07:12:56

@metametadata thanks for Elm link, looks interesting

pbaille07:12:14

@kauko, carry looks great I will definitely study it

pbaille07:12:45

@kauko "re-frame components don't get argumentsĀ Ā» ? Iā€™m not sure about that, is it like reagent components? take props as 1st arguments and follow the react lifecycle if it changes? reagent is a bit messy for that I think, if props changes, lifecycles methods are called but not if a ratom is changingā€¦ can be troubling at first...

kauko07:12:02

In re-frame you don't typically give arguments to your view functions, instead you use the subscriptions and whatnot.

pbaille07:12:26

oh I see, sorry

pbaille07:12:52

I donā€™t have much practice of re-frame

kauko07:12:40

And about the "ratom is changing" thing: lifecycle methods are called even when your argument is an atom (or a reagent/atom), but atoms are not compared by their contents. Instead, you just check whether it's the same atom or not.

pbaille07:12:47

if the first arg to reagent component change it trigger lifecycle, as far as I know

pbaille07:12:07

with ratom magic, no lifecycle I think

pbaille07:12:20

but I may be wrong

kauko07:12:59

Eh, I don't think it has anything to do with the order of the arguments šŸ™‚

pbaille07:12:50

when you call reagent/props

pbaille08:12:05

you get back only the first argument of a reagent component

pbaille08:12:44

I have to test this further

kauko08:12:55

Are you sure? Could it be just the arguments in a vector?

pbaille08:12:01

Iā€™m probably missing something

pbaille08:12:16

yes iā€™m sure

pbaille08:12:30

It cause me trouble at work

pbaille08:12:52

the rerendering model of reagent is tricky I think

pbaille08:12:18

I have to go, see you later, thank you

pbaille10:12:36

@kauko here's what i tried to explain šŸ™‚ from https://github.com/Day8/re-frame/wiki/When-do-components-update%3F Lifecycle Functions When props change, the entire underlying React machinery is engaged. React Components can have lifecycle methods like component-did-update and these functions will get called, just as they would if you were dealing with a React Component. But ... when the rerender is re-run because an input ratom changed, Lifecycle functions are not run. So, for example, component-did-update will not be called on the Component. Careful of this one. It trips people up.

pbaille10:12:22

maybe it is specific to re-frame, I believed it comes from reagent docs, not re-frame

kauko10:12:22

Yeah that's exactly what I was talking about too

kauko10:12:39

The thing is, the atom doesn't "change" when its contents change

pbaille10:12:31

"props" is the first argument or "the entire args vector" in this case?

pbaille10:12:39

don't know

pbaille10:12:44

should experiment

kauko10:12:55

"Props" in React are the arguments of the component, given by the parent.

pbaille10:12:21

ok so it is reagent/props + reagent/children ?

kauko10:12:49

Hmm I don't know what reagent/children does actually. It sounds like it would return the child components, but the docstring says Returns the children passed to a component.

kauko10:12:07

Why are we discussing this in #rum and not #reagent by the way? šŸ˜„

pbaille10:12:15

1st arg is props and others is children I think

pbaille10:12:24

lol you are right

kauko10:12:14

Huh, I think you're right. It looks like with React.js you always give one props object to a component.

kauko10:12:21

I didn't know that!

pbaille10:12:53

just ask for the lifecycle stuff on #reagent

misha10:12:20

parrot off topic police parrot

metametadata13:12:39

@pbaille yeah, I wanted to say that pure-frame doesn't define a global model var, but it probably still gravitates towards the usage of a single model per the application.

pbaille19:12:10

@metametadata, I donā€™t know, I have to do experiments on combining ā€œframesā€ together, sounds fun to try.

martinklepsch19:12:19

Did some work today consolidating global state in re-frame: https://github.com/martinklepsch/re-frame/pulls ā€” I'd eventually like to be able to use all but the subscription stuff with Rum (and perhaps other React wrappers) but that will probably take quite a bit longer šŸ™‚