Why Angular 2 Is So Awesome – Jacob Gardner – Medium

Why Angular 2 Is So Awesome  #react #angular2 #angular #javascript #reactjs

  • First you start with a simple route that looks something like this:{ component: SweetComponent, path: ‘fabulousness/:someId’}Pretty straightforward, yeah?
  • Okay, time to dig down into that SweetComponent from earlier and see how it accesses those fields.Your route is polite enough to provide Observables so that the component can make any necessary updates when the route changes, like this:route.params.subscribe(({ someId }) = otherStuff }) = …Convenient, huh?
  • Simply put, it’s a hash of the names for component properties that have changed to corresponding SimpleChange objects.
  • On that note, I’ll just defer to a passage from my entirely hypothetical and nonexistent previous article, Why TypeScript Is So Awesome:Unfortunately, TypeScript’s philosophy tends to encourage a developer to encapsulate values in ES6 classes, much as one would use structs in other languages.
  • When we obfuscate the true nature of JavaScript’s dynamic typing and prototypal inheritance behind a facade of static types and classes, we directly harm inexperienced developers by giving them a false impression of how JavaScript actually works.

Did you want to know what’s so great about Angular 2? Man, that sure was rhetorical. I’m definitely going to tell you regardless. Let’s talk routing; every app worth its salt needs routing. First you…

@ReactDOM: Why Angular 2 Is So Awesome #react #angular2 #angular #javascript #reactjs

Did you want to know what’s so great about Angular 2? Man, that sure was rhetorical. I’m definitely going to tell you regardless.

Let’s talk routing; every app worth its salt needs routing. First you start with a simple route that looks something like this:

component: SweetComponent,

path: ‘fabulousness/:someId’

Pretty straightforward, yeah? You’ve got a route, it takes an id, renders that component and the component gets to do something with the id if it wants. There are a few ways that you can get to it. One would be to render a link pointing to it:

This will happily append whatever that thing’s id is to “/fabulousness/” and work just as you’d expect. “But what if you want to add query parameters?” you ask me with an exasperated look on your face. Well don’t you worry your pretty little head; that’s only slightly more complicated:

Alright, that’s pretty swank. How about we look at making that same navigation from in a component?

from earlier and see how it accesses those fields.

Your route is polite enough to provide Observables so that the component can make any necessary updates when the route changes, like this:

will be an empty object. What, did you want your framework to be intuitive and consistent? This is the future!

interface, and add a method that looks something like this:

instance could be left out entirely?” Why yes, silly goose, that would work just fine. But over-engineering things is how we prove how smart and educated we are. Why pass around simple values when you could encapsulate them in completely redundant classes? Perhaps this is to make things more TypeScript-y. On that note, I’ll just defer to a passage from my entirely hypothetical and nonexistent previous article, Why TypeScript Is So Awesome:

Angular’s approach to front-end web development is, to quote Dr. René Belloq, to “use a bulldozer to find a china cup.” Speaking of the aforementioned change detection, let’s dive into how that works for a bit. All you need to do is update a property on an Angular component, like so:

and the changes will be reflected in that component’s template. I have to be honest, the first time I encountered this type of syntax in Angular 1, I was blown away. “All I need to do is update this property, and it’ll be automatically updated in the DOM?! It’s like magic!” Which leads me to this relevant point:

“Magic” in software is bad. “Magic” implies a fundamental lack of understanding for how something works.

When something appears to be magic, it is typically because the interface it presents to a developer is so alien compared to what they’re used to that they can only conclude that its implementation is beyond their understanding or comprehension. This is harmful to any developer’s learning experience.

), and XMLHttpRequests. Now, glossing over the fact that monkey-patching Web APIs gives me a sensation similar to what I imagine removing bubonic plague sores with a metal file must feel like, there are some other things that I think must be considered here.

in cases where the change cycle doesn’t seem to be occurring on its own. This can be especially prevalent while using certain third party libraries that could potentially run code outside of the Angular Zone. By introducing an unnecessarily complex layer of abstraction around change detection, Angular creates the possibility for numerous frustrating bugs, and forces the subsequently frustrated developers to fall back on manually forcing a process that should be automatic.

Angular’s method is to allow you to merely update some property on your component, and then by a complicated system of branching execution contexts, determine when that component should be checked for changes, subsequently detect that you updated a property, and reconcile that change with the DOM. Now, I’m sure if I presented the challenge of coming up with a simpler method of notifying the component when to perform a change detection cycle, it wouldn’t take much time for you to give me an answer. How about we just call a function when we want to update something in the component’s state? Something like, I don’t know, this?

is a function call whose return value is not used, implying that this expression will have side effects. There is no mysterious behind-the-scenes detection going on here; it is quite clear that such a function will produce side effects in the form of template reconciliation. React eschews magic for simplicity and clarity.

Just for the sake of another comparison, let’s reexamine that previous example of updating a component whenever its inputs are changed. In React, a component need only implement this method:

. No need for excess abstraction. It’s minimalist and intuitive.

Why Angular 2 Is So Awesome – Jacob Gardner – Medium