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

parent being overwritten #30

Open
herregroen opened this Issue Mar 6, 2015 · 1 comment

Comments

Projects
None yet
3 participants
@herregroen

herregroen commented Mar 6, 2015

When ampersand-view created a collection-view it explicitly passes along the viewOption of "parent: this". This option is then immediately overwritten by the collection-view when it sets the parent to itself.

Either the viewOption shouldn't be passed along, with documentation that the parent property can not be set, or it should be set correctly.

@bear bear added bug question labels Mar 6, 2015

@mmacaula

This comment has been minimized.

Show comment
Hide comment
@mmacaula

mmacaula Apr 27, 2015

This seems related to a bug I'm having as well. From one of the instantiated ItemViews, we used to be able to call this.parent which would be the collectionView, and then this.parent.parent which would be the original View that ran renderCollection(). However, that seems broken now, replaced with this.parent being the original View.

I'm not smart enough on semver but this seemed like a breaking change (at least it broke our code). Shouldn't the version have been bumped to 2.0? Once we knew about the problem, it was easy enough to fix, but ideally it would have never happened. I suspect it was #36 that caused the issue.

mmacaula commented Apr 27, 2015

This seems related to a bug I'm having as well. From one of the instantiated ItemViews, we used to be able to call this.parent which would be the collectionView, and then this.parent.parent which would be the original View that ran renderCollection(). However, that seems broken now, replaced with this.parent being the original View.

I'm not smart enough on semver but this seemed like a breaking change (at least it broke our code). Shouldn't the version have been bumped to 2.0? Once we knew about the problem, it was easy enough to fix, but ideally it would have never happened. I suspect it was #36 that caused the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment