Should we keep using Ember Data?

[pereira_alex]

@varblob

I think this is where the problem begins, ember needs to have an official story for best practices around not using ember-data and clear statements that ember-data is not to be used in certain situations ie time series data. Whilst experience may make it obvious where ember-data is and is not useful, when people are just starting all signs point to ember-data AND when you do finally make the decision to not use ember-data for certain situations seems like your pretty much on your own.

I think this is dead on completly and exactly right. On top of this, maybe some addons to ember data ( like rpc or nested resources, associations/parents dirty checkings, etc ). I actually like ember data for what it does right! But then again, i “accept it for what it is”, and dont try to make it a huge beast with “hacks”.

@dagda1 … it is interesting and thanks for going throught the effort of trying to bring new ideas.

start rant: My idea and opinion of all current ember status is: Dont like it. Dont like it at all ! What appealled to me in ember is was the Router → Controller → View → Template. This gave me the knowledge of what to code and where : Route for model and data things, controller for app logic , view for display logic , template for … well template.

For all the Ember steep learning curve, coming from rails where i use draper all the time, it was like : Controller → Ember Route, View → Ember Template, Draper → Ember controller and view.

Its also similar to my experiences with WPF, using MVVM , where the controllers and views seem to be the ViewModel part.

Components are interesting, in creating reusable components. Turning everything in components is just an abuse. The same with DDAU, where granted most of things should be actions up, but i have a soft spot for 2way bindings and events ( made wonders in wpf with OnXXXChanged and 2way bindings with caliburn ( curiously , main dev was on angular2 )).

Seems to me that ember is trying to be ReactJS.

End rant. Now that i ended rant, i managed to create a perfectly DDAU, simulating almost what ember 2.0 is going to ( only missing was routable components, used empty controller with attrs hash ) … and it ended pretty great.

On the good side: Do love the Services workflow and DI!!!

[kylecoberly]

For what it’s worth, I’ve been using Ember Data heavily for a year now, and it’s fine. Not only do they not “keep throwing everything away and starting over”, the public API hasn’t even substantially changed in that time. To the extent that some stuff occasionally breaks through the release candidates, between the release notes and the console warnings, it’s not hard to figure out what to do, nor has it ever been very much work. If all you need is simple objects from the server, add an AJAX call to your model hook, or wrap it in a service, or overwrite the find() method in your adapter. You can do this across your application, or you can do it for specific models. Ember Data is for apps (or parts of apps) that deal with relational records, need caching, do type coercion, data transforms, compute properties, etc. If you can get by with POJOs, go ahead and use them. That’s not the case with everyone’s apps.

[dagda1]

I’ve created an ember-flow repo that is one commit old and has one passing test for if anybody is interested in getting some reflux in ember.

[zigomir]

That is interesting. Can you please provide an usage example?

Maybe we can continue discussion here where we already discussed some of data down, actions up and other flow related topics.

[dagda1]

I blogged about using a reflux like approach here and here is a todomvc example I quickly hacked together.

[amiel]

@misteroneill

The current needle in our eye has been nested URLs, which I see have been discussed at length on this forum - though the proposed solution(s) don’t seem to cover the case we’re running into. Most importantly, manipulating resource relationships by way of HTTP is not something Ember Data can do. But lots of APIs use nested URLs - both for creating new resources and for creating relationships between resources.

I’m currently working on https://github.com/emberjs/rfcs/pull/4.

@misteroneill Would something like url-templates cover your use case?

[MiguelMadero]

whats the issue you see with nested urls?

[misteroneill]

Whoa, this thread kind of blew up! Sorry to be MIA - I’ve been heads down charging for a (not “the”) finish line. Lots of interesting discussion here. To follow up…

whats the issue you see with nested urls?

It’s mostly around the intersection of relationships and nested URLs. If your relationships are embedded in some way in the JSON payload, ED works great. However, if managing relationships is only possible via HTTP requests to sub-collection URLs, it doesn’t work so great.

My solution has been to create a serializer mixin that allows serializer to declare a hash of relationshipLinks. Assuming a serializer for a “whatsit” model with a hasMany “foobars” relationship, it might look something like:

relationshipLinks: {
  foobars: 'https://url-for/whatsits/%@/foobars'
}

Then, the normalize method in the mixin takes that and populates the normalized representation with a links property… something like:

links: {
  foobars: 'https://url-for/whatsits/123/foobars'
}

This works fine for populating relationships, but not does nothing for saving them.

The best I’ve come up with in that case is to prevent relationships from being serialized on saves and make manual requests in routes or controllers to save relationships (in the case above, perhaps, a POST to https://url-for/whatsits/123/foobars to add a new “foobar” to a “whatsit”) when they are created/destroyed in the UI.

It does work, but it’s not the cleanest solution.

[amiel]

In case anyone is reading this looking for nested url support, GitHub - amiel/ember-data-url-templates: an ember-addon to allow building urls with url templates instead of defining buildURL might solve your use-case.

[haggis]

I’m currently working on my 3rd ember app and it’s the first which doesn’t use ember data for everything. The only reason for this decision was performance.

The apps purpose is to visualize measurements of up to 5000 channels with a frequency of 10hz each. Additionally a history of 400 records for each channel is needed client side as the “server” is a super weak breasted embedded device.

I ended up using an initial handshake which provides all metadata about the channels (= models with ember data) and having all the values stored in a big object as a property of a websocket service. That service receives a Float64Array of 5k values indexed from 0 to 4999 each 100ms.

Each channel model has a property ‘index’ referring the appropriate position in that array.

While using Ember Data for this freezed every non-dev-workstation the CPU load without ED is nearly irrelevant.

Thus, I like to use ED everytime when possible as it simplifies code and data storage a lot. It just not fits to every use case.