Augmenting With Object Instances / Lifecycle Augments about backbone.augment HOT 5 OPEN

What kind of scenarios would you see augmenting an instance or augmenting with an instance?

I like the idea, but I don't know if it might benefit from a different naming scheme so that augments designed for one purpose aren't used for another, if that might happen. The way I've dealt with lifecycle augments is to augment upon instantiation, e.g.

var myInstance = new (MyGenericView.augment(augment1, augment2, etc))

I can see augmenting instances useful, augmenting with an instance should be fine as long as that object includes an augment method.

from backbone.augment.

Commented on #4 that I think might address some of the ideas here

#4 (comment)

from backbone.augment.

I'm not sure if I have a clear view of how to implement the suggested changes into Backbone.Augment yet, so instead I'll just give my thoughts on this so far.

I really like the idea of extending the constructor and initializer and I'd particularly like the idea to extend methods like render, show, close, etc. with multiple augmentations. It would definitely add a lot of power to mixins other then plain object extension.

If I understand correctly, the suggested approach here exhibits two ways of mixing in methods:

1. Hooking into the lifecycle of the target object, allowing the method of the target object and the method of the augmentation to both be executed even if they share the same name.
2. Directly extending the target object, possibly overriding a method on the target object if it happens to have the same name (unless the augment's method explicitly calls the whole Backbone.Whatever.prototype.method chain etc.)

I might be wrong, but I think the it would actually almost always be better to augment an object before instantiation. It would seem to me that an object, once instantiated, should not receive new methods and definitely should not have it's existing methods overridden anyways. If you decide to approach things that way, it could reduce some of the potential complexity.

I think the most important difference between the two mixing methods is if you want to override any target methods or not. Being able to extend a method without explicitly having to call the whole Backbone.Whatever.prototype.method chain from inside the extending method would make things easier.

I like the ability of mixInto to control which methods do and don't get mixed if such control is needed. But as I already said in issue #4, I think the list of methods to mix should be optional.

It would be nice if we could find an approach where Backbone.Augment handles as much of the specific augmenting and mixing as possible, preferably with a few simple, well defined and predictable behaviors. The augment property on the source object should probably be reduced to configuration or even left out completely if no configuration is necceary.

from backbone.augment.

A completely different approach would be to use Marionette.Callbacks to hook into the life-cycle of objects, such as views. Extensions that need to respond to life-cycle events of the target view could use those callbacks to respond to key moments in a View's life-cycle such as beforeRender, render, onShow, onClose, etc.

That would give lots of freedom:

• You could still leave the extending functionality contained within its own scope.
• It wouldn't clutter the view with all sorts of foreign properties.
• It wouldn't cause conflicts between separate extensions etc.

Backbone.Augment could then be left to it's originally intended functionality, which is IMO actually quite elegant and quite possibly doesn't need to be cluttered with all sorts of attempts to add more mixing conveniences that border on re-inventing inheritance.

from backbone.augment.

I think the mixInto plus some of the other things @derickbailey and @Rayraz have talked about have huge advantages on their own, and I think @Rayraz is on the right track in it being a separate solution.

I don't want to tie much more into augment unless it is very generic. Even the UMD wrapper was a concession for AMD and makes the code look more complex than it is.

I'm not too concerned about the complexities or having developers work more to get something out of augment. If you look at the jquery plugin pattern, that exists to take advantage of high flexibility and the user's adapted to the complexities that arose.

from backbone.augment.