Should we recommend Blaze Components?

[stubailo]

I think it's pretty clear when you take a look at the application development landscape these days that people are pretty excited about reusable components. Blaze is a great templating system, but it doesn't quite give you everything you need to be able to reason about small parts of your app independently.

Mainly the issue is that it can be hard to look at a Blaze template and know how it will behave when used in different parts of your app. This involves a few issues:

1. The tendency to use global data via Session - partly because using Template.instance() all the time is a lot of boilerplate
2. The tendency to use global jQuery selectors, or HTML IDs, like $('.error')
3. The data context being passed from outside of the template means the functionality depends on the outside environment in a poorly-defined way
4. The way event maps work means they also catch events from child templates, which is something you might or might not want

@mitar, can you help me understand to what extent your Blaze Components package solves these issues? Unfortunately, you're right - I haven't had enough time to look at it in depth, but I would like to learn more now.

Copied below, the outline of the Blaze guide as proposed:

---

Blaze guide: The Tracker-based reactive templating system

Write “HTML with holes” just like you're used to, and get a fast, fine-grained, reactively updating page with no sweat.

1. Spacebars syntax, and how to use the built-in helpers
2. Building reusable components with Blaze
3. How to use reactivity in a principled way
4. Writing maintainable helpers and event handlers that aren't tightly coupled to HTML
5. Reusing logic and HTML snippets between templates

[tmeasday]

So, what is the status of this? I checked current published guide and it is really funny how much of the stuff there is just workarounds and long explanations for things which Blaze Components are already solving. It looks so much extra work needed to be done by developers.

It's a tricky situation because the current status of the future of Blaze is still being debated. I think we should see more clarity soon, and hopefully before the guide is "officially" released with 1.3. In the meantime it doesn't make sense right now to push developers further into the Blaze ecosystem and add a bunch of new concepts from Blaze Components to their vocabulary.

Basically our conclusion as of this writing is to have a Blaze article that outlines some obvious best practices and is a first step in providing a migration path to something more React-like.

BTW, @tmeasday, @stubailo, check out the new template-level event handlers support: https://github.com/peerlibrary/meteor-blaze-components#handling-events

Nice! BCs is definitely becoming more and more like what we'd discussed internally as a Blaze 2 (w/o React).

One thing I don't understand is this:

While it is recommended that you define only one event handler per event per element and then do multiple actions inside the component's code, you can still use the following syntax to bind multiple event handlers:

Why provide the syntax if you don't want people to use it? I would have just not included it in the first place, given it entails a bunch of complexity about order of execution and no doubt other things.

[mitar]

Basically our conclusion as of this writing is to have a Blaze article that outlines some obvious best practices and is a first step in providing a migration path to something more React-like.

But migration could be through Blaze Components. Blaze -> Blaze Components -> Sideburns -> React.

Why provide the syntax if you don't want people to use it? I would have just not included it in the first place, given it entails a bunch of complexity about order of execution and no doubt other things.

Not really. I just have to check if the value is an array of functions instead one function.

Because I cannot predict all use cases people might need. From Zen of Python:

Special cases aren't special enough to break the rules. Although practicality beats purity.

[mitar]

I think that what I am complaining about is that it is not even mentioned. I think one comment in the Blaze section that "there is Blaze Components package which wraps the patterns proposed here into reusable components, but we will show the patterns themselves" would be great.

[rhyslbw]

^ @mitar +1

[filipenevola]

I'm closing this issue because it's too old.

We are going to make many updates to the guide in the next weeks and it's better to focus on issues with recent activity. If you think this issue is still relevant please open a new one.