I recently had the chance to interview for a company called Flywheel.io, which is revolutionizing the way that medical technology is used to process medical images captured from things like CT scans. Along with development of machine learning data pipelines, the platform also includes different annotations you can apply to the medical scans, which would help researchers and medical experts to present findings in much clearer ways. As I started interviewing for the role, I realized that the stack that they were using to build all these features was actually Angular. As someone that has found a home in React, I've always heard of Angular, but I never found the need to learn about it, since I was already busy building things in React. There are definitely a lot of key differences, some of which I wanted to share here as major points to consider when determing what these frameworks offer.
Modular Programming
If you're someone that is familiar with React, you are familiar with the component. This component, which is a single Javascript file, with multiple portions, handles everything you need for configuring the HTML being displayed, getting the data for the component through fetch requests, setting up lifecycle methods with various functions for usage in the component, and importing other libraries for use. In Angular, all of these vital actions are performed by different files. This separation of concerns is called modular programming.
A good analogy for modular programming would be the way DSLR cameras are sold. The cameras are designed so that each part of the camera has it's own function, and is essentially many different parts, which can be put together. This is in contrast to something like a digital camera that comes as one unit. Just like with DSLR cameras, Angular has separated concerns for each part of an app's activities. Modules handle importing major libraries, services handle HTTP requests, templates handle HTML layout, and components (a separate file) hold component logic and functionality. Each of these parts that you have to build out in separate files in your Angular project.
There are some major advantages this separation of concerns can provide. The first is reusability. Since each functionality is divided into multiple components, you can easily swap out parts based on how you want to customize a particular component, and reuse files(f.e. a service that makes an API call) that can serve a similar purpose in other components. Second thing is the organization. Bugs are much easier to find when the problem you're looking for has categories and labels to indicate different concerns in your project. If you've got a problem making an API call, this would be a problem in your service file, and if you've got a display issue, the bug would probably exist in one of your template files.
Templates
Another major difference in Angular is in how your HTML is displayed. Like I just mentioned, this is handled your template files. This is actually a separate HTML file in each of your component folders, so you have on template for each component. This file is in contrast to what what the return call does for the React component. A major part of Angular is learning how this display file is communicating with the separate component logic file to configure the component's behavior.
Besides the file structure, what are the actual options for manipulating the DOM? In React's focus on component structure, you can give properties to components, which will then be passed down as props. In Angular, you get a deeper system of DOM manipulation, which allows you to assign custom Angular attributes and functions to anything on the DOM, including HTML elements themselves.
One major part of this is a system called directives. I've never heard this term before, but that's because it's something specific to Angular and a core part it works. Simply, a directive is a function that executes whenever the Angular compiler finds it in the DOM. It's not just a function that exists in relation to the DOM, but is on the DOM itself, which in this case is the template file. This configuration allows you to place these functions directly onto HTML elements themselves, and even receive attributes related to the HTML element itself. Angular comes with a whole box of different kinds of directives, which are Angular specific functions for manipulating the DOM.
Including directives, Angular has syntax you need to know for manipulating your template. Here's a list of some of the major tools:
-{{ }} for interpolation.
-[] for property binding.
-() for event binding.
-# for variable declaration.
-* for structural directives.
To understand template manipulation in Angular, here's an example of each tool we just listed.
Interpolation:
<img src="{{itemImageUrl}}">
Here's an example of an interpolation where now the variable itemImageUrl is now available in the component logic that you can manipulate with the functions available there.
Property binding:
<img [src]="itemImageUrl">
Here's property binding. Actually, this statement and the interpolation example do the exactly same thing. The only difference is that for property binding, you place the brackets on the property, and the string is then treated as a variable for the component. What this is actually doing behind the scenes, is the brackets are actually creating a directive, which is a function. In this case that directive is passed in the argument "itemImageUrl", which sets it as a variable.
Event binding
<button (click)="Delete()">Delete</button>
Here's a button with simple event binding. You'll notice that the first property click is descriptive of a type of event, which in this case is when this particular button is clicked. Then you have the event that is associated with the action, defined in the component logic. Standard event binding, with slightly different syntax and event names.
Variable declaration
<input type="text" #name>
{{name.type}}
This variable declaration which is written using #name points to the HTML input element properties themselves, and allows us to use those properties elsewhere in our template. This was just one example in reference to HTML elements, but per the documentation, you can actually declare variables on templates, components, and even directives.
Structural Directives
//ngIf
<div *ngIf="data.attributes.length > 0">
<h2>Display the data>
</div>
//ngFor
<div *ngFor="let item of list">
<p>{{item.name}}</p>
<p>{{item.count}}</p>
<p>{{item.price}}</p>
</div>
//ngSwitch
<div [ngSwitch]="itemCount">
<p *ngSwitchWhen="0">You have no items.</p>
<p *ngSwitchWhen="1">You have 1 item</p>
<p *ngSwitchWhen="2">You have 2 items</p>
</div>
What is a structural directive? As we mentioned before, a directive is simply a function that returns a value when it's found on the DOM. A structural directive then, is a function that provides a value that returns a 'structural' element or directly manipulates the DOM. This is in contrast to an attribute directive, which only returns values that concern data outside the DOM.
In the above example code, the ngSwitch statement does not have the same syntax as the ngFor statement. The reason for this is because, the are different kinds of directives. The '*' is only for ngFor, which is an example of a structural directive, while the ngSwitch, which is an attribute directive, is put into curly brackets. These two directives, with components themselves, are the 3 main kinds of directives in Angular. Given the definition of directive is simply a function which returns a value, you can actually create your own custom directives as well.
Decorators
This is actually a small difference, but is relevant in looking at the way modular programming style is configured in Angular. This is a basic decorator, which is a function that sits at the top of your component logic.
@Component({
selector: 'app-todos',
templateUrl: './todos.component.html',
styleUrls: ['./todos.component.css']
})
Like we mentioned before, components are directives, and @Component represents that directive. We imported this directive from Angular's library, and is taking multiple arguments from an object. Selector allows you to customize the name of your component, templateUrl allows you to pick your template file, and styleUrls allows you to select your stylesheet.
This is a good microcosm of what Angular does. This is merely on the level of the component, but in other Angular files like module folders, you'll notice this similar pattern. Since you are creating a bunch of interchangeable parts, you are selecting which parts you want to select at multiple levels to build the application. At the component level, you import an Angular component directive and you feed it custom options. The same pattern of assembling from multiple constructed/imported options is used for modules, services, and other Angular functions.
A note on comparison to React
The pros for this kind of modular programming seems to be that there is definitely much better design architecture and scalability, with the downsides that people usually mention being that Angular is difficult to grap, since you have to learn that architecture. Based on this typical analysis of Angular, it seems to me then that everyone should just invest time in learning it and gain the better architectural foundation that Angular would provide. But why does most of the industry then use React?
I think the thing that personally bothers me as a coder is that now I have to have so many more files open to just look at one component. In React, I would be able to open files for everything regarding multiple components to look at a larger scope of code, but now I need to have two files open just to look at the component logic and display.
On the same point, but in a more general sense, it seems that the reason for a preference for React might be that it's file structure is also emphasizing a different focus, which is the single component and its state. While Angular might be focusing on scalability, the way that React has a focus on the single components and their hierarchy, seems to be placing a greater emphasis at the component level and their display.
Top comments (0)