Fork me on GitHub

I bought an early version of this course and its excellent:


@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


@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


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


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


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


the component local state support is modeled after React’s


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?


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


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


it’s not really the “containing" component


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


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


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


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


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


sure but in Om almost everything is just data driven


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


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


the whole point is to avoid event subscription publication model


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


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


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


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


in Om Next even that will be hopefully less necessary


Found this in the Communicating Between Components Section


"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."


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


if they do often a simple callback will suffice


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


or on a gist?


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


thanks for the pointers though


but post your gist here anyway


other people might comment on it


What are advantages of om when compared to reagent?


@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


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


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?


same link to gist by the way


and thanks for the help


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


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


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: