Blaze and React component reusability

1

I’ve been using blaze before and now start to learn about react. So I see a lot of ppl talking about react’s components reusability, can blaze achieve the same thing? Can ppl please also explain the term ‘components reusability’?

2

From the horses mouth:

When designing interfaces, break down the common design elements (buttons, form fields, layout components, etc.) into reusable components with well-defined interfaces. That way, the next time you need to build some UI, you can write much less code. This means faster development time, fewer bugs, and fewer bytes down the wire.

https://facebook.github.io/react/docs/reusable-components.html

Personal experience - Most patterns are achievable in Blaze, they are just non-obvious. React makes reusable patterns really obvious, so you’re likely to use & benefit from them.

For example - passing callbacks to components.

React:

var Parent = React.createClass({
  doSomeAction(){
    console.log('some action happened!')
  },
  render(){
    return <Child  onClick={this.doSomeAction} />;
  }
})
Child = React.createClass({
  render(){
    return <button onClick={this.props.onClick}>Click Me!</button>
  }
})

Blaze:

<template name="parent">
  {{> child onClick=doSomeAction}}
</template>
<template name="child">
  <button>Click Me!</button>
</template>
    
Template.child.events({
  'click button': function(e, tpl){
    tpl.data.onClick(e);
  }
})
Template.parent.helpers({
  doSomeAction(){
    return function(){
      console.log('some action happened!')
    }
  }
})
2 Likes
3

I think maybe reusability is the wrong term - I think the place where React really shines is component encapsulation.

Basically, every React component has a very well-defined API - the props and context that it takes, and outputs DOM elements through a render function. When you’re using a well-designed React component, you can expect it to not leak anything out, and the developer of the component can easily communicate how the component should be used. It feels a lot like defining a function, or a Java class. There’s also a well-defined place to put component-local state - the helpfully named state property.

In Blaze, it’s a little bit less clear how to achieve a similar level of decoupling between different components. It’s not that the technology isn’t there - it is - but the API of Blaze encourages a less-encapsulated approach. Some of the problems:

  1. Automatically inherited data context means you don’t have to specify what data you’re passing into a child component
  2. Event handlers based on selectors mean that you can easily get events that originate from a child component
  3. There’s no clearly defined standard for passing data up the component chain (you can do it with callbacks or reactive variables, but it doesn’t “feel nice”)
  4. It’s cumbersome to store encapsulated state in a component - you need to refer to Template.instance() constantly, and make sure you handle reactivity correctly.

@mitar’s Blaze Components library tackles some of these issues: https://github.com/peerlibrary/meteor-blaze-components

Personally I’m a big fan of React at the moment because it seems like they managed to encode some best practices directly into the API so that it’s hard to create a React component that doesn’t follow a certain style.

2 Likes