Can Reactjs be used as a View within Emberjs?


#9

I would like to extend this discussion with this blog post: http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/

I know the arguments in the first part of the piece are partially answered by Ember’s run loop. What do you think of the following ideas:

Because we always have the entire state of the UI in a single piece of data we can trivially serialize all of the important app state - we don’t need to bother with serialization protocols, or making sure that everyone implements them correctly. Om UI states are always serializable, always snapshotable.

This also means that Om UIs get undo for free. You can simply snapshot any state in memory and reinstate it whenever you like. It’s memory efficient as ClojureScript data structures work by sharing structure.

He then talks about playing back UI state like a VCR. I know there is more state than UI to worry, such as route state, etc, but this sounds very intriguing. Ember community thoughts on this?


#10

I’m using React as the equivalent of an Ember View in some of the performance-sensitive parts of our application. It was fairly easy to implement, the process was pretty much like using a jQuery plugin, you just need to hook up mounting and unmounting the React component in didInsertElement and willClearRender.

The main gotcha is that you need to make sure you call forceUpdate on the React component whenever your data is updated.

This is what the code looks like:

App.LibraryView = Ember.View.extend({
  didInsertElement: function() {
    this.set('reactComponent', ReactComponent({
      content: this.get('content'),
      view: this
    }));
    React.renderComponent(this.get('reactComponent'), this.get('element'));
  },

  willClearRender: function() {
    React.unmountComponentAtNode(this.get('element'));
  }
});

Within the React component you can then use this.props.content.get('...') and this.props.content.set('...') to get and set properties and this.props.view to access the Ember view instance. Note that within the React event handlers if you set a property using this.props.content.set you will need to explicitly tell React to re-render by calling this.forceUpdate().

The list on this page is implemented using React components: http://hummingbird.me/users/vikhyat/library

The source code is here: https://github.com/hummingbird-me/hummingbird/blob/3dcde76e906f86c438f4ca11fd54481e7bf8c53e/app/assets/javascripts/react/library.js.jsx


#11

Look interesting! The initial load takes a while but after the list is loaded, switch among list views is super fast. Do you have any data showing the performance gain of this approach versus a traditional group helper?


#12

I didn’t do any actual scientific measurements but the best performance I was able to get out of Ember using the group helper and everything static unbound was about 10-15 seconds to render ~600 entries. Render time with this approach was actually acceptable until I had to add an itemViewClass to handle the dropdown and a jQuery plugin I was using. The performance drop was probably because of having to create a virtual view for every row once I specified an itemViewClass.

My initial React test in which I just modified the itemViewClass to render the row using Discourse brought the render time down 5-8 seconds. After that I tried using React to render the full list and that brought the render time down to 2-4 seconds.

At the moment React is a lot faster but I don’t believe that will be the case once HTMLbars is a thing, because React re-renders everything to a virtual DOM when anything is changed, does a diff with the current state and reconciles things whereas Ember actually keeps track of what changed and would update only what needs to change.

React’s reconcilation is still interesting though, it makes server-side rendering very easy since you can render things on the server and when React is initialized it will only attach event handlers.


#13

Thanks @radq, this is really helpful comparison!


#14

HTMLBars is going to significantly change the performance characteristics of Ember, so I don’t think there will be much of a benefit to using something like React to improve rendering performance.


When will HTMLbars be ready?
#15

Note that the second render of React for big lists is currently unnecessarily slow because of an issue that makes it run in O(n^2) instead of O(n). This has been fixed by the following diff and will be available in the next version.


#16

How is the progress with HTMLBars now? Can’t wait to test it! :smile:


#17

Thanks for heads up!


#18

@krisselden and I are cranking away at it in our free time. I’ll be giving a talk at the SF Ember.js meetup on 1/21 about it. We’d love to have something to show for EmberConf :slight_smile:


#19

Cool! The meetup is already full … Do post the slides! :smile:


#20

Is there a writeup somewhere that goes over HTMLBars?


#21

You can find some words by @wycats


#22

Raynos introduced today an interesting benchmark on #reactjs http://jsfiddle.net/JD8Bj/

HTMLBars isn’t performing outstanding, to be honest the implementation of mercury virtual DOM seems to be the fastest one. Reactjs was on my chrome

mercury performed 21880 iterations in 571220 ms (average 26.11 ms per loop)

react : 3980 iterations in 477000 ms (average 119.85 ms per loop)


#23

I assume you’re referring to this?

  • Ember+HTMLBars: Performed 1040 iterations in 16743 ms (average 16.10 ms per loop).
  • React: Performed 1060 iterations in 19045 ms (average 17.97 ms per loop).
  • Mercury: Performed 1320 iterations in 24820 ms (average 18.80 ms per loop).

All 3 seem pretty much on par with each other (slight variations) yet HTMLBars still seems on top (Chrome 34 on iMac.)


#24

Yes, I just saw his post on freenode so i tested it out. HTMLBars came fine out, generally I would assume that reactjs performed most worst of all.

In my opinion, the best option with ember is to use the most closest or native solution (HTMLBars) and tailoring something else into the an ember project would create an unnecessary external dependency.


#25

Just watched

Highly recommend this video. I’m definitely sold on trying out React rather than just plain jQuery for the next bit dynamic client side UI.

I look forward to reading more about the possibilities of leveraging both React’s components with the opinionated nature of EmberJs.


#26

I don’t know how I feel after seeing the HTMLBars comment and the fact it’s a year old :smile: I am quite excited about the current diff implementation of HTMLBars and hoping to see it soon.


#27

I’d really love to use React with ember, I can use React with backbone, meteor, angular. really like the component idea, but writing a component isn’t as pleasant as writing a React component, I just can’t say why, it’s just feels that way, I love using ember-cli, git,bower,node… everything is so easy(if you know how to do it right), but writing template,controller, bind actions isn’t as fun as I’m doing with React. Currently I’m writing with meteor+react, just enjoying the codes.


#28