Ember 2.x Ember 2.x

Exercise 10 Solution, Part 3

Check out a free preview of the full Ember 2.x course:
The "Exercise 10 Solution, Part 3" 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 wraps up his walk through the Exercise 10 solution by fielding some audience questions.

Get Unlimited Access Now

Transcript from the "Exercise 10 Solution, Part 3" Lesson

>> [MUSIC]

>> Mike North: Before I post this. So I'll post this then I'll do another commit converting the whole thing through. So that you can see the finished picture here. But it's really more of the same, it's really more of the same stuff. So does anyone have questions about where I'm at and how this works.

[00:00:27] Where to do what.
>> Speaker 2: I have one question for you. So if you get a model in from an API or you get a record from your API. And then in business somewhere you add a property onto that record.
>> Mike North: Yeah, business logic in your UI.
>> Speaker 2: Yeah not in the model but you just tack it on there like this like this kind of thing as you're going through the UI.

[00:00:49] And when you refresh that model or get it updated does it wipe out any of the properties that you set?
>> Mike North: So you're saying beyond what is defined in model?
>> Speaker 2: Yep.
>> Mike North: You add a property to a record.
>> Speaker 2: Yep.
>> Mike North: It will not be de-serialized. When you persisted.

[00:01:07] And the reason-
>> Speaker 2: That's what I'm asking. I'm asking if I refreshed that model from the server, like say, refreshed my model and, nothing's changed, will it wipe off the things I've set on things that haven't changed? I've selected a bunch and then sent in a selected flag.

>> Mike North: I see what you're saying. So, that's hard to reconcile, right? Because essentially you have two changes and there's not an easy way to determine what should override what in the case of a conflict. So one person might say, all right I made my client site changes an hour ago.

[00:01:44] And my, I'm using web sockets and I'd finally reconnected to my server and that's the up to date data. I want the API to supersede. And someone else might say, this data's not changing in my API. I changed it and so you have to manage that yourself.
>> Speaker 2: The data doesn't exist immediately.

[00:02:02] So I got records coming in I clicked on them and instead of just used for display.
>> Mike North: Frankly that sounds a little bit of a fishy use case. The model should define the structure of your records and there is not a really great. Unless you have a specific thing you're trying to do, I would avoid trying to tack things on.

[00:02:25] That would go beyond how the model has defined it. I will tell you that in terms of serialization and deserialization, you're really looking at the model object, the factory, in terms of turning records into JSON. And so anything you do to the records themselves will not have probably the effects you are thinking of on how things are updated.

[00:02:51] Its tough to answer that question cause it's sought of hypothetical edgy edgy cornery edge case Any other questions? Adapters? Serializers? Types of APIs Ember works with? The answer is pretty much anything restful.
>> Speaker 3: So this question it sounds to me like, not that uncommon of a scenario where you have a list of something and you track what's selected.

[00:03:26] Is that something that would be better put in a component, and that component would store the state of what is currently selected?
>> Mike North: Yes.
>> Speaker 3: Dependent of the model stuff?
>> Mike North: It kind of depends on whether you intend versus this data so if you just like get on some online food or [INAUDIBLE] investing, you wanna select a couple things in that state you know really exist on the client until you place an order.

[00:03:55] You could probably create an order object and then whatever is said and done, persisted that as a whole. Selection is difficult to wrap my head around in terms of what you guys are thinking because that could mean UI selection state or I am doing course registration and I'm persisting that I've registered for these courses, I'm not sure what you mean.

>> Speaker 3: Thank you, I can go into more detail.
>> Mike North: Yeah.
>> Speaker 3: So I've got a list of items, and I am explain the inside of a component that has a check box in it. Outside of that component I got siblings to the list of items. I've got a count and some actions and some buttons that say leave all those things I've selected, copy all those things I've selected, do something with those things.

[00:04:38] So I go to check them, I tack on an inselected property to the record. Not being persistent, only use when I use the UI and only use when I click right into the buttons to say anything I selected, act upon.
>> Mike North: Totally get what you're saying.
>> Speaker 3: And every once in a while I want to reach into the API and say are there any new records.

[00:04:56] I got three new records pop them into the list but don't deselect my stuff.
>> Mike North: What I would advise there is you take a different approach to holding selection state. And that you potentially have a separate object that represents [CROSSTALK] instead of having the objects know about being selected [CROSSTALK] and not.

[00:05:16] Because remember the purpose of the model is to represent, usually, a persistent data structure. And to tack things on it that are a UI only concern may have some unexpected side effects.
>> Speaker 3: Maybe a service is a good spot for that.
>> Mike North: Yeah I would say totally an array on a service.

[00:05:36] Or an array on something like that. A service of course is global in a. So if that fits it's probably a good option. Question from the web.
>> Speaker 4: Yeah, we had a couple. There is wondering Windows that data get refreshed like if new repo is added would nullit show up.

>> Mike North: So good question. So I assume that means if someone, some other user through gethub, you know while we are looking at this page Creates a new repo. Out of the box nothing, no effort is made to try to keep that in sync. We don't, by default we don't poll for changes to data.

[00:06:19] What you can do is you can unload all records of a type. So the way the caching works, there's a separate bucket of the cash on a per model basis. And you can say you know every ten minutes, unload all of the repos you just have some you know, ember run later that will take care of that.

[00:06:43] And then you know the next time you come back to that page and you need data. There's nothing in the cache anymore and if you've used this logic we talked about or you checked to see is there anything in there, if not, go and request it from the API.

[00:06:58] That's where that can happen. So you really have to manage that yourself and the reason is that's more about your particular application than anything else. If you're building a real time trading platform, you probably don't want to cache anything at all. You want the latest data no matter what except for maybe like ticker symbols and you can say, all right, Coke's ticker symbol is not changing.

[00:07:26] You know Yahoo is gonna be Y-H-O-O even an hour from now. But the price, I don't want that to be cache at all. So there is some hooks where you can disable cash in other pro-model basis if you need to. But that is so specific to a particular app that Ember data does not aim to try to lean one way or the other.

>> Speaker 5: [INAUDIBLE]
>> Mike North: And many things.
>> Speaker 5: Many things.
>> Mike North: [LAUGH] All right any questions? Okay.
>> Speaker 4: The second one was, when talking of components. Is it okay in some cases to do an Ajax, somebody had a code to populate it, like a graphic component?
>> Mike North: So, I, that's an easy question to answer today.

[00:08:14] Because you should probably be doing your Ajax in a route. And we have these things called controllers for now. That are sort of the default context for things. And controllers currently have access to the store. And, although it's not advised, it's sort of set up so that you could request data via the controller.

[00:08:39] I would say, really what you want to do is do it in a route, pass it to the component. And the reason is, you know, components should really be more about visualizing and permitting the manipulation of application state. But the state should be owned elsewhere and that's cuz they get destroyed and created every time you transition to and from page and you want state to live on something that lives a little longer.

>> Speaker 4: And then another one just came in. Will we be showing any examples of saving data? Is there a way to do mass saves in one post, or are they all separate calls?
>> Mike North: There is a way to save data, and you're gonna have to look at the documentation for that cuz I could spend five or six hours going through all the edges and corners of this.

[00:09:35] It's pretty self explanatory. So, you change properties and measure width that it is 30. You can check to see if it's 30 or not and then save it. And that's useful so that as you turn to navigate away from your page. You can say, like, are you sure you want to discard your changes, and then roll it back to its previously, known clean state.

[00:10:00] So that all exists there. The idea of bulk operations, bulk saving, bulk editing, is a really, really hard problem to solve. There is no solution for it in Ember data. That is to say there is no like adopted pattern for doing it. But yeah we absolutely did do that.

[00:10:23] And it was An approach that I really wanna describe because I don't want people to follow it and say Mike told you cuz to do this. [LAUGH] So but one good sign here if you look at Jasonapi.org one of these sort of extensions to the course back is you know a good standard URL and JSON contract for bulk operations of various kinds.

[00:10:55] And so the fact that the standard exists means that ember data as one of the first class implementors of JSON API, it will hopefully come eventually I'm not aware of any specific developments in that area, but at least it's in the spec. And so I think that it would be good to see.

>> Speaker 5: Could you just in JSON p which is the old one which is the new [INAUDIBLE].
>> Mike North: JSON p, JSON API is a schema URL and a JSON schema and JSONP is a means of having AJAX without AJAX by way of loading JSON as if it's JavaScript in a script tag.

[00:11:47] but Json API is definitely newer. And the thing I would compare it to is hal, which is like this hyper media standard json in URL format. It's an attempt to avoid bike shutting. Which is this effect of like people making little trivial decisions that sort of cause a lot of noise and variance between different APIs and even different endpoints within the same API.

[00:12:14] And to agree on like this is the way we do relationships, this is the way we represent attributes, this is how we tell you that you've asked for a list of objects and you're on page 6 of 15, here's how we're passing that information back to you. Because once you have a standard, once you have a convention, you can save people a lot of time by the pile of work that can be considered boilerplate that just works, becomes much larger.

[00:12:47] Compared to having to do everything from scratch.
>> Speaker 5: So does it cover up on the equipment of the SQL query when it's ordered by this?
>> Mike North: Yeah, it covers ordering.
>> Speaker 5: Right.
>> Mike North: Like sorting. It covers pagination. It covers even the ability to include related records with a response.

[00:13:07] So if I was asking for the org and please include the complete list of repos fully fleshed out in your response. You know the spec includes that. So there's a lot there. And various implementations of JSON API I'm not sure if there's anything that completely implements the spec.

[00:13:29] But the idea is if we are going to move forward and implement a feature, this is the spec that things will try to align with.