Geriausios kampinės ir kampinės JS mokymo programos

„AngularJS“ (1.x versijos) yra „JavaScript“ pagrindu sukurta atvirojo kodo sistema. Tai yra daugialypė platforma ir naudojama kuriant vieno puslapio žiniatinklio programas (SPWA). „AngularJS“ įgyvendina MVC modelį, kad atskirtų logikos, pateikimo ir duomenų komponentus. Jis taip pat naudoja priklausomybės įpurškimą naudodamasis serverio paslaugomis kliento programose.

„Angular“ (2.x ir naujesnės versijos) yra „Typescript“ pagrindu sukurta atvirojo kodo sistema, skirta kurti priekines žiniatinklio programas. „Angular“ turi tokių funkcijų kaip bendrosios rūšys, statinis spausdinimas ir kai kurias ES6 funkcijas.

Mes rekomenduojame išmokti „Angular“ ir naudoti jį naujiems projektams. „AngularJS“ dažniausiai naudojamas seniems projektams.

Geriausias būdas išmokti kampinį yra „freeCodeCamp“ 6 valandų kampinio mokymo programa „YouTube“.

Kitos „Angular“ pamokos

Kampinis 1.x

Bendrieji puslapiai

  • Kampinis JS - kampinis JS tinklapis
  • „AngularJS“ stiliaus vadovas - išsami geriausia kampinio vystymosi patirtis

Vaizdo įrašai

  • Maršruto nukreipimas kampiniu JS - kliento maršrutas per 15 minučių
  • „Angular ToDo“ programa - „Angular ToDo“ programa per 12 minučių

Kursai

  • „Egghead.io AngularJS“ kursai ($)

Kampinis 2.x +

Bendrieji puslapiai

  • Kampinis - kampinis pagrindinis puslapis
  • Kampinio stiliaus vadovas - išsami kampinio vystymo geriausia praktika

Konkrečios temos puslapiai

  • Direktyvos - puikus vadovas išsamiai aprašant kampines direktyvas (1 dalis)

Kursai

  • „Egghead.io“ kampiniai kursai ($)
  • „FrontendMasters“ - „Awesomer“ programų kūrimas kampu
  • Galutinis kampinis - Toddo šūkis
  • „Angular 6“ (anksčiau „Angular 2“) - pilnas vadovas ($) Maximilianas Schwarzmülleris

Tinklaraščiai

  • Alligator.io
  • Kampinis gylis

Versijų istorija

„Google“ išleido pradinę „AngularJS“ versiją 2010 m. Spalio 20 d. Pirmasis stabilus „AngularJS“ leidimas buvo 2017 m. Gruodžio 18 d., 1.6.8 versijos. „Angular 2.0“ leidimas įvyko 2014 m. Rugsėjo 22 d. Konferencijoje „ng-Europe“. Viena iš „Angular 2.0“ savybių yra dinaminė apkrova.

Po kai kurių modifikacijų „Angular 4.0“ buvo išleistas 2016 m. Gruodžio mėn. „HttpClient“ biblioteka yra viena iš „Angular 4.0“ savybių. „Angular 5“ buvo išleistas 2017 m. Lapkričio 1 d. Pažangių žiniatinklio programų palaikymas buvo vienas iš „Angular 4.0“ patobulinimų. „Angular 6“ buvo išleistas 2018 m. Gegužės mėn. Naujausia stabili versija yra 6.1.9

Įdiekite :

„Angular“ galime pridėti nurodydami turimus šaltinius arba atsisiųsdami sistemą.

Nuoroda į šaltinį :

„AngularJS“: „AngularJS“ („Angular 1.x“ versijas) galime pridėti nurodydami „Google“ turinio pristatymo tinklą.

Atsisiųsti / įdiegti: Mes galime atsisiųsti sistemą naudodami „npm“, „Bower“ ar kompozitorių.

Kampinis 1.x :

npm

npm install angular

Tada pridėkite prie savo index.html:

lenkėjas

bower install angular

Tada pridėkite prie savo index.html:

Norėdami gauti daugiau informacijos apie dokumentus, apsilankykite oficialioje „AngularJS“ svetainėje.

Angular 2.x“ ir kitas versijas galite įdiegti atlikdami oficialios „Angular“ dokumentacijos veiksmus.

Komponentai

Motyvacija

„Angular“ yra daugybė pastatų taikymo schemų . Komponentai yra viena iš tokių schemų. Jie apima vieną logikos vienetą, susijusį su viena programos dalimi. Norėdami efektyviau veikti, komponentai dažnai bendradarbiauja su kitomis schemomis.

Tarp visų schemų komponentai paprastai sunaudoja daugiau, nei pateikia. Kitos schemos, tokios kaip direktyvos, vamzdžiai ir paslaugos, yra naudingos, komponentai naudojami. Jie yra atsakingi už programos sąsają, todėl yra prasminga, kodėl jie naudojasi naudingumu.

Komponentai supaprastina taikymą. Jų pagrindinis tikslas yra logikos nukreipimas į vieną matomos sąsajos skyrių. Norėdami nuosekliai kurti programas, turite kurti komponentus. Komponentai vis dėlto veikia kaip „Angular“ statybiniai elementai.

Komponentų įvadas

Kaip minėta, komponentai sunaudoja naudingumą (paslaugas / išteklius). Jie stovi tarp verslo logikos ir pateikimo, kad sukurtų darnų vienetą. Kampinis prie kiekvieno komponento pritvirtina įvairius mechanizmus. Šie priedai nurodo klasę kaip komponentą ir apibrėžia jos standartines galimybes.

Kampinis turi atpažinti komponentus, kai jie susiduria su jais. Norėdami tai padaryti, @Componentturite papuošti kiekvieną klasę, skirtą sudedamajai daliai. Dekoratoriai nurodo kampu, kokia yra klasė.

Komponento atveju jis turi žinoti, kaip bendrauti su jo purkštuvu, prisijungti prie šablono, ištraukti iš stilių sąrašo, apimti jo stilius ir pan. „Angular“ rūpinasi daugeliu žemo lygio reikalavimų. Kūrėjai vis tiek turi sukonfigūruoti komponento veikimą, importuoti jo priklausomybes ir išplėsti jo logiką.

Visiems tokiems dalykams turime komponento klasę. Klasė išlaiko viską palyginti vienodą. Tai apibendrina komponento verslo logiką.

Komponentų klasė ir metaduomenys

Go ahead and install the Angular command-line interface (CLI). You can learn more about it from this article. The CLI command ng generate component [name-of-component] yields the following.

import { Component, OnInit } from '@angular/core'; @Component({ selector: 'app-example', templateUrl: './example.component.html', styleUrls: ['./example.component.css'] }) export class ExampleComponent implements OnInit { constructor() { } ngOnInit() { } }

This is the basic skeleton from which all great components originate. The @Component decorator is the most important part. Without it, the above example becomes a generic class. Angular relies on decorators to discern a class’s schematic type.

@Component receives metadata as a single object. Decorators are just JavaScript functions under the hood. They take in arguments as with the metadata object. The metadata object configures a component’s basic dependencies. Each fields plays a role.

  • selector: tells Angular to associate the component with a certain element in the application’s template HTML.
  • templateUrl: accepts the file location of the component’s template HTML (this is where data gets displayed to).
  • styleUrls: accepts an array of style-sheet file locations (strings). These style-sheets target the component’s assigned template.

Think of metadata as a big blob of configuration. The decorator takes it so that it can generate the data specific to the component. The decorator decorates the underlying class with data necessary for its class’s behavior. A component class that is.

The class’s signature exports by default so that the component can be imported. ngOnInit also gets implemented. implements tells the class to define certain methods per the interface’s definition. ngOnInit is a lifecycle hook.

Component Lifecycle and Change Detection

Components use all sorts of tools, services, and features. One key feature available to components is lifecycle hooks. An explanation for each hook exists in this article.

There are eight in total and they all serve as timing functions. They execute conditionally as the component transitions from state-to-state via change detection. This process happens constantly across the component tree. It searches for changes in data which merit a re-rendering of the template.

Time to move on. Please refer to the aforementioned articles for more information on the component lifecycle. It deserves much more explanation.

Component Data

Data drives everything. Components are no exception. Components encapsulate all their data. To receive data externally, a component must explicitly declare it. This form of privacy keeps information from clashing across the component tree.

Data determines what gets displayed from the component class to its template. Any updates to the class’s data will (or at least should) update the template display.

Components will often initialize a set of members (or variables) that store data. They are used throughout the component class logic for convenience. This information fuels the logic resulting in the template and its behavior. See the following example.

// ./components/example/example.component.ts import { Component, OnInit } from '@angular/core'; import { Post, DATA } from '../../data/posts.data'; @Component({ selector: 'app-example', templateUrl: './example.component.html' }) export class ExampleComponent implements OnInit { username: string; totalPosts: number; allPosts: Post[]; deletePost(index: number): void { this.allPosts.splice(index, 1); this.totalPosts = this.allPosts.length; } ngOnInit(): void { this.username = DATA.author; this.totalPosts = DATA.thePosts.length; this.allPosts = DATA.thePosts; } }

{{ username }}

Change Name:

Posts: {{ totalPosts }}


    DELETE
    {{ post.title }}

    {{ post.body }}


Note the ways the component interacts with its data. It first fetches it from ../../data/posts.data before it begins to forward it to the template for display.

The data shows up throughout the template. Inside the double curly braces, a variable’s value is mapped from the component class into the braces. The *ngFor loops across the allPosts class array. Clicking on the button removes a specific element from allPosts by its index. You can even change the topmost username by typing into the input box.

The above interactions alter the component class’s data which in turn updates the component’s template HTML. Components provide the backbone logic that facilitates the flow of data. The template HTML makes that data readable to the user.

Component Template

The previous example’s template HTML featured an interesting syntax. The syntax was not actual HTML. It was Angular’s template HTML. Some often refer to it as HTML Plus, recognizable only by Angular’s compiler. The compiler supports a syntax resulting in the dynamic manipulation of HTML. This article will often refer to it as ‘template HTML’ or ‘template’.

The syntax lets components inject data directly into the template HTML. The injection is dynamic. This means that data can iterate and display itself as HTML without needing external assistance. The Angular compiler compiles it into real HTML by the time it reaches the web browser.

To learn more about some of the ways data binds to the template, read about data binding in Angular. A few examples of data binding occurred in the previous example ({{ ... }}). For this article, it is enough to recognize data interactions were happening between the component class and its template.

Querying the Template

Data managing the state of the template imperatively works OK. Yet, pure data does not always fulfill an application’s intended design. Interacting more directly with the Document Object Model (DOM) may be required.

To do that, the component must have reference to the template elements. When the data changes, the component can manipulate the DOM explicitly. This is a more declarative approach.

Components can grab references using a web browser’s DOM application programming interface (API). Bad idea though. Angular prefers cross-platform compatibility. For a component to function outside of the web browser, it needs to use Angular’s API instead of the DOM’s.

Components can query their templates using the @ViewChild and ContentChild decorators. They grab references to template elements on behalf of the component class.

import { Component, ViewChild, ContentChild, ElementRef, Renderer2, AfterContentChecked, AfterViewChecked } from '@angular/core'; @Component({ selector: 'app-child', template: ` Toggle Enlarge  ` }) export class ChildComponent implements AfterContentChecked { @ContentChild("pReference", { read: ElementRef }) pElement: ElementRef; textEnlarge: boolean = false; constructor(private renderer: Renderer2) { } toggleEnlarge() { this.textEnlarge = !this.textEnlarge; } ngAfterContentChecked() { if (this.textEnlarge) this.renderer.setStyle(this.pElement.nativeElement, 'font-size', '25px'); else this.renderer.setStyle(this.pElement.nativeElement, 'font-size', 'initial'); } } @Component({ selector: 'app-parent', template: ` Toggle Highlight 

View Child

Content Child

` }) export class ParentComponent implements AfterViewChecked { @ViewChild("hOneRefereance", { read: ElementRef }) hOneElement: ElementRef; textHighlight: boolean = false; constructor(private renderer: Renderer2) { } toggleHighlight() { this.textHighlight = !this.textHighlight; } ngAfterViewChecked() { if (this.textHighlight) this.renderer.setStyle(this.hOneElement.nativeElement, 'background-color', 'yellow'); else this.renderer.setStyle(this.hOneElement.nativeElement, 'background-color', 'initial'); } }

The above example contains two buttons that toggle a certain style for each element. Clicking the buttons toggles the true/false values unique to each component. These booleans determine if the custom styles apply. Instead of these values causing changes imperatively, the lifecycle hooks (ngAfterViewChecked and ngAfterContentChecked) declaratively alter the DOM.

The declarative approach explicitly changes the style through the element’s reference. In imperative programming, changes to the DOM based off data are implicit. Check out this article on imperative and declarative programming to learn more.

The main thing to notice is how these references get pulled from the template. In the example, there are two sections of the template queried using two decorators: @ViewChild and @ContentChild.

They differ in where they look for an element’s reference whether it be in the content DOM or view DOM. These two DOMs exist in ParentComponent’s template. Differentiating between them is important because they finish rendering at separate times.

This is why @ViewChild and @ContentChild both exist. They work together with their companion lifecycle hooks ngAfterViewChecked and ngAfterContentChecked. These lifecycle hooks wait for their respective queries to resolve before executing.

Once resolved, @ViewChild and @ContentChild provide references to two elements. Both exist in separate parts of the DOM. The boolean data still determines the outcome. How that outcome translates to the DOM is the key difference from before. The DOM updates viaRenderer2’s direct manipulation of it.

Content Projection

The content DOM exists in the innerHTML of ChildComponent’s element. It is all positioned within ParentComponent’s template. The innerHTML of app-childprojects onto ChildComponent’s template through .

This exemplifies content projection. Displaying content from one component to another using the innerHTML of another’s tags in one’s template so that another component can pull that innerHTML into its own template via . Thank you for reading that sentence.

Hence why ChildComponent references its element using @ContentChild. Content contained within in ParentComponent’s template makes up the content DOM. ChildComponent references the element with an @ContentChild query.

ParentComponent’s view DOM consists of everything accessible from within the component’s view. This does not necessarily include the entire template given the innerHTML of . Again, this part of the DOM is queried from ChildComponent using @ContentChild. Everything else gets queried using @ViewChild from the ParentComponent class.

This is a great way for components to exchange content and query their own content regardless of their DOM type. Components can communicate with themselves and others using data binding as well. Read more about it from this article.

Component Styles

Styles are critical to a component’s readability and interactivity. Each component encapsulates its style-sheet dependencies. That way they only apply to the component’s template HTML. A special technique introduced by HTML’s shadow DOM makes this possible.

A shadow DOM branch may exist on any element. This part of the DOM cannot be seen from the HTML’s source code. Standard HTML elements leverage the shadow DOM to provide their trademark appearances. A shadow DOM branch must anchor itself to a visible component so that it can style and customize it.

The unique aspect about a shadow DOM branch is its encapsulation. Everything used to style a shadow DOM branch’s root element is private to it. No other element can access it.

Angular embraces this form of encapsulation with components. The style-sheet and template of a component encapsulate together. No other components have access to them. Style-sheet clashes cannot occur.

Angular does not use the shadow DOM by default. It uses an emulation system that mimics the behavior of the shadow DOM. This is a temporary measure since some web browsers do not yet support the shadow DOM API.

The @Component metadata contains the encapsulation field. This lets developers toggle in-between emulated shadow DOM, real shadow DOM, or neither. Here are the options in their respective order:

  • ViewEncapsulation.Emulated - fake shadow DOM (default)
  • ViewEncapsulation.Native - real shadow DOM (now deprecated since Angular 6.0.8)
  • ViewEncapsulation.None - neither

ViewEncapsulation.None means the component’s style-sheets elevate to the global scope. Not recommended considering components should form their own private unit (encapsulation). Angular still provides it as an escape hatch for extreme situations.

Conclusion

Komponentai kuria programas. Jie yra privataus masto ir atskirai vienas nuo kito, nebent sukonfigūruota kitaip. Programos paprastai prasideda nuo šakninio modulio. Po to komponentai sudaro pailgą medį, apibrėžiantį likusią programos dalį.

Komponentas apima nustatytą programos sąsajos vienetą. Tai apima jo stilius, logiką ir išdėstymą. Kitos schemos, tokios kaip vamzdžiai, paslaugos ir direktyvos, dažnai naudojamos komponentų kode. Daugiau apie šias sąveikas galite sužinoti kai kuriuose kituose „Angular Guide“ straipsniuose.

Nepamirškite, kad komponentai turi būti paleisti. Tai gali atsitikti šakniniame modulyje arba komponento metaduomenyse. Tai taip, kad kampinis atpažįsta komponentą visur, kur jis rodomas programoje.

Visada galite sužinoti daugiau, nes komponentai suteikia daug daugiau gylio nei tai, ką šis straipsnis galėtų pasakyti.