Why isn't toggleTodo function a part of todoModel class? I know you created it as a model, but from an OOP perspective, methods and properties of an object would be housed in its own class. I understand that if we did that it wouldn't be possible to create a new object to prevent mutation when we toggle. Is it because of this?
The immutability reminds me of the Redux course. Redux also separates the view rendering logic with the logic that changes the application state. Here, it's all abstracted into separate components, which requires a trickling of events down to each individual components in a hierarchy. It's a bit hard to follow the event to its final recipient and may make maintenance require touching all components. With Redux, that trickling is still done, but can be bundled together as to make more readable code, leaving the view rendering untouched. One is a functional approach and the other is an object oriented approach.
What I found most helpful is how Angular 2 didn't change how it does inter component communication. You still broadcast events in order to communicate state change. That should soften the learning curve for me, but I'm constantly thinking of different scenarios that have previously gotten me stuck with Angular 1 such as including third party libraries. It's exciting that we have these options.
Technically, you could have TodoModel.toggleTodo() return a new copy of the Todo... but moving away from OOP thinking, you can think of Object.assign like it's applying a "diff". You take what's changed, mix it with the old object, and get a new object out (without ever changing the original object). So model become a simple representation of data. In fact, if you have a method that returns "void", you're most likely going against immutable conventions. I recommend going through the other Immutable lesson here on egghead (and the course on redux) if this is unfamiliar territory.
Redux can actually work really well with Angular 2! Taken one step further, the RxJS features allow for a fully reactive app. Unfortunately, these topics are out of scope of a "fundamentals" series and many best practices are still emerging from Angular 2.
Angular 2's interoperability story is really great. I hope it's not abused too much though ;)
There's a concept of "smart" and "dumb" components.
Smart = Components that handle services, state, routes, etc which are specific to your application and push that state into your dumb components
Dumb = Components that are reusable across applications and you could share them with the world. (Many frameworks like Bootstrap, Material, etc all have "dumb" components)
Everything is pretty new to me, and I keep giving up and coming back to Angular2. To me Angular1 is much more intuitive and if I use the controllerAs syntax I can sort of componentize pieces that way. This course was simple but it did get me excited about Angular2 again.
The only negative I see is there are now a few different files I believe where you are doing a ternary and hardcoding the string status in? Is there a better way of declaring that only in one file?