Skip to content
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

Access to "view" #39

Closed
bensmeets opened this issue Apr 26, 2015 · 11 comments
Closed

Access to "view" #39

bensmeets opened this issue Apr 26, 2015 · 11 comments

Comments

@bensmeets
Copy link

Acces to "view": I'm already having trouble with everything related to views/templates/templateinstances and what not, I hoped the components wouldn't add to that list but abstract it all away. That maybe coming in the future. But until then I found that the only way to access the view the component is related to was through _componentInternals. Maybe something like a "getView" on the component? Preference is to abstract it away though :)

@mitar
Copy link
Member

mitar commented Apr 26, 2015

Care to explain why you need access to view? I hopped I already abstracted all use cases away. :-) And that you would not have to think about template instances and views at all anymore.

@bensmeets
Copy link
Author

Sure, it's because of the Blaze.remove() as mentioned here #36 . I wanted to be helpfull and group some feedback in the Q&A thread, but as I respond now I guess it's making a bit of a mess of the issues :).

So plz remove if needed.

@mitar
Copy link
Member

mitar commented Apr 26, 2015

I still do not get you. You render manually and you cannot keep the view object around, so you would like to be able to get it yourself from the component later on again?

@bensmeets
Copy link
Author

Yes, but just to be able to pass it on to Blaze.remove(). I use componentChildren() to find out all existing "panels" inside a viewstack component of mine. Having the component works, than just need to get the view of that component to be able to remove it once I click a "close" like button from within that panel.

@mitar
Copy link
Member

mitar commented Apr 26, 2015

Hm, should this be BlazeComponent.remove(componentInstance) or componentInstance.remove()? :-)

@bensmeets
Copy link
Author

instance.remove() has a nice feel to it. Makes more sense to me than BlazeComponent.remove() which only has going for it that it matches Blaze, but Blaze has no (apparent) parent/child relationships to factor in (as far as I know). Calling remove on the parent is more specific.

@bensmeets
Copy link
Author

On reading it again, I didn't get your comment correctly. There is one more (which I thought you meant):

  • calling parentInstance.remove(childInstance);

@mitar
Copy link
Member

mitar commented Apr 27, 2015

Yes. I thought more like instance.removeItself().

Good idea to remove children.

@mitar
Copy link
Member

mitar commented Apr 27, 2015

But probably it is better to remove itself, because you can always first access the child though componentChildren. Otherwise one cannot remove the root itself.

@bensmeets
Copy link
Author

true. sounds good!

@mitar mitar closed this as completed in 21d9160 Oct 12, 2015
@mitar
Copy link
Member

mitar commented Oct 12, 2015

Implemented as instance.removeComponent().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants