flight-groups.js

// Flight Proposal: Groups

// Its useful to be able to structure components together
// so that we can manage their lifecycles.  We currently
// group components together using simple initialization
// functions which give us a rough structure but don't
// allow us to manage lifecycles easily which has given
// rise to nested components.  However, it's not desirable
// to couple one component to another in this way and
// departs from the self contained nature of Flight 
// components that give it so much flexiblity.  What
// if we had a mechanism that is external to component
// logic that allows you to define nested structures
// and manage lifecycles?  Here's one way of doing it,
// a specialized type of component called a group. These 
// would replace initializer/page functions. There's 
// also some scope to use our stricter this.attribute()
// semantics to control the flow of configuration data
// but I've not worked out the details of this bit yet :)


// define a group of components that make up
// a tweetbox
var tweetBox = defineGroup(function() {
	// attach to the root node
	this.child(TweetBox).attach({
		charLimit: this.attr.charLimit
	});

	// attach to a sub nodes
	this.child(GeoControl).attachTo('.geo');
	
	this.after('initialize', function() {
		this.on('closeTweetBox', this.teardown);
	});
});

// define your whole app as a tree of groups
// NB. would replace "page" functions
var app = defineGroup(function() {

	tweetBox.attachTo('#tweetbox', {
		charLimit: 140
	});

	homeTimeline.attachTo('#timeline');
});


app.attachTo(document, {
	// some options from the server
	userId: 4083095438
});

Anybody have any further opinions on this?

It seems to me: we have withTeardown and from TD experience it works. Maybe we could rally around that to make it as great as possible?

The idea here is that Im trying to keep apart structure of components in a particular application and the logic. withTeardown does allow you to manage lifecycles (and yes, is very similar to this, especially given that groups are just components) but it mixes it up with the component logic itself. I'm honestly not sure whether its over engineering the problem but I do see many examples where you might want a tweetbox component, for example, that doesn't have GeoControl but has AnimatedGifBrowser and it would be great to support that without having to noodle with the innards of the TweetBox component.

Re: Kenneth's comment, I adjusted the example to show that a group is a specialized component so it can manage its own lifecycle using events. There's no need to drop our no references to components thing here by handing out references to group instances, we don't need it elsewhere, we don't need it for groups.