Similarities between React and Blaze

I’m starting to learn React. One thing that helps me to learn is to find the common ground between what I already know and what I’d like to learn.

What are some good examples of similarities between React and Blaze?

For example, here’s a similarity in the way you can create a component, give it some data, and add it to the dom :

// data context
let data = {’value’:xx}

// react
let component = React.createElement(MyReactComponent, data);
let target = document.getElementById(‘container’);
ReactDOM.render(component, target);

// blaze
let component = Template.MyBlazeComponent;
let target = document.getElementById(‘container’);
Blaze.renderWithData(Template.MyBlazeComponent, data, target);

In the soon-to-be-released Meteor Guide we have a section on building reusable components with Blaze, which takes some pointers from React, like internal state, validation of arguments, and more:


the guide rules, I suggest everyone to read it!

here is another similar technique, composing classNames based on some conditions :

From the popular React package :
var classNames = require(‘classnames’);

var Button = React.createClass({
  // ...
  render () {
    var btnClass = classNames({
      'btn': true,
      'btn-pressed': this.state.isPressed,
      'btn-over': !this.state.isPressed && this.state.isHovered
    return <button className={btnClass}>{this.props.label}</button>;

From the meteor guide

<template name="myTemplate">
  <div id="my-div" {{classes 'foo' 'bar'}} {{backgroundImageStyle 'my-image.jpg'}}>My div</div>

  classes(names) {
    return {class: => `my-template-${n}`)};
  backgroundImageStyle(imageUrl) {
    return {
      style: {
        backgroundImage: `url(${imageUrl})`

Hi Sashko,

Awhile ago, I remember you mentioning that your motivation for writing the validated-method package was that you experienced the necessity to write a lot of boilerplate code to write methods using best practices (validation, testing, etc.). There were also some less-than-obvious features that were exposed, such as returning the stub value by default.

I was wondering if you experienced anything similar while writing/studying for the reusable components chapter. Any discussions about doing something similar for reusable templates? Do you see any value in that? Maybe something along the lines of having the validation “built in” to the template rather than having it sit in the onCreated callback. I also don’t want to miss out on any secret features!

I hope this isn’t interpreted as a request or anything like that. More curiosity than anything. The guide is getting the gears spinning in my head… and it’s not even done yet.

Thanks for your time,


1 Like

Similarly, gaps in the platform highlighted by the guide can often be plugged by community packages; we hope that if you see an opportunity to improve the Meteor workflow by writing a package, that you take it! If you’re not sure how best to design or architect your package, reach out on the forums and start a discussion.

That’s one of the goals! We hope that by highlighting common issues, we can expose some of the gaps that can be filled by carefully constructed packages.

I’d encourage you to:

  1. Make your package small, so that it can solve one problem very well
  2. Get a lot of feedback from people in the community about the design and see if it works for them
  3. Get some people to use it in production

Then we can include it in the guide!

Here is how to enforce incoming parameter types.


export class Counter extends React.Component {
  constructor(props) {
    this.state = {count: props.initialCount};
Counter.propTypes = { initialCount: React.PropTypes.number };
Counter.defaultProps = { initialCount: 0 };


Template.Lists_show.onCreated(function() {
  this.autorun(() => {
    new SimpleSchema({
      list: {type: Function},
      todosReady: {type: Boolean},
      todos: {type: Mongo.Cursor}
1 Like