This can auto-merge properties, check that you are passing the correct properties, and there can be sesame.{development,production}.js builds that only check the type in development so that you don't have any performance penalty in production.
I also want to suggest that [un]bindEntityEvents be moved to utilities that do not live on the base object model (if they are needed at all).
Argument for removing [un]bindEntityEvents entirely (including modelEvents, collectionEvents, etc):
When you're working with views that have multiple models/collections, it's generally better to use named models/collections (this.user instead of this.zone). We've now made it a rule on our app that everything should always be named, and it has improved clarity dramatically.
This also means never using modelEvents and collectionEvents. However, TBH I don't miss them at all.
In fact, it might even be better without them, because we're using the same API we use all over the place rather than a couple of exceptions.
Creating an issue to start a discussion about how the base object model should work.
In Marionette there is:
I want to propose removing
this.options
,getOptions
, andmergeOptions
in favor of the React stylepropTypes
.This can auto-merge properties, check that you are passing the correct properties, and there can be
sesame.{development,production}.js
builds that only check the type in development so that you don't have any performance penalty in production.I also want to suggest that
[un]bindEntityEvents
be moved to utilities that do not live on the base object model (if they are needed at all).Argument for removing
[un]bindEntityEvents
entirely (includingmodelEvents
,collectionEvents
, etc):When you're working with views that have multiple models/collections, it's generally better to use named models/collections (
this.user
instead ofthis.zone
). We've now made it a rule on our app that everything should always be named, and it has improved clarity dramatically.This also means never using
modelEvents
andcollectionEvents
. However, TBH I don't miss them at all.In fact, it might even be better without them, because we're using the same API we use all over the place rather than a couple of exceptions.
I also want to propose changing
triggerMethod
into an internal utility for doing this:or just:
This is going to improve performance, rather than the weird string manipulation that there is now.
Also, custom
triggerMethod
's have had a tendency of being a source of confusion in our app.