Popular = Simple for simple things. Easy for hard things.
Building a simple App, all I want is get some JSON object from the server, mark it up and provide navigation to some other objects, no fancy binding just plain old JSON with markup and simple navigation.
This model (JSON) object has some properties on it and some nested arrays. One would think that a simple #each in handlebars would do the trick in the template but - heck nada - no nothing.
Like this: (abbreviated, not Users is array of objects, all objects have a User attribute)
So - why is this so hard - is it really necessary to have a whole Ember Data model defined with all the PITA associated with it to just âshow a nested objectâ?
jasonmit - that is what I thought would work too. After being puzzled I modified the provided Fiddle (see Ember Data Canary - JSFiddle - Code Playground) with the data structures that are passed. Turns out that the case-sensitivity of Ember blows things up.
Nasty. Might need to inject a âlower caseâ filter or something.
In your case, you want to return a header and an array of users from your API, but Ember expects your model to be your array of users, not the whole response (header and all), so thatâs why its getting confused. Easiest way to get it working like that is to call model.Users, like this.
Better yet is to stick a .then on the response and return the user array from there. Or you could manage it all in the setupController hook, or format the response like @jasonmit showed.
ulisesrmzroche, jasonmit Thanks for your replies. However - the part that started the post and that is puzzling to me is the fact that I cannot take some JSON object (whether the properties are uppercase or lower case) and use a Handlebar template to display it.
Note the strucuture I have is { item1: âsome textâ, Users: [ { User: âname1â }, { User: âname2â } }
Why do I have to do something complicated (in a non typed language) to show some (untyped) data? Isnât that the appeal of JS that I can âjust do thingsâ and NOT have to defined and declare different âtypes/structuresâ ??
Still puzzled? I must be missing something about Ember? Please enlighten me.
Because your payload is a little more complicated than Ember expects, youâll have to specify the details. Ember is expecting your model to be an array of users, but doesnât know what to do with the extra property. I handled it straight on the model route, but if you use Ember Data, you can use its Adapters to make it much cleaner and customizable.
I got it to work by changing Users to users (downcasing) in both the xhr response and the template. Maybe this is a bug in canary. I think that ember is looking for Users in the global namespace because it starts with an uppercase letter.
This is indeed some quirkiness due to Ember wanting to treat Caps as a global. @oss it is indeed a bug, and the best work-around for now is to lowercase properties in your JSON response before passing them to part of Ember.
Thanks for the explanation - that makes a lot of sense. The workaround provided by âulisesrmzrocheâ with using model.Users as a property reference for the {{#each}} loop helped me to get it moving. But it sure is counter intuitive and looks like a bug, but then I am using Ember the first time for a quick and dirty project where I figured it be worth exploring the capabilities.
Is there a release data/version for the fix?
BTW. Changing the model is not an option, the entire point is to use an existing API to provide a simple display of the nested data that appeals and provides navigation and the ability to link to other APIs. If I had to change the API (e.g. JSON response) it would undermine the purpose of quick and clean.
The uppercase âUsersâ is a red herring. See this JSBin, Ember Data Canary - JSFiddle - Code Playground, itâs the exact same result. Also, a lot of the time you may not have control over the API, whether for legacy reasons or because you donât own it, so itâs not a repeatable practice. It shouldnât matter what your API payload looks like though, itâs Emberâs job to adapt to it.
The real issue is that ember doesnât know what to do with that extra header property unless you tell it what to do with it. Right now, itâs just iterating through the whole response instead of just the array of users. you can do this either via an adapter, manipulating the response inside the subsequent promise, etc.You just have to make sure that your model (not necessarily your whole payload) returns an array of users.
In practice, your template should just look like this though.
@oss, As I think @ulisesrmzroche is suggesting, using a custom Ember Data adapter/serializer to normalize the values from your API will be the best in the long term. If you want to just get something simple working, itâs pretty trivial to do something like this:
You are totally right in the case of ember-data, but I think @oss is looking for a simpler case. I was thinking the same thing when I first read the original question. Having spent a lot of time with custom adapters and serializers, itâs easy to forget that it is perfectly valid to just pass simple json objects directly from your api to your view (although this has the problem of being less maintainable).
Yeah, pretty much the first one, except for that he also wants to display the Header in the template, so you have to return that too. The .then() doesnât exist because heâs using httpRespond to seed it. Thatâs why itâs being backed by ObjectController in the jsbin and not ArrayController.