Provide a way to get the component from the DOM element about meteor-blaze-components HOT 42 CLOSED

A class method makes sense. Currently I use @componentChildren('dotNav')[0] to get and update a sub nav. It would be much nicer to do @getComponent($('#dotNav')[0]).

Additionally I am currently using session vars to manage my titlebar name across pages. With this trick I can now do this:

  component = Blaze.getView($('#nav'[0])).templateInstance().get('component')
  component.titleVar.set(@currentCrop.get().localName)

But would rather do:

  @getComponent($('#nav')[0]).titleVar.set(@currentCrop.get().localName)

from meteor-blaze-components.

Not sure if I should open a separate issue for this question, but I wonder how I can access a component instance defined inside another one:

<template name="parent">
  {{> childComponent}}
  <button class="js-open-child-component">Click to open component</button>
</template>

Where childComponent is for instance a component with a boolean state (isOpen) and two methods (open() and close()). How can I open the childComponent by clicking on the .js-open-child-component button?

from meteor-blaze-components.

@mquandalle that is actually ver similar to what I am doing, but with nav state:

  events: -> [
    'click .next': @onNext
    'click .previous': @onPrevious
  ]

  onNext: (e, t) ->  @componentChildren('dotNav')[0].next()
  onPrevious:(e, t) -> @componentChildren('dotNav')[0].previous()

from meteor-blaze-components.

Not sure if I should open a separate issue for this question,

Please open separate tickets for questions. I like questions in the issue tracker (I have a special label for them), but it is great if they are with a nice summary.

Currently I use @componentChildren('dotNav')[0] to get and update a sub nav. It would be much nicer to do @getComponent($('#dotNav')[0]).

Oh, I think that accessing components using componentChildren is much cleaner. You do not want global IDs to access your elements, no? The last you access DOM, the better (and faster). You can also have a field/property on your component (like ID, but on the object instance) and then use @componentChildrenWith to find that component. This is the pattern I think is the cleanest.

It is true that maybe componentChildren is too fragile because it is only one step down the tree, but I expect the community to come up with some helper functions to help navigate children and parents better. So there could be interesting jQuery-like functions made.

Why I think that componentChildren is better is also because it is reactive.

@getComponent($('#nav')[0]).titleVar.set(@currentCrop.get().localName)

Oh, this is sooooo ugly. :-) Why don't you have rather something like (pseudo code):

@getRootComponent().findComponent(id: 'nav')[0].setTitle @currentCrop.get().localName

So the idea is that you traverse the tree of components and then access an explicit API your component is exposing to set the title.

@mquandalle, maybe something like this:

component = @componentParent().componentChildrenWith('isOpen')
if component.isOpen
  component.close()
else
  component.open()

from meteor-blaze-components.

@mitar In retrospect I was actually thinking on the same lines.

Oh, I think that accessing components using componentChildren is much cleaner.

Agreed, though my example could have bene better with scoped jQuery @$(selector)

Oh, this is sooooo ugly. :-)

Also agreed but is @getRootComponent().findComponent(id: 'nav')[0] necessary? Could we not get something cleaner? Also the nav component I am looking for is not in the competent root path. It is in my layout and currently FlowLayout does not appear to render components. That may need to get fixed (unless you know another trick :? ) I will make a separate issue after I am sure this is a true problem.

- layout
-- navComponent #found via "#nav"
-- basic page template from FL
--- currentPageComponent
---- childrenComponents

@mquandalle @mitar's example is almost the same as my code, though I used an internal check and called toggle(). Depends on your need. I try to keep as much logic internal to the class/component. Just an FYI

from meteor-blaze-components.

Also agreed but is @getRootComponent().findComponent(id: 'nav')[0] necessary? Could we not get something cleaner?

This is just how it could be implemented. API could be something more like jQuery or something. Like you could always do @findComponent on any component and if you do not specify the second argument, it starts from root component. Otherwise you can limit to some scope. But that is counter intuitive for me. I think going from the current component downwards is easier. And you then have to access the root component manually, if you want to search from there.

I do not know. I am not yet sure what are all use cases here. What would be cleaner for you?

It is in my layout and currently FlowLayout does not appear to render components.

I think you could do:

<template name="FlowLayoutRootComponent">
  <div id="__component-flow-root"></div>
</template>

<body>
  {{> FlowLayoutRootComponent}}
</body>

class FlowLayoutRootComponent extends BlazeComponent
  @register 'FlowLayoutRootComponent'

  template: ->
    'FlowLayoutRootComponent'

FlowLayout._getRootDomNode = ->
  $('#__component-flow-root').get(0)

But maybe @arunoda would have a cleaner solution.

from meteor-blaze-components.

Maybe it would be cleaner if FlowLayout would provide an extension point to return the base template. So instead of hard-coding the content injected into the <body/> that you would be able to tell the template which should be added to the body. But I think the good side of the FlowLayout is its simplicity and minimalism. So probably the approach above is good as well.

from meteor-blaze-components.

But yes, using Blaze.getView is a good way to do it when you are talking with non-component word. Or from outside of the component word, like some global event handlers or something and you want to get into the components. This is why I think we should provide such a method at some point.

from meteor-blaze-components.

Hmm no I have to agree with your context down approach. findComponent gets children and exists on all components. getRootComponent get the root component. Blaze.getView for odd cases, like FL. With this you can get components from the most efficient path.

FlowLayout is a separate issue. Currently it is not blocking so it may be best to let both of these packages mature and see how things settle. Though @arunoda may want to see this.

from meteor-blaze-components.

@offthegrass see this quick fix:

<template name="ExampleView"> <!-- render with FL -->
  {{> ExampleComponent}}  <!-- get the component you where looking for -->
<template>

from meteor-blaze-components.

@Kestanous, I do not think your approach works. The issue is that you cannot get to the sibling component (NavComponent) from ExampleComponent without a common parent component.

from meteor-blaze-components.

(At least not without going through Blaze.getView.)

from meteor-blaze-components.

My quick fix assumes Blaze.getView. I am actively using that now. It is ugly but it works. Thus the 'quick' or temp part of the fix ;)

from meteor-blaze-components.

Yea, that's why we have it. :-)

from meteor-blaze-components.

How should this be named? Because BlazeComponent.getComponent is not a good place. It is returning a component class. And our DOM -> component is in fact returning a concrete component instance.

from meteor-blaze-components.

Here's some:

getComponentFromElement
getComponentFromHTML
getComponentOfElement
getComponentOfHTML

from meteor-blaze-components.

OK, let's go with getComponentFromElement.

from meteor-blaze-components.

no!!!!!

from meteor-blaze-components.

What then? I see that Blaze internally use forElement and getElementView. So maybe getComponentForElement? Or getElementComponent?

from meteor-blaze-components.

component, element, module and sometimes even package are used to interchangeably between syntaxes (they shouldn't be, but they are) - for example, Polymer call their equivalent of a Blaze component an element, although that is changing to DOM-module as of 0.8

from meteor-blaze-components.

I will think and make some suggestions

from meteor-blaze-components.

I think DOM-module is something else, no?

So Polymer uses web components, but name things elements? Beautiful. :-)

But DOM element is an element? What is unclear here? We are mapping DOM elements to components.

You have 10 minutes for better suggestions. This is how long it will take for me to finish the tests and README. ;-)

from meteor-blaze-components.

@Instance, @DOMInstance, @getInstance

from meteor-blaze-components.

I think "instance" is way too generic. It is true that you get a component instance, but I think the core idea behind the method is that you get a component instance from a DOM element. So I think that something like "get component from/for (dom) element" tells more about what the method does. Perhaps getComponentForDOMElement?

from meteor-blaze-components.

getComponentInstanceForDOMElement?

from meteor-blaze-components.

forks package

from meteor-blaze-components.

getComponentInstanceForDocumentObjectModelElement?

from meteor-blaze-components.

climbs out window

from meteor-blaze-components.

push

from meteor-blaze-components.

hahah

from meteor-blaze-components.

OK, but really, I am almost ready to commit this. So what should be choose? getComponentFromElement or getComponentForElement?

from meteor-blaze-components.

(And sorry, names are verbose in this package. You have auto-complete, no?)

from meteor-blaze-components.

do it

from meteor-blaze-components.

OK, going with getComponentForElement. One letter less than getComponentFromElement.

from meteor-blaze-components.

If we had generics in JavaScript we could use ::getComponent<DomElement> :-)

from meteor-blaze-components.

FlowLayout now has a method for setting the root node

from meteor-blaze-components.

@offthegrass, that is great. Would you maybe add to the README a section how to use Blaze Components with Flow router now?

from meteor-blaze-components.

flow router, or flow layout?

from meteor-blaze-components.

Oh, layout.

from meteor-blaze-components.

done

from meteor-blaze-components.

One thing I noticed when I used Flow Layout with BC is that the components would be rendered separate from each other and have no access to each other unless you use getComponentForElement or getView. I tried to render a component to be the layout in order for the region components to inherit from it but it was not possible. Has anyone tried doing this or found a solution?

from meteor-blaze-components.

@offthegrass, @rclai, let's have a discussion about this in the pull request.

from meteor-blaze-components.