Fork me on GitHub
#om
<
2015-09-22
>
clojuregeek02:09:50

I bought an early version of this course and its excellent: https://twitter.com/ericnormand/status/646144572473524224

ul06:09:21

@darwin: yes, your PR is very interesting, i'm watching it from the beginning. i just have not enough time these days to try to integrate it. i will do at planned refactor next month

ul08:09:14

@darwin: and, honestly speaking, i feel that all our improvements (including applying re-frame to om, and then emulation of anonymous, lexical-scoped dbs in re-frame) are attempts to make from react/om/ragent/re-frame something, which is already partly implemented in hoplon

afhammad08:09:01

@ul, @darwin: These look great, I’ve been wanting to do this but now I dont have to!

staypufd20:09:59

I have a newbie type question about Om and how to use buttons to cause another sibling view to switch out. I was thinking I could use shared state but that seems global to the app. Is there a way to put the state in the containing component and then still get to it without passing it in all over? The page looks like: staypufd [12:36 PM] navbar across top, then buttons down side in there own div section the is 1/4 of grid, then another div for middle and right of screen. When a button is clicked on left, I want to set state and then react to that and switch out middle staypufd [12:36 PM] any help would be appreciated as I”m a noob to OM

dnolen20:09:31

@staypufd: Om components supports component local state, use that if it makes sense

dnolen20:09:50

the component local state support is modeled after React’s

staypufd20:09:36

I’ll look. I’m still not clear on the component that comes in as owner. Is that the containing component that your running build or build-all in?

staypufd20:09:40

If so I’d think you could put the state there. Like current-button-selected and then b/c your two sections (divs) both are children they’d be able to access that

staypufd20:09:54

so the buttons would call set-state in the parents local state somehow

dnolen20:09:26

it’s not really the “containing" component

dnolen20:09:39

it’s the real React component that knows how Om works

dnolen20:09:16

you write code that is delegated to for specific operations like rendering or lifecycle

dnolen20:09:04

you should read up on component local state in React and refer to the signatures provided in Om

staypufd20:09:04

I guess the simplified version of my situation is you have two sibling views, one with buttons that when clicked you want to have the other sibling view switch out it’s content

staypufd20:09:23

In iOS or OS X I’d do target-action

dnolen20:09:53

sure but in Om almost everything is just data driven

dnolen20:09:06

change some data and write some logic to react to data changes, that’s it

staypufd20:09:12

y - that’s where my neurons are tossed and turned

dnolen20:09:25

the whole point is to avoid event subscription publication model

staypufd20:09:23

Y - but I’m not sure how the sibling can write to one anothers data yet, b/c as you mentioned I don’t have a good understanding of how the data is structured and who can do what

staypufd20:09:38

have the React page you mentioned pulled up to read it though

dnolen20:09:04

@staypufd: well I should clarify the point is to avoid it as much as possible

dnolen20:09:36

people do coarse grained subscription via dispatchers, core.async, or something else

dnolen20:09:13

in Om Next even that will be hopefully less necessary

staypufd20:09:53

Found this in the Communicating Between Components Section

staypufd20:09:55

"For communication between two components that don't have a parent-child relationship, you can set up your own global event system. Subscribe to events in componentDidMount(), unsubscribe in componentWillUnmount(), and call setState() when you receive an event. Flux pattern is one of the possible ways to arrange this."

dnolen20:09:16

yeah but this is really for things that don’t share a parent

dnolen20:09:24

if they do often a simple callback will suffice

staypufd21:09:42

@dnolan - would you mind looking at a small code snippet here?

staypufd21:09:33

or on a gist?

dnolen21:09:06

@staypufd: sorry don’t have time to look at anything at the moment

staypufd21:09:19

thanks for the pointers though

dnolen21:09:21

but post your gist here anyway

dnolen21:09:26

other people might comment on it

mbertheau21:09:45

What are advantages of om when compared to reagent?

afhammad22:09:05

@staypufd: The easiest option as @dnolen mentioned would be to pass a callback to the child component that is triggering the action. You can pass it as :opts in the map argument to om/build. The callback would simply do a set-state using the parent’s owner (or “component” in ur case) and the value from the child, causing a rerender on the parent. then your get-state should work as-is. If its still unclear i’ll update your gist with some sample code

staypufd22:09:40

does the opts go on the buttons-view om/build?

staypufd22:09:11

OK - I updated the gist with the functions that show the buttons creation. One function with list of button names calls another to actually build the buttons. I’m assuming the callback would need to be passed in the :opts of those as well?

staypufd22:09:18

same link to gist by the way

staypufd22:09:28

and thanks for the help

staypufd22:09:54

I’ve been stuck on this for a couple of days b/c I haven’t been understanding how to do this

staypufd22:09:40

In my function right now for section-button-view I have it trying to set state on the owner, but that owner is not the same as the one with the component state so it seems from what your telling me that the :on-click I have in section-button-view will pull the callback out of the opts that’s passed in and call it instead

afhammad22:09:47

yes, so if you define the function in the parent and pass it to the child, the owner would be scoped to the parent. See this example: https://github.com/omcljs/om/blob/245d5b0a5837593e412f31c1eb2ac376b8ffa7b7/examples/state_bug/src/core.cljs#L26