-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
View childViewEvents should support trigger #3247
View childViewEvents should support trigger #3247
Conversation
Perf concerns.... I will have to run test to find out. Which will goad me to get the perf checker into the repo. Btw, the perf checker will always test against src vs lib. |
ab1278b
to
1c843fe
Compare
I wouldn't be so concerned about perf here since you probably don't have 1000 regions on a view like you might have on a collectionview which is already doing this.. except that.. for sufficiently deep views nesting on an existing app this is going to open the door to deep bubbling.. soo that could slow things down if not managed. |
@@ -300,7 +300,7 @@ describe('layoutView', function() { | |||
var ChildView = Marionette.View.extend({ | |||
template: false, | |||
onRender: function() { | |||
this.triggerMethod('content:rendered'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this signalling a move towards removing triggerMethod
in favour of just using trigger
everywhere instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not directly. That'd be #2508
However if this were a childView of a CollectionView
then trigger
would work. This PR is just about making sure that trigger
works in both places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@scott-w would you prefer another childViewEvents https://github.com/marionettejs/backbone.marionette/pull/3247/files#diff-0f13482af07d71e12b54fc8c40be7af6L293 to cover the triggerMethod
case?
@paulfalgout regarding perf. no noticeable degradation in render time. |
1c843fe
to
aec3eb9
Compare
I went ahead and added a test so this can get in. Hopefully the new test and the one that changed doesn't last as they're all pretty awful. #3248 |
aec3eb9
to
2061f12
Compare
I realized that `view._parent` was no longer in use in most cases and only related to a region. Then I made the proxy code a little drier and made the proxy cleanup on the region match the setup
@marionettejs/marionette-core I just realized that this change warranted some additional code cleanup. Can I get 👀 again? |
Until marionettejs#3247 is in, the `_parent` here will skip over the `CollectionView` and trigger on any `View` above the `CollectionView`. For that reason, currently setting the `_parent` here is a bad idea and users will have to listen to the `emptyRegion` or `emptyRegion.currentView`. Until a CollectionView can be treated as a parent of a Region we should leave this line out 😿 Additionally the emptyRegion should be destroyed on clean up
I think it all checks out @paulfalgout 👍 |
Until marionettejs#3247 is in, the `_parent` here will skip over the `CollectionView` and trigger on any `View` above the `CollectionView`. For that reason, currently setting the `_parent` here is a bad idea and users will have to listen to the `emptyRegion` or `emptyRegion.currentView`. Until a CollectionView can be treated as a parent of a Region we should leave this line out 😿 Additionally the emptyRegion should be destroyed on clean up
Until marionettejs#3247 is in, the `_parent` here will skip over the `CollectionView` and trigger on any `View` above the `CollectionView`. For that reason, currently setting the `_parent` here is a bad idea and users will have to listen to the `emptyRegion` or `emptyRegion.currentView`. Until a CollectionView can be treated as a parent of a Region we should leave this line out 😿 Additionally the emptyRegion should be destroyed on clean up
Until marionettejs#3247 is in, the `_parent` here will skip over the `CollectionView` and trigger on any `View` above the `CollectionView`. For that reason, currently setting the `_parent` here is a bad idea and users will have to listen to the `emptyRegion` or `emptyRegion.currentView`. Until a CollectionView can be treated as a parent of a Region we should leave this line out 😿 Additionally the emptyRegion should be destroyed on clean up
Until marionettejs#3247 is in, the `_parent` here will skip over the `CollectionView` and trigger on any `View` above the `CollectionView`. For that reason, currently setting the `_parent` here is a bad idea and users will have to listen to the `emptyRegion` or `emptyRegion.currentView`. Until a CollectionView can be treated as a parent of a Region we should leave this line out 😿 Additionally the emptyRegion should be destroyed on clean up
Until marionettejs#3247 is in, the `_parent` here will skip over the `CollectionView` and trigger on any `View` above the `CollectionView`. For that reason, currently setting the `_parent` here is a bad idea and users will have to listen to the `emptyRegion` or `emptyRegion.currentView`. Until a CollectionView can be treated as a parent of a Region we should leave this line out 😿 Additionally the emptyRegion should be destroyed on clean up
Until marionettejs#3247 is in, the `_parent` here will skip over the `CollectionView` and trigger on any `View` above the `CollectionView`. For that reason, currently setting the `_parent` here is a bad idea and users will have to listen to the `emptyRegion` or `emptyRegion.currentView`. Until a CollectionView can be treated as a parent of a Region we should leave this line out 😿 Additionally the emptyRegion should be destroyed on clean up
Until #3247 is in, the `_parent` here will skip over the `CollectionView` and trigger on any `View` above the `CollectionView`. For that reason, currently setting the `_parent` here is a bad idea and users will have to listen to the `emptyRegion` or `emptyRegion.currentView`. Until a CollectionView can be treated as a parent of a Region we should leave this line out 😿 Additionally the emptyRegion should be destroyed on clean up
Until #3247 is in, the `_parent` here will skip over the `CollectionView` and trigger on any `View` above the `CollectionView`. For that reason, currently setting the `_parent` here is a bad idea and users will have to listen to the `emptyRegion` or `emptyRegion.currentView`. Until a CollectionView can be treated as a parent of a Region we should leave this line out 😿 Additionally the emptyRegion should be destroyed on clean up
Resolves #2667 and #2464
This makes child events consistently work between both views for both
triggerMethod
andtrigger
Currently some bubbling exists between view types. This will add additional bubbling. Previous to havingchildViewEventPrefix: false
I would have been against the bubbling, but it can be managed easily now.However we may want to wait until
childViewEventPrefix: false
is the default?@rafde any other perf concerns? I like the consistency, but realize this might be doing more now.. however since it's regions on a view it is probably not an issue. If you think it is an issue perhaps we should consider breaking CollectionView such that it too only works with
triggerMethod
?I'm bringing this up now as we could introduce this #3244