Decorating blaze-component as webcomponent

[emmanuelbuah]

@mitar If you don't mind, I'm going to build on what you have here and make blaze-components usable/accessible as webcomponents similar to https://atmospherejs.com/numtel/webcomponent. That will allow the use of blaze-components from

{{> mycomponent k='foo'}} 

to

<mycomponent k='foo'></mycomponent> 

//better yet
<mycomponent k='{{reactivedata}}'></mycomponent>

I will take sometime to digest you code. Is there any gotcha's I need to be aware of. Thanks for putting this together.

[mitar]

I will copy a comment from here:

My current plan is to allow wrapping web components into this components. So that you could use Blaze, React, or Polymer components interchangeably. So if you define a Polymer Component inside a this system, you could still do {{#PolymerTag args foo='bar'}}...{{/PolymerTag}} which would then be rendered as a <PolymerTag foo='bar'>...</PolymerTag>. So instead of going the webcomponent direction, I see them only as one possible implementation of these components.

But I have to think more about this. In any case, with current Blaze something like you are suggesting is not really possible. It would require changing the parser. So a job for somebody else.

This is the reason why there is also a base component package. The idea is that that package shares common API so that you can use components interchangeably, no matter the rendering engine.

But I do see that your approach here is a bit different. The idea is that you can use the webcomponents syntax to use it? I think this could work. I would suggest that you map:

<FooComponent foo='bar' />

Into:

{{> FooComponent args foo='bar'}}

And:

<FooComponent foo='bar' >content</FooComponent>

Into:

{{#FooComponent args foo='bar'}}
content
{{/FooComponent}}

Why do you use <content></content> in Blaze templates? Wouldn't it be better if you would use {{> Template.contentBlock}} there?

And then <content></content> from the webcomponent use would be passed in as a content block?

In any case, I think Blaze Components provide you hook into this. See the chapter about block helpers in the README.

[emmanuelbuah]

@mitar I think syntax wise it doesn't matter but the aim of webcomponent is to make it no different from any other web controls we currently use so others don't have to worry about learning another syntax. ex. , we could define button as {{> button}} but I think I get your point and you get where I'm coming from. I think since webcomponent based on blaze-component will be use in meteor, it doesn't matter because users will already be used to the {{}} sytax.

Another aspect I will be interested in via webcomponents is inter component communication via direct event handler. Ex. assuming a webcomponent decorated blaze-component "editItem" which raises an "on-save" event, other components can interact like following:

Note:I'm not a coffeescript user so the code translation below might to not be correct but pseudo wise, its should be readable.

<listItems list='{{items}}' >
  <editItem /*has an item=''"*/ property /></editItem>
<listItems>

//or per @mitar comment above, syntax wise, the above can be written as 
{{#listItems list=items }}
 {{> editItem }}
{{/listItems}}

in code-behind

class ListItems extends BlazeComponent{
...
events:function(){
   return this.events.concat({
      'click .item': this.onItemClick,
      'on-save editItem': this.onItemEdited
    })
},
onItemClick:function(event){
  var editItem =  this.find('EditItem');
  //NOTE: set edititem component's item property and show it
  editItem.item = this.currentData;
  editItem.show()
},
onItemEdited:function(event){
  //update item in list or database with changes  from event.data
...
 //hide edititem component
this.find('EditItem').hide()
}
}

class EditItem extends BlazeComponent{
...
events:function(){
   return this.events.concat({
      'click .btn-save': this.onSave
    })
},
onSave:function(event){
  //emit save event
  this.fire('on-save',this.item);
},
hide:function(event){
   //code to hide this component
}
}

[mitar]

Cool. It would be interesting to see this.

[offthegrass]

@emmanuelbuah this is exactly what I have in mind. Let me know if I can help to speed things up.

[mitar]

I propose this should be a separate package, but feel free to make any pull requests if you need any integration points or anything else. And feel free to ask anything about the package if it is unclear.

[emmanuelbuah]

@offthegrass Sorry for the late reply. Haven't started work on this yet due to some backlog work I need to take care of. I will post references to the project here when I get to it, else, if you want to start the project, go ahead and I can commit to it when I have sometime.

@mitar I agree. It has to be a separate package.

[mitar]

Hm, is there any features of Blaze Components needed for you to make this work?

[DominikGuzei]

@mitar i thought a bit more about this and think it actually does not make so much sense to unify the API for various rendering layers like react, angular etc.

The reason is quite simple: all of these libraries have different philosophies and people interested in React are not necessarily interested in blaze-components (and vice versa).

So it's not so much about the tech (it always sounds interesting to build abstractions) but more about if actual people would be interested in using it. We will also drop angular support from our roadmap, since it already includes the whole kitchen sink of dependency injection etc. - i don't think any die-hard angular developer would be interested in anything related to space:flux or blaze-components :wink:

However React / BlazeComponents support will still make a lot of sense for us because they are very similar in the outcome although quite different in the implementation. Hope this makes sense to you!

[mitar]

Hm, I do not think we talk about the same thing. So as I explained here I really think that what is needed is a very basic core: common component hierarchy and a method to render a subcomponent.

But the API of each rendering engine class should then contain all other stuff which is closest what people using it expect.

What I am saying is that I am looking at the whole ecosystem. I would like that if somebody is using React Components for their work and finds a great Blaze Components package with some already made component they can use it in an interoperable way. And vice-versa.

I do not want fights in the future of the type "oh, this is so great menu Blaze Component, I wish I could use it in my React Components app". And then people rewriting that menu just so that it is in the other framework.

So I look at the base component you will see that there are just very few basic methods:

• naming a component
• registry of components
• dealing with component instances tree
• render a component

The last one is not yet finalized.

So I would like that if you are in the React, you could say BaseComponent.getComponent('MenuComponent').renderComponent() and it would work for you no matter if MenuComponent is React Component or Blaze Component.

I am not yet sure what would be renderComponent signature though.

[DominikGuzei]

Ok got you, but isn't the problem that React has a totally different way to render components? From what i understand is that you can easily render React components into blaze markup but i can't imagine it the other way round! React manages the DOM in a very abstracted way (virtual dom) that is not web-standard and even interfacing with jquery etc. can be cumbersome. So how would this work with server side rendering for example? SSR seems to be one of the main selling points of React, if it wouldn't work because of blaze-components, then i doubt a lot of people want to adopt this "mixed" style.

[pixelass]

@mitar while I understand your idea I think it would be fatal. IMHO it is not a good practice to use an angular menu, a React date-picker and some blaze components just because they already exist.

I am new to meteor and know that a lot of meteor developers don't really care about performance or loading too many libraries. It's OK but they should not be encouraged to do that.

@DominikGuzei I totally agree with your point about the differences.

We at http://codefights.com just redesigned our app with blaze-material-components (hopefully open-sourced next week). I tried to very closely replicate Polymers material-design implementation because it is simply the best one out there. I had a lot of trouble making them, being used to making Angular, Polymer, React and native web-components. Trying to use my knowledge about components on the blaze-components made things difficult at first. I did not use jQuery or underscore at all (I wrote it all in plain ES6) because neither are really needed nowadays. The issues I had were mostly related to one-way/two-way binding and conditionals and performance (still hurts)

ServerSideRendering: @DominikGuzei Yes!! this is something that I think should be considered a feature instead