Ember 2.x Ember 2.x

Exercise 4 Solution, Part 2

Check out a free preview of the full Ember 2.x course:
The "Exercise 4 Solution, Part 2" Lesson is part of the full, Ember 2.x course featured in this preview video. Here's what you'd learn in this lesson:

Mike continues the solution to Exercise 4 by explaining the content-policy errors that are appearing in the console and adding dynamic data to the issues and contributors routes.

Get Unlimited Access Now

Transcript from the "Exercise 4 Solution, Part 2" Lesson

>> [MUSIC]

>> Mike North: Now we've got three errors here. Things are getting a little nutty in my console and they all have to do with content security policy. So this content security policy is a way of informing the browser what, given a resource that has been served up, what should the browser be able to connect to?

[00:00:25] And so we've just started talking to a new resource that by default we're not supposed to be talking to. So we just need to add Github's API as developing to talk to. The place where you set that up is in the config environment, and security policy.
>> Mike North: And then in this case we just need to connect source.

>> Mike North: And we should just be able to add this and then we're done.
>> Mike North: Additionally we have to stop and and start it again.
>> Mike North: Okay, so [NOISE]
>> Mike North: Looks like the avatars are still giving us trouble here. I will post a link how to customize this further, but the basic idea is for different types of communication, if you allow this, these domains and these resources for style and these four connecting to via ajax, these for images and so on.

[00:02:01] So I'm gonna keep going here and just apply very similar changes to the issues and contributors. So I'm gonna go to routes > repo >
>> Mike North: contributors. And basically want this same thing.
>> Mike North: Except we also have to get the repo itself. Same modelFor technique.
>> Mike North: And we'll set a debugger, make sure everything works.

>> Mike North: 'name' on undefined, my mistake.
>> Mike North: And I believe we'll need to go here as well. So I'm basically just filling in with the appropriate API request all the way down. What we're gonna end up doing here is asking for more data than we really need. And the reason is there's no understanding that we just came from the list of repos and therefore don't need to ask for this object that we already knew about.

[00:03:36] This is where Amber Data starts to become very valuable. All right, so repos > org > id.
>> Mike North: So let org = modelFor.
>> Mike North: Here we'll do
>> Mike North: org id and then,
>> Speaker 2: [INAUDIBLE]
>> Mike North: Thank you.
>> Mike North: And it is undefined. Because the dynamic segment is actually repo id.

[00:04:30] All right, there we go. And I can see that we've got the repo if I look at the network tab here, but I don't wanna take up more time than we have to.
>> Mike North: All right, so now I've got that, which means that the list of contributors should work now.

>> Mike North: Fantastic. Looking for that URL up here.
>> Mike North: And I'm just going to keep stepping through.
>> Mike North: Something is odd here.
>> Speaker 3: What did you use for the repo ID in the repo.js file?
>> Mike North: I'm just looking for the repo id and the repo.js.
>> Speaker 3: [INAUDIBLE] repo, correct?

>> Mike North: So the repo should already be resolved. So there's my org id, there's my repo id, that looks right to me. Maybe it's a.
>> Speaker 3: [LAUGH]
>> Mike North: [LAUGH] Trolled again.
>> Mike North: Awesome. And now raw contributors. Awesome. And we just need to do the same mapping here. I'm gonna just copy it.

[00:06:47] This would be a great thing to sort of externalize and make it a function that we could just massage everything the same way.
>> Mike North: And [NOISE] got rid of the debug, and rawContributor.
>> Speaker 4: No.
>> Speaker 5: It should be fine. And that there's various equal to one of the individuals.

>> Mike North: All right. Now, I'm pretty convinced it works.
>> Mike North: There we go. So now we have the list of contributors. We've gone really deep into this now. We've got a lot of data coming in at different levels and what's important to note is that you can drill in and drill in and drill in, and as you go through the routes deeper and deeper, you often need to refer to parent route models in order to do what you need to get done.

[00:08:28] In one case, in the case of the org, we had to actually make available, sorry, it was the repos list I think. We had to make something available in the template via setup controller. And so this is the kind of stuff that you have to do in order to resolve the differences in the hierarchies between the route structure you want, what you want to show up in your templates, and what data is necessary in order to fetch other data, if that makes sense.

[00:09:02] So, I think I should be able to just copy this and make it just work for issues and then we're all home free. I'll copy this one and replace with issues and
>> Mike North: <ul>. So just iterating over again </ul>
>> Mike North: And here we've got a couple issues. This is a smaller repository.

[00:09:57] We can go back to something little more interesting like Ember seal by itself many issues. Many people working on them and then here are the contributors. So now we've gotten rid of all the hard coding, hard coded data. We're getting repo information. The list of repos, the list of issues, the list of collaborators, all from the API.

[00:10:20] And when it comes down to it, it seems like a lot of work but it falls into three categories, using get $.get using jQuery to just return a promise, you don't need ember data, although it's quite useful. Using modelFor instead of controller to get the right data onto the right template.

[00:10:41] And then finally doing a little JSON massaging to get things into a state where link two is happy with them. Make sure you get that id matching what the URL thinks the id should be.