There are a few changes required to convert your Ember app from using EmberFire to Fireplace. Here are a few that I found to be required. There are probably more.
In Ember, your state is separated from the UI inside models. But, often you want the state of your models to be represented visually in the UI via dynamic class names. Make it happen with
Ember Views are used for event handling and creating reusable web components. To make them useful and interesting, model data needs to make it into and out of the view. Here is an example of how this works.
In CoffeeScript there are two different types of arrows for defining functions: arrow (
->) and fat arrow or hash rocket (
=>). Usually, you’ll use the regular arrow. But sometimes you’ll want the special behavior of the fat arrow.
Ember’s convention of template hierarchy is very specific. Learn it once, and you’ll know it every time.
Ember is very specific about what version of Handlebars it requires. This is probably good, but it’s also a pain to work with as different versions of the two libraries are released independently. There are a few good tools to help us out.
Ember makes use of the wonderful Handlebars templates. These templates, in order to be performant, must be precompiled. Based on the Ember docs, it’s not abundantly clear how this is to happen. Here’s a solution that works well.