where the app creates the page and the page creates the widgets and communication is flowing through channels?
and how do you deal with url transitions?
do you capture and flow up the click from a widget back to the app so it knows it's time to render a different page? and have some (case ...) at the app level?
or using some kind of mix with secretary and changing the location.href/a hrefs?
Yep, that sounds about right. For us, API communication and some global events flow through channels into the app state, where it's distributed to components. For routing we've built up a library around secretary, where we write down a map of uris, handlers, and metadata (can be a modal, etc). Info about the current page and such goes into the app state and that drives the transitions between page components.
Comments
I'm interested in knowing more about how people are architecturing their Om projects
e.g. are you using something like:
app component <-> page components <-> (widget) components
where the app creates the page and the page creates the widgets and communication is flowing through channels?
and how do you deal with url transitions?
do you capture and flow up the click from a widget back to the app so it knows it's time to render a different page? and have some (case ...) at the app level?
or using some kind of mix with secretary and changing the location.href/a hrefs?
etc
Yep, that sounds about right. For us, API communication and some global events flow through channels into the app state, where it's distributed to components. For routing we've built up a library around secretary, where we write down a map of uris, handlers, and metadata (can be a modal, etc). Info about the current page and such goes into the app state and that drives the transitions between page components.