I would really love to see this integrated with Blaze Components

[mitar]

This really looks so good.

Or make React Components. :-) With the same API as Blaze Components.

So how I see Blaze is that it is just an engine which renders a reactive state to DOM. An React is a similar engine. How exactly is then API build for components on top of it is then something which can be adapted. So it would be great to make the API the same (template language, class structure), just the rendering would be different and then we could really compare them. Or even use one where each of them are stronger.

[timbrandin]

Yeah, I have totally been thinking the same.

I'm reworking this a bit for SpaceDrop, which makes it possible to separate components and templates a little better, its all still in spacedrop core, but will move it out as soon as I've added in all functionality its still missing.

[mitar]

So some people were also asking for Blaze Components that it would be great to have Blaze templates, code, and style all in one file. Do you think that would be possible to achieve?

[timbrandin]

Yeah, that should be easy! 👍

[mitar]

Ooohhh. How!!! Teach/show me how! :-)

[timbrandin]

hey, why don't we design a Blaze 2.0 API that is a superbreed of react and blaze? with superclear taxonomy.

[mitar]

I prefer that parts are opt-in. So we have very basic core, and then we can build more packages on top which add extra stuff.

And frankly, I do not know what more I would add to Blaze Components. :-)

Read maybe this discussion: peerlibrary/meteor-blaze-components#79 (comment)

[timbrandin]

Though I'd move in this into a constructor:

ExampleComponent.register('ExampleComponent');

so it becomes:

this.register('ExampleComponent'); // or it could pick up the template with the same name as the class?

[timbrandin]

hehe, seems like we're on the same idea here, making a component that could be rendered by either framework! I do like that idea a lot!

[timbrandin]

And regarding registering you class on the global scope, we could do something like this instead which would work with es6 modules in the future:

export class ExampleComponent extends BlazeComponent {
}

[mitar]

No, constructor is too late. You have to register the class. I do not know how to go around registration though. Maybe a preprocessor could help here and add that call automatically.

See also this comment: meteor/guide#8 (comment)

[timbrandin]

Just my though, we're already doing a the preprocessing to parse the template. 👍

[timbrandin]

And can't we achieve the same effect by doing:

ExampleComponent = class ExampleComponent extends BlazeComponent {
}

[mitar]

No. Registration is needed so that you can do {{> ExampleComponent}}.

[mitar]

But I would not try to make API for classes for each rendering engines the same. I think that each rendering engine should have API which its users prefer. What should be common is the component tree and how to render a child component which might of different type.

[timbrandin]

alright, let me be a little more clear. what I meant is that we use the export before the class and that adds for example the registration.

[mitar]

Oh you mean export as our special keyword which does that? Maybe it would be better to use our own keyword then? Like register:

register class ExampleComponent extends BlazeComponent {
}

[timbrandin]

yeah that could work, though it would be nice if it followed the es6
modules standard so in the future it was actually an export.

2015-10-08 10:05 GMT+02:00 Mitar [email protected]:

Oh you mean export as our special keyword which does that? Maybe it would
be better to use our own keyword then? Like register:

register class ExampleComponent extends BlazeComponent {
}```

—
Reply to this email directly or view it on GitHub
#20 (comment)
.

Cheers,
// Tim Brandin @timbrandin https://twitter.com/#!/timbrandin
http://timbrandin.com
http://studiointeract.com

[timbrandin]

When Meteor finally implements es6 modules it would be nice to support it
I'm pretty sure they need to drop the global namespacing thing with the
templates, which in the future will be imported from the module with
import and export.

2015-10-08 10:17 GMT+02:00 Tim Brandin [email protected]:

yeah that could work, though it would be nice if it followed the es6
modules standard so in the future it was actually an export.

2015-10-08 10:05 GMT+02:00 Mitar [email protected]:

Oh you mean export as our special keyword which does that? Maybe it
would be better to use our own keyword then? Like register:

register class ExampleComponent extends BlazeComponent {
}```

—
Reply to this email directly or view it on GitHub
#20 (comment)
.

Cheers,
// Tim Brandin @timbrandin https://twitter.com/#!/timbrandin
http://timbrandin.com
http://studiointeract.com

Cheers,
// Tim Brandin @timbrandin https://twitter.com/#!/timbrandin
http://timbrandin.com
http://studiointeract.com

[mitar]

Hm, but this is not about symbol access. In fact, this often a direct opposite use case in the case of Blaze Components:

• or you create an abstract class you do not want to register because you do not want to use directly in templates, which you want that it is available to other parts of the code (you export it)
• or you register a class because it is something you want to use in the template, these ones you often do not want to export because they are used as it is

[timbrandin]

@mitar have you tested the latest version? Do you think we could get Blaze components using it?

[mitar]

Not yet. I still have to wrap my head around it. :-) This is all too magical. :-)

So probably what would be best to do is to split Blaze Components into even more limited core which can be supported both by Blaze and Sideburns, and then have on top more things which are more Blaze related (like animations). Or we might have to find ways to integrate that as well into React. So if you look at Blaze Components API. Do you think all that can be expressed in React as well?