How to structure commits for a more complex Model

Design
1

I am coming from a non-MVC environment so this all is quite new to me, so any help is greatly appreciated.

I am trying to structure new application in Ember and in the proper way. I have something similar to this model:

User

  • First Name
  • Last Name
  • User code
  • Contact Addresses (list)

The User can be viewed on multiple screens/views - list view and then User detail view. I would like to be able to directly edit the User code and First + Last name from the list view and then all additional details from the User Edit view.

The way I had this structured before Ember (in jQuery) was that I had web services for different actions, some of which did partial updates:

  • UpdateFirstName
    • Partial update, fired when customer changes user’s first name from the list view
  • UpdateLastName
    • Partial update, fired when customer changes user’s first name from the list view
  • UpdatedUserCode
    • Partial update, fired when customer changes user’s user code from the list view
  • UpdateUser
    • Full update, fired when user is saved/updated from the edit user view

The nice thing about this structure was that it kept the web services simple and short. The negative was that UpdateUser had to replicate some of the functionality in the other web services.

It is a little strange to me to always send the whole model back to the server to update a small simple thing (from example just the user code) when I call .save() on a model. Is this the desired way, or would you recommend structuring things differently?

I am sorry if this has a super straightforward answer, I am still trying to learn to think in the MVC and Ember way.

Thanks!

2

If you’re just getting started, I would just send the whole model back to the server on update requests and call it good. The size of the payload is almost guaranteed to be trivial relative to the overhead of the request itself, and it’s the standard behavior you’d expect from an UPDATE request in a REST API. What you’re referring to is called PATCHing, and there doesn’t appear to be a good, tested, canonical answer for this in Ember Data yet (I’d love to be wrong if anyone knows otherwise). That said, it’s on the radar and people are working on solutions. You might want to track this discussion.

3

@kylecoberly thanks for such a prompt answer! I will stick with posting the whole model back to the server for now unless some issues come up.

I came across this addon but not sure if it is actually worth using.

4

I don’t know anything about the addon, but until you’re more comfortable with the ecosystem, I would stick with the standard stuff. BTW, when you’re evaluating addons, you can get a ton of great information about them via Ember Observer.

5

Thanks, that makes sense!