App Life Cycle

[samccone]

Application objects should have a "start" and "destroy" method to introduce a formal life cycle to Applications.

MyApp.start();
MyApp.destroy();

var myApp = new App()
myApp.start();
myApp.destroy();

The call order would look like this

constructor
initialize

---

beforeStart
start

beforeDestroy
destroy

@marionettejs/marionette-core thoughts?

[jamesplease]

to introduce a formal life cycle to Applications.

I'm not sure if this is a good idea, but that is a separate discussion.

Assuming that it is a good idea, then the way this issue has been presented is correct per se. start and destroy are not analogous methods, so it's not telling the whole story by putting those as the representative methods for the issue, I think. To see what methods App is missing, we can review the lifecycle API of Marionette. There are two sorts of things, as I understand it:

constructor/initialize - Creation
destroy - Destruction

Something does not exist until the constructor has been called, and once destroy has been called, it should no longer be used.

Separate from that certain objects have lifecycle events while they are existing. These are start / stop. Applications have a start, but no stop. Modules have both.

This is likely due to the history of these two objects. Historically, there would be one Application that would never be destroyed – only started. Modules would be created that could be started and stopped.

Going forward, if we wanted to introduce sub-applications, then adding destroy and stop methods to the application would make sense.

To current users of Marionette, this change isn't as drastic as it might seem. If you strip the "namespace" functionality out of Modules; i.e.; the bit that lets you define them as:

app.module('my.namespace'); and then access them via app.my.namespace, then you end up with this exact API. The namespacing functionality will be provided through a separate library.

tl;dr

Apps may need stop and destroy methods.

[samccone]

I chose start because applications tend to start outside of calling new on them. initialize is still there but follows what Marionette.Object does .. like ever other marionette class.

you have to call start to start an app.

I can see stop being valuable as in applications could be reusable however I would love to enforce the concept of destroying an app, and to start it back up you just pass in state, since ideally the cost to starting would be low. But maybe having both stop and destroy would be a good idea.

I tend to remember the hell of view.close and how much better we have been since just enforcing .destroy

[paulfalgout]

I think apps/subapps need both initialize and start if on initialize listeners are setup that may handle when to start / stop itself.

Otherwise I don't see much point in separating the two, just always use initialize and don't exist if you're not running.

[jasonLaster]

Start seems nice bc initialize is different from start.

[ahumphreys87]

If we are naming it destroy then this implies it cannot be restarted, Are
we sure we don't want to allow people to restart their app?

I'm not against this I think it's a good idea to be explicit. However we do
currently start/stop modules - there is definitely a use case for
start/stop in whatever is replacing module

On Tuesday, 10 March 2015, Sam Saccone notifications@github.com wrote:

Application objects should have a "start" and "destroy" method to
introduce a formal life cycle to Applications.

MyApp.start();
MyApp.destroy();

var myApp = new App()
myApp.start();
myApp.destroy();

The call order would look like this

constructor

initialize

beforeStart
start

beforeDestroy
destroy

@marionettejs/marionette-core
https://github.com/orgs/marionettejs/teams/marionette-core thoughts?

—
Reply to this email directly or view it on GitHub
#2200.

[benmccormick]

I'm with @jmeas here. Start and stop should be paired, as should init/destroy. Don't have one without the other, for consistency if nothing else. Adding both would be a nice transition for those using modules as subapps as well.

[paulfalgout]

warning shameless plug ahead

I've spent a lot of time lately in our own app with our app life-cycles and pulling out the patterns to create Marionette.Toolkit. We initially were trying to get away from our dependence on modules, while cleaning up our organization.

The pattern that seemed to consistently affected our decision I think we took from @brian-mann early on.

startSubApp: function(appName, args) {
  var currentApp = this.module(appName);
  if (this.currentApp === currentApp) {
    return;
  }

  if (this.currentApp) {
    this.currentApp.stop();
  }

  this.currentApp = currentApp;

  currentApp.start(args);
},

This kind of state routing type logic would be far more complex if it had to check if the app was destroyed and then re-init it or something.

Really you want to be able to init an app that either has its start/stop handled by something else, and/or that it perhaps handles it itself.

We found the issue around start/stop was all of the listeners that may be added during this portion of the lifecycle. Our solution to this was to register any event added between start and stop, and to remove them when the app stops.
https://github.com/RoundingWellOS/marionette.toolkit/blob/master/docs/abstract-app.md#event-management

We found 3 major concern involving an app type object

• It needed an init/start/stop/destroy lifecycle
• It needed to be concerned about listeners added while running.
• It needed to have an easy way to have it's lifecycle managed by something else without adding a bunch of boilerplate.

I also know there are some concerns about an app-type object existing at all, relying on simpler objects and a smarter router. While I think this is certainly a reasonable pattern, I don't know that it is everything for everyone. I am 👍 on an app object, but I am very biased.

[jasonLaster]

Nice toolkit docs @paulfalgout! I think you've got the right idea. Would like to get some of this into Mn proper

[paulfalgout]

🎉 🐎

[paulfalgout]

@marionettejs/marionette-core I'd be ok with closing this. While I will continue to use an app lifecycle pattern, I think it is overly opinionated and not needed in Marionette.

[paulfalgout]

Got another thumb.. so re-open or comment if you want to discuss this further.

[alexone077]

Can someone provide an information about lifecycle methods marionette vs react?