Understanding Angular modules (NgModule) and their scopes

Feature modules are NgModules for the purpose of organizing code.

As your app grows, you can organize code relevant for a specific feature. This helps apply clear boundaries for features. With feature modules, you can keep code related to a specific functionality or feature separate from other code. Delineating areas of your app helps with collaboration between developers and teams, separating directives, and managing the size of the root module.

https://angular.io/guide/feature-modules

 

The purpose of a NgModule is to declare each thing you create in Angular,

and group them together (like Java packages or PHP / C# namespaces).

There is two kind of main structures:

  • “declarations” is for things you’ll use in your templates: mainly components (~ views: the classes displaying data), but also directives and pipes,
  • “providers” is for services (~ models: the classes getting and handling data).

Source: Understanding Angular modules (NgModule) and their scopes

 

From angular official docs:

Modules are a great way to organize an application and extend it with capabilities from external libraries.

Angular libraries are NgModules, such as FormsModuleHttpClientModule, and RouterModule. Many third-party libraries are available as NgModules such as Material DesignIonic, and AngularFire2.

NgModules consolidate components, directives, and pipes into cohesive blocks of functionality, each focused on a feature area, application business domain, workflow, or common collection of utilities.

Modules can also add services to the application. Such services might be internally developed, like something you’d develop yourself or come from outside sources, such as the Angular router and HTTP client.

Modules can be loaded eagerly when the application starts or lazy loaded asynchronously by the router.

NgModule metadata does the following:

  • Declares which components, directives, and pipes belong to the module.
  • Makes some of those components, directives, and pipes public so that other module’s component templates can use them.
  • Imports other modules with the components, directives, and pipes that components in the current module need.
  • Provides services that the other application components can use.

Every Angular app has at least one module, the root module. You bootstrap that module to launch the application.

The root module is all you need in a simple application with a few components. As the app grows, you refactor the root module into feature modules that represent collections of related functionality. You then import these modules into the root module.

Read more here: https://angular.io/guide/ngmodules

Angular 5+ not working in Internet Explorer – solution

You installed the Angular CLI and used it to generate your new application. But, when you try to view it in Internet Explorer (IE), you see nothing. Now what?

The bad news:
Angular CLI applications require a few more steps in order to support Internet Explorer.

The good news:
It’s really simple: un-comment a few imports and install a couple of npm packages.

Read more: Angular and Internet Explorer – Angular In Depth

How to include and use jQuery in Angular CLI project

Tested in angular version 7:

  1. install jquery:
    npm install jquery
    install jquery typescript intellisense:
    npm install @types/jquery
  2. edit the angular.json file in root folder:
    in the architect / build / scripts location, add this:

    "scripts": [ "./node_modules/jquery/dist/jquery.min.js" ]
  3. To use jquery inside a component.ts add this import at the top:
    import $ from ‘jquery’;

    Example code to check for functionality:
    component html:

    <button (click)="testJQuery()">Test jquery</button>
    component.ts:
    testJQuery() {
    $('html').fadeOut();
    $('html').fadeIn();
    }
    Click on the button should fade out and fade in the entire page.

Source: How to include and use jQuery in Angular CLI project

json2typescript – npm

NPM Package for converting from JSON to TypeScript object.

json2typescript In Angular 2 applications, everyone consumes JSON API’s from an external source. Type checking and object mapping is only possible in TypeScript, but not in the JavaScript runtime. As the API may change at any point, it is important for larger projects to verify the consumed data. json2typescript is a small package containing a helper class that maps JSON objects to an instance of a TypeScript class. After compiling to JavaScript, the result will still be an instance of this class. One big advantage of this approach is, that you can also use methods of this class.

Source: json2typescript – npm

Angular – Template Binding Syntax

Binding syntax: An overview

Data binding is a mechanism for coordinating what users see, with application data values. While you could push values to and pull values from HTML, the application is easier to write, read, and maintain if you turn these chores over to a binding framework. You simply declare bindings between binding sources and target HTML elements and let the framework do the work.

Angular provides many kinds of data binding. This guide covers most of them, after a high-level view of Angular data binding and its syntax.

Binding types can be grouped into three categories distinguished by the direction of data flow: from the source-to-view, from view-to-source, and in the two-way sequence: view-to-source-to-view:

Source: Angular – Template Syntax

Real world example code for popular front-end and back-end frameworks

This is taken from Jon Hilton, Quick Tip Friday newsletter.
You can subscribe to the newsletter here: https://jonhilton.net/

Its a great tip regarding example code for popular web frameworks (also mobile in the works), for example ASP.NET Core on the backend side and Angular or Vuejs on the frontend side etc. See list of backends and frontends here: (scroll down there are many options…)
https://github.com/gothinkster/realworld 

Building software applications is hard, but doing it in isolation is even harder.

And, unless you’re one of the fortunate few who work in a perfectly balanced team with just the right amount of experienced developers to lean on, you’re often left figuring all this stuff out for yourself.

· Architectural best practices

· How to organise your code

· How to separate your concerns

· Which ORM to use

· How to KISS (keep it simple stupid) and avoid incurring loads of technical debt

But, just because you haven’t got a supportive, experienced and wise team physically on your doorstep doesn’t mean you have to re-invent all the wheels yourself!

Specifically I really want to recommend you check out the “real world” examples over at https://github.com/gothinkster/realworld.

There, they take the exact same application (a Medium clone) and show examples built in all manner of front-end and back-end frameworks.

So if you’re looking to see what a good ASP.NET Core API application looks like (or React, Angular, Vue.js or anything else you can think of)