Fork me on GitHub
#rum
<
2017-01-13
>
martinklepsch06:01:47

Btw, not sure I shared this here before: made a few components to inject ssierra component systems into React context and start/stop them: https://gist.github.com/martinklepsch/8e8a924a9e2b3293688530e905fd3e4e

martinklepsch06:01:08

Not 100% decided you need component on the client but I like being able to swap implmentations. E.g. when developing while not having a network connection I swap my “internet database” with my “offline database” and the whole thing continues to work 🙂

leov16:01:26

@tonsky stupid question - why does rum reactive mixin requires custom deref function instead of some setup function on the atom it needs to watch?

dialelo16:01:19

because it needs to subscribe to the atom besides deref-ing it for gettings its contents

leov16:01:20

(I'm new to reagent, rum and react, though. I just currently set up my first app with one global atom, and subscribed to its changes where I wrote

(add-watch world :updated-world (fn  [_key _ref _old _new]
                                    (rum/mount (root-component) (js/document.getElementById "app"))))
  (add-watch local :local-world   (fn  [_key _ref _old _new]
                                    (rum/mount (root-component) (js/document.getElementById "app")))))
)

leov16:01:48

yes, but can a subscription be done once in the definition of component?

dialelo16:01:10

the reactive mixin is there so you don't need to manually subscribe to atoms and re-render, does just that

leov16:01:24

(defc root-component < (subscribe-to world) [] .. )

leov16:01:01

so I basically will not track in the header of component which atoms it was subscribed to, this is the purpose, right?

dialelo16:01:53

declare the component with reactive mixin: (r/defc root-component < r/reactive

dialelo16:01:04

and then you use (r/react world) inside component's body

dialelo16:01:16

this will make the root component rerender whenever world changes

dialelo16:01:18

hope it helps

leov16:01:23

ok, thanks

leov16:01:55

should I track umm server state and local copy state in two separate atoms?

leov16:01:25

in the very simplest case where I'm building a to-do list

leov16:01:30

or user list editbox

leov16:01:32

for example

dialelo16:01:16

> should I track umm server state and local copy state in two separate atoms?

dialelo16:01:33

that's probably overkill, you can store "transient" UI state local to a component

leov16:01:04

thank you

dialelo16:01:27

happy to help

leov16:01:53

last noob question - am I right that in React I must somehow update this internal state of any input-field component with on-change callback?

leov16:01:35

and the logic of display will be something like (or (internal-state component) (:server-field @server))

dialelo16:01:57

> I must somehow update this internal state of any input-field component with on-change callback?

dialelo16:01:22

this is optional, you are referring to what React calls "controlled components" https://facebook.github.io/react/docs/forms.html

dialelo16:01:45

but you can store input value state in the DOM just fine with uncontrolled components https://facebook.github.io/react/docs/uncontrolled-components.html

dialelo16:01:10

react can be a bit overwhelming at first but at least is reasonably well documented

leov17:01:07

yay thanks

Niki21:01:10

@leov re: custom deref. That way you can subscribe to atoms that are not in a global scope, eg passed as arguments