/angular-guide > _

კომპონენტის შექმნა და კონფიგურაცია

ფრეიმვორქის ერთ-ერთი უპირატესობა ის არის, რომ შეგვიძლია აპლიკაცია დავყოთ კომპონენტებად. ეს საშუალებას გვაძლევს, რომ აპლიკაციის განმეორებადი ელემენტები ერთ ადგილას განვსაზღვროთ და ბევრგან გამოვიყენოთ.

შენიშვნა: ამ თავში განვიხილავთ მე-17 ვერსიაში სტანდარტიზირებულ standalone კომპონენტებს. ანგულარის ძველ ვერსიებში გამოიყენებოდა მოდულებზე დაფუძნებული მიდგომა.

ანგულარის კომპონენტი ჩვეულებრივ სამ ფაილად დაყოფილი ფოლდერია. გვაქვს ts ფაილი, სადაც კომპონენტის კონფიგურაცია და ჯავასკრიპტის ლოგიკა ერთიანდება, html თემფლეითი, სადაც კომპონენტის მარკაპია და scss/css ფაილი, სადაც კომპონენტის სტილებია.

# example კომპონენტი

example.component.ts
example.component.html
example.component.css

ახალი კომპონენტის შემოტანა ასეთი ფაილების ხელით შექმნით შეიძლება, ან უბრალოდ CLI-ში ბრძანების გაშვებით:

ng generate component child

child იქნება ის სახელი, რომელსაც კომპონენტს დავარქმევთ. ანგულარი შექმნის კომპონენტს, რომელიც განთავსდება child სახელის მქონე ფოლდერში. ფაილების დასახელება მათი დანიშნულების მიხედვით ხდება. კონვენციურად წერტილებით გამოიყოფა component ფაილების დასახელებაში. html ფაილში ჩვენ ვწერთ მარკაპს. ანგულარის CLI-იმ წინასწარ თემფლეითში ჩაგვისვა ტექსტი, რომელიც კომპონენტის სადმე განთავსების შემთხვევაში უნდა გამოჩნდეს. .css ფაილში ვწერთ ამ კომპონენტის სტილებს, ხოლო .ts ფაილში კომპონენტის ლოგიკას. როგორ არის ეს ყველაფერი ერთმანეთთან დაკავშირებული?

ტაიპსკრიპტის ფაილში ვხედავთ, რომ დაესქპორტებულია კომპონენტის კლასი, რომელსაც კონვენციურად სახელთან ერთად ეწერება სიტყვა ‘Component’, მაგრამ კლასის დაექსპორტებამდე მას თან ახლავს @angular/core-დან დაიმპორტებული @Component დეკორატორი. დეკორატორი ტაიპსკრიპტის ხელსაწყოა, რომელიც მეტაპროგრამირებაში გამოიყენება. იგი ერთგვარი ფუნქციაა, რომელიც მოდიფიკაციას უკეთებს მონაცემის სტრუქტურას - ამ შემთხვევაში კომპონენტის კლასს. ამ დეკორატორში კონფიგურაციის ობიექტის მიწოდებით ანგულარი მუშა კომპონენტის ინსტანციას ქმნის.

import { Component } from "@angular/core";
import { CommonModule } from "@angular/common";

@Component({
  selector: "app-child",
  standalone: true,
  imports: [CommonModule],
  templateUrl: "./child.component.html",
  styleUrl: "./child.component.css",
})
export class ChildComponent {}

selector არის ის თეგი, რომლითაც ამ კომპონენტს თემფლეითში განვათავსებთ. კონვენციურად კომპონენტის თეგებს აქვთ app პრეფიქსი, მაგრამ ეს შეიძლება იყოს პროექტის დასახელება, კომპანიის სახელი, რომელიმე მათგანის აბრივიაცია და ა.შ. სცადეთ app.component.html-ში ამ თეგის განთავსება:

<!-- დამხურველი თეგით -->
<app-child></app-child>
<!-- შესაძლებელია void ტიპის თეგიც -->
<app-child />

თუ სადეველოპმენტო სერვერი გაშვებული გაქვთ, მაშინ ის მარკაპი უნდა დავინახოთ, რომელიც child.component.html-ში დავწერეთ.

კონფიგურაციაში standalone თვისება მიუთითებს იმაზე, დამოუკიდებელია თუ არა კომპონენტი. standalone კომპონენტი დამოუკიდებლად ფუნქციონირებს იმ თვალსაზრისით, რომ ყველა dependency (ანუ საჭირო კლასები) არის უშუალოდ ამ კომპონენტში დასაიმპორტებელი, თუკი მათი გამოყენება გვსურს. ეს განსხვავდება მოდულზე დამოკიდებული კომპონენტებისგან, სადაც ცალკეულ ფაილში მოდულის კლასის დეკლარაცია შეგვიძლია და იქ არსებული კომპონენტების გამოცხადება, ისევე როგორც მათთვის dependency-ების მიწოდება. თუ ეს ყველაფერი ბუნდოვნად ჟღერს, არ ინერვიულოთ! დროთა განმავლობაში ყველაფერი გასაგები გახდება. უბრალოდ გაითვალისწინეთ, რომ ანგულარის მე-17 ვერსიიდან სტანდარტული პრაქტიკაა standalone კომპონენტების გამოყენება.

imports არის თვისება, სადაც ჩვენ შეგვიძლია შემოვიტანოთ ანგულარის სხვადასხვა საშენი ბლოკები (კომპონენტები, დირექტივები, ფაიფები და ა.შ), რათა ისინი ამ კომპონენტში გამოვიყენოთ. CommonModule არის მოდული, სადაც ასეთი ყველაზე გამოყენებადი ბლოკებია, ამიტომ CLI-მ ის წინასწარ დაგვიმატა.

კონფიგურაციაში templateUrl მიუთითებს იმ მისამართზე, სადაც თემფლეითის ფაილი უნდა იყოს. styleUrl, შესაბამისად, მიუთითებს სტილების ფაილის მისამართზე.

აღსანიშნავია, რომ @Component დეკორატორში templateUrl-ის მაგივრად შეგვიძლია გამოვიყენოთ template და მარკაპი პირტაპირ ამ თვისების მნიშვნელობაში ჩავწეროთ, როგორც სტრინგი:

@Component({
  selector: 'app-child',
  standalone: true,
  template: `<h1>Hello from ChildComponent!</h1>`,
  styleUrl: "./child.component.css",
})

ასევე შეგვიძლია styles თვისების გამოყენება styleUrl-ის მაგივრად და სტრინგის მიწოდება, სადაც ჩვენ მიერ არჩეული სტილების ფაილის სინტაქსი იმუშავებს:

@Component({
  selector: 'app-child',
  template: `<h1>Hello from ChildComponent!</h1>`,
  styles:`
    h1 {
      color: red;
    }
  `,
})

@Component-ში არსებულ კონფიგურაციას ანგულარის ქომფაილერი კითხულობს, და საჭირო ადგილას (სადაც კომპონენტის თეგებს განვათავსებთ) DOM-ში ამ კომპონენტს ჩასვამს სათანადო ფუნქციონალით. @Component დეკორატორის დანიშნულება ამით არ ამოიწურება. მის შესახებ დეტალური ინფორმაციისთვის გაეცანით ოფიციალურ დოკუმენტაციას.

სიცოცხლის ციკლი

აპლიკაციაში კომპონენტებს გააჩნიათ სიცოცხლის ციკლი. ისინი თავიანთი არსებობის განმავლობაში კონკრეტულ ეტაპებს გადიან და ჩვენ შგევიძლია ამ ეტაპებში კონკრეტული ოპერაციების განხორციელება, ეგრედ წოდებული lifecycle hook-ების დახმარებით. ანგულარი ამის საშუალებას გვაძლევს კომპონენტის კლასში ინტერფეისების იმპლემენტაციით და ამ ინტერფეისების მიხედვით კომპონენტში მეთოდების შექმნით. გავეცნოთ ორ ყველაზე გამოყენებად ჰუკებს: ngOnInit და ngOnDestroy.

ngOnInit

ngOnInit ეშვება, როცა კომპონენტი ინიციალიზირდება. AppComponent-ის შემთხვევაში ეს შეიძლება იყოს როცა მომხმარებელი აპლიკაციას გახსნის. სხვა კომპონენტების შემთხვევაში - მაშინ, როცა აპლიკაცია მათ გამოაჩენს NgIf დირექტივით ან რაუტერით (ამ კონცეფციებს მოგვიანებით ვისწავლით).

ჩვენ შემოგვაქვს OnInit ინტერფეისი angular/core-დან და მას იმპლემენტაციას ვუკეთებთ.

import { Component, OnInit } from "@angular/core";
import { CommonModule } from "@angular/common";

@Component({
  selector: "app-root",
  standalone: true,
  imports: [CommonModule],
  templateUrl: "./app.component.html",
  styleUrls: ["./app.component.css"],
})
export class AppComponent implements OnInit {
  ngOnInit(): void {
    console.log("კომპონენტი ინიციალიზირებულია!");
  }
}

ngOnDestroy

ngOnDestroy მაშინ აქტიურდება, როცა კომპონენტი ნადგურდება. ეს შეიძლება მოხდეს მაშინ, როცა აპლიკაცია გააქრობს კომპონენტს NgIf დირექტივით ან რაუტერით, ან როცა აპლიკაცია დაიხურება. ხშირად ამ ჰუკში ე.წ “მოსუფთავების ლოგიკას” ვწერთ, რათა ბრაუზერის მეხსიერება გავწმინდოთ ზედმეტი მონაცემებისგან.

import { Component, OnDestroy, OnInit } from "@angular/core";
import { CommonModule } from "@angular/common";

@Component({
  selector: "app-root",
  standalone: true,
  imports: [CommonModule],
  templateUrl: "./app.component.html",
  styleUrls: ["./app.component.css"],
})
export class AppComponent implements OnInit, OnDestroy {
  ngOnInit(): void {
    console.log("კომპონენტი ინიციალიზირებულია!");
  }

  ngOnDestroy(): void {
    console.log("აპლიკაცია განადგურდა!");
  }
}

როგორც ხედავთ, ერთ კომპონენტში შეგვიძლია ერთზე მეტი ჰუკის იმპლემენტაცია. დროთა განმავლობაში ამ ჰუკებს პრაქტიკულ მაგალითებში ვნახავთ. ამ ეტაპზე უბრალოდ უნდა ვიცოდეთ ზოგადად რა არის მათი დანიშნულება.

ახლა ვნახოთ, როგორ მუშაობს მარტივი რეაქტიულობა ანგულარში!