How to handle multiple "sub applications" with unique stores / actions

[loudwinston]

I'm curious what approach you'd recommend for something like this. Please excuse my ignorance is this is covered in the docs but I didn't notice it.

Let's say I have an app that starts with a list of songs. Clicking on a song title launches a "Edit" dialog that lets me edit information about that song. This dialog might have several tabs, many actions that can be performed for this particular song, its own stores for various data, etc.

Let's say I want to be able to launch many of these dialogs at the same time, within the same browser window. In effect creating several sub-applications running on the page at the same time. Ignore the fact that this is probably a bad UX choice :)

It seems to me that each dialog/sub-application would need its own dispatcher and stores so that actions fired within that dialog would only affect the stores associated with that dialog (editing song information in one dialog shouldn't affect any other open dialogs).

In the documentation it states that the dispatcher is a singleton, meaning that an action dispatched from any of the dialogs would be treated as global actions and not tied to the "sub application" for the particular song that the action was fired for.

It seems like perhaps contexts could be the solution for this, but they are mentioned as a feature to handle isomorphism, not this use case.

What would be the best approach for this with marty? Any ideas/recommendations?

Thanks for any advice you can offer.

[dariocravero]

Hi @loudwinston, the way I see it, contexts should work. I'm probably missing something though because this doesn't seem to work:

import Marty from 'marty'
import React from 'react'

let Constants = Marty.createConstants(['TOGGLE'])
class ActionCreators extends Marty.ActionCreators {
  toggle() { this.dispatch(Constants.TOGGLE) }
}

class View extends React.Component {
  render() {
    return (
      <div>
        <button onClick={() => ActionCreators.for(this).toggle()}>toggle</button>
        <div>{this.props.v}</div>
      </div>
    )
  }
}

class Store extends Marty.Store {
  constructor() { this.handlers = {toggle: 'toggle'} }
  toggle() { this.setState({v: !this.state.v}) }
  get v() { return this.state.v }
}
let RStore = Marty.register(Store)

let Container = Marty.createContainer(View, {
  listenTo: 'RStore',
  fetch: { v() { return RStore.for(this).v } }
})

class Context1 extends React.Component {
  getChildContext() { return {marty: Marty.createContext()} }
  render() { return <Container /> }
}
Context1.childContextTypes = {marty: React.PropTypes.object.isRequired}

class Context2 extends React.Component {
  getChildContext() { return {marty: Marty.createContext()} }
  render() { return <Container /> }
}
Context2.childContextTypes = {marty: React.PropTypes.object.isRequired}

React.render(<div><Context1 /><Context2 /></div>, document.getElementById('el'))

I think it might be interesting to explore the idea of an app mounter concept, I don't know if it may apply or even be needed here (need to dig into it a bit better). We have that concept in Padrino and it's very handy to share/isolate stuff in apps.

[jhollingworth]

@dariocravero is correct, contexts are how you'd solve this in v0.9. Each context has its own dispatcher which should get around your issues.

That said, this is an area we're working on improving (See #261) so would love to hear what you'd like marty to do and we can see if we can help solve your problems

[loudwinston]

@jhollingworth @dariocravero Thanks for the response!

When I create a new context, doesn't every store that's in the default context get duplicated for the new context? This isn't what I want in this case, since the sub-applications don't need duplicates of every store in the application.

The API docs mention the Marty.createInstance method. Could I create a new Marty instance when creating my subapplication and register the subapp specific stores directly with this new instance?

I like the suggestions in #261, especially the idea of creating new Marty instances (rather than relying on a singleton) and the ability to do psuedo-DI using this.resolve(type) in constructors.

I'm gonna give this some thought..would providing suggestion of the kind of API I'd like to see be useful?

[jhollingworth]

Marty.createInstance() is another way of achieving this although would be a little trick if you're defining classes in the classic ES5 syntax.

Yeah, I'd love to hear your thoughts on what APIs would be yeah :smile:

[jhollingworth]

We're almost there with Marty v0.10 which should fix these issues. Going to close for now