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
});

Overall, this is very cool, and matches the "companion component" idea I've been talking about since forever.

I'd be very interested to see groupings of data, ui and scribe components this way. If you throw in templates and CSS too, you could build real blocks of UI. Could be fun.

I don't understand the "this.child" mechanic. What's going on there?

I think I like this, but it might be a bit limiting. For example how would I add more things to tweetBox group later? (thinking dynamic attachments)

Kenneth: Im guessing at API a bit here but this defines a group which you then can subsequently attach one or more of. This API would both allow the deferring of initialization of the child components and also let the code hook in to the component creation process so it can keep references of component instances for later teardown.

Angus: I'm not picturing a use case. Got an example of this?

I strongly believe we should let components tear down subcomponent instances.

var a = B.attachTo('body');
a.teardown();

Where a is not the component instance, but merely: { teardown: function()... }

I can't think of a good example, but I think if you can create instances, you should also be allowed to kill them. In every example of this (tweetbox, dialogs, autocomplete), the code could be written a different way, or handled with events, but would be more simply managed with an explicit teardown.

Afaict, this is possible using withTeardown, and it kinda addresses @kennethkufluk's comment too:

defineComponent(function TweetBox() {
    this.after('initialize', function() {
        this.attachChild(
            GeoControl.mixin(withTeardown), // the .mixin(...) could be automated
            '.geo'
        );

        this.on('closeTweetBox', this.teardown);
    });
}, withTeardown);

Grouping is different to nesting & trees of components, which is the problem withTeardown intends to solve.

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.