Best Practice for Temporary Models in Forms?


Let’s say you have a “forgot your password” form. The model is obviously not going to be stored anywhere. It’s simply for the sake of processing the form.

What is the best practice? Alternatives I can think of:

  1. create an instance of an existing model. A downside is that this clutters the store. Especially as it’s implemented here it will create a new model each time the route is transitioned to.

    model: function() { return this.get(‘store’).createRecord(‘user’); }

  2. create a temporary model for the sole purpose to back the form

    model: function() { return this.get(‘store’).createRecord(‘temporaryuser’); }

  3. simply use a json

    model: function() { return {email:’’, password:’’}; }

  4. don’t use a model at all, simply get the values from the fields on submit action in the controller

    actions:{ submit:{ var email = this.get(‘email’); // get value of the email field in the form } }


I did see someone extending ember object instead of model for this purpose


thanks Wayne, Do you have any links?


Th 5) th way would be to simply skip the model and work with controller properties.


Wayne means something like:

Model Def:

var TempUser = Ember.Object.extend({
  email: null,
  password: null,


model: function() {
  return TempUser.create();


actions: {
  submit: function() {
    var email = this.get('email');

The Controller should be extended from a ObjectController in this case.


Sorry I’ve been hacking away all day at my own stuff. @samsinite Hit it


Thanks @Wayne_Douglas and @Samsinite!

A bouquet of final questions:

  1. We have now listed 6 alternatives (including yours) what is the best practice and why?

  2. Are there any benefits to using

    model: function() { return TempUser.create(); }


model: {
      email: null,
      password: null,
  1. Is it OK to skip the model, defined in a Router, entirely for forms, and use Controller Properties instead? It would certainly make for smaller file size, but is it a bad design decision?



@emorling the guides go over the advantages that an ember object provides over plain ol’ javascript objects. The biggest thing is bindings, computed properties, and observers. Do provide a model, worst case, a plain JS object as a model. If you don’t need bindings/computed properties/observes, than a plain ol’ JS object will be fine. Don’t skip the model entirely and just use controller properties, it gets messy fast.

File size doesn’t matter, you are talking about the different between bytes (not kilobytes). Even when you are talking about kilobytes, why do you think the difference between a couple thousands of bytes matter? Even mobile devices handle lots of JS allocated memory pretty well.


Points taken. Thanks!


I am trying to do something similar. I realize this post is 292 days old, which means it’s stone age technology in the web development world.

Is this still the best way to to use a temporary model, or has EmberJS added some new tools?



I’ve been wondering the same myself. I only need temporary models for my application and based on all of the information that I’ve gathered to date, this should still be the proper approach.

If you’re using ember-cli, I think that you should just be able to put your constructor/class in a service and your object instances/temporary models in that same service. Then you can inject that service into your route and return a particular object instance in the model hook.

With that method, I think the model will persist as long as the webapp is running. With Samsinite’s method, I think the model’s lifespan will be even shorter as it will be replaced every time the submit method executes.


I ended up just using the model itself (i.e. no temporary model, I just used the actual model itself), and used the rollbackAttributes function when I wanted to cancel any changes I made to the model.

This doesn’t actually answer the question of how to use a temporary model, but it solved the underlying problem for me so I figured I’d post it here.