Analysis: Behaviors

[MeoMix]

Hey,

I just found myself with a bit of free time and agreed to read over some sections for @jdaudier. Here are my thoughts on the Behavior's section:

Sharing common view Behavior / What is a Behavior?

• The code example is slightly inconsistent. The first snippet uses triggers without a behavior. Then the "same code" is represented within a behavior, but now uses events. I think that this detracts from the intention of the example.

Listening to View events

The example itself here is good for conveying what a Behavior is, but I have some concerns about the correctness of the example. Is it really a view's job to be telling its collection to mark models as newlyAdded? What if there was no view -- should things simply stop being marked as newly added? What if the collection was shared between multiple views? etc... This entire example feels like a job for Cocktail not Behaviors.

I think using an example that's a bit more presentation-specific could be beneficial. Perhaps doing a 'mouseover/mouseout' + showTooltip concept. In fact, I see a tooltip example in the list of extended examples. I feel like this would be a better introductory concept, but maybe others feel differently.

Defaults

All of the defaults example stuff seems fine. Personally, I feel like behaviors should use a different term than 'defaults' since they're not accessed in the same way as BB.Model defaults. This has led me to confusion in the past, but that's not super related to the docs.

Misc

One thing I would've liked to see more talk on is an issue I raised in Mn issues a while back: marionettejs/backbone.marionette#2784. Even if the guide doesn't suggest one pattern or the other... I think it would be prudent to make people aware of their different options for view/behavior interactions. Passing methods down into the behavior vs having the behavior emit events which come back up.

Additionally, I didn't see any mention of nesting behaviors -- which is certainly possible :)

Overall, read well and had a solid amount of examples. I don't really expect people to take the examples at face value, but it would be nice to have a higher level of confidence in them just in case people do copy/paste the examples and assume they're best practice.

[scott-w]

Hi @MeoMix, cheers for this. With regards to architecting behaviours, I'll have to look through the options and see what's best. I'm completely open to suggestions on this as I do intend for the Guide to offer best practise recommendations for solving issues - basically, picking a pattern and pushing it as the "right way to do it".

My feeling is that this is the best way to introduce the concepts to new users who lack the background to give context to any decisions they need to make.