Components

აქ მინდა უბრალოდ ვისაუბრო კომპონენტების დაყოფის და წერის ლოგიკაზე.

ხშირად ისმის შეკითხვა თუ როდის უნდა გავიტანოთ კოდის ნაწილი კომპონენტებში და სამწუხაროდ მაგაზე პასუხი არის "you will get a feel for it when you get experience", რაც მეც პირადად ხშირად მესმოდა და არ მაკმაყოფილებდა, მაგრამ სამწუხაროდ ეს სიმართლესთან საკმაოდ ახლოსაა მე ვერ დაგიდებთ წესს რომ თუ კოდი 50 ხაზზე მეტია მაშინ უნდა გაიტანოთ აუცილებლად ან რამე ეგეთს, მაგრამ შემიძლია რამდენიმე რჩევა მოგცეთ რაც დაგეხმარებათ აწონ-დაწონვაში, ღირს თუ არა კომპონენტის დაყოფა ცალკე კომპონენტებად:

• დაიმახსოვრეთ რომ კომპონენტში გატანა მარტო re-usability-ის გამო არ ხდება და კოდის კითხვადობის გაუმჯობესებაც უნდა იყოს თქვენი მიზანი. ამის გამო არ მინდა რომ წესი დაგეწესოთ რომ მაინც და მაინც 50 ხაზს თუ გაცდა აუცილებლად გაიტანეთ, მაგრამ გირჩევთ გქონდეთ რაციონალური ზღვარი და თუ კომპონენტი მას გადასცდა, უმჯობესია ცალკე გაიტანოთ, რომ კოდი სუფთა იყოს.

• კიდევ საკმაოდ ხშირად მაქვს ნანახი რომ ზოგი დეველოპერი იმისთვის რომ jsx ადვილად წაიკითხოს ასეთი ტიპის კომენტარებს წერს ხოლმე "this is profile dropdown", "this is login button", "this is delete modal" და ასე შემდეგ. თუ ოდესმე ასეთი რამის საჭიროება იგრძენით ჯობია კომპონენტად გაიტანოთ.

• ამას ხშირად გაიგონებთ ალბათ მაგრამ თუ ხშირად იმეორებთ ერთსა და იმავე რაღაცას აუცილებლად გაიტანეთ კომპონენტში ეს ფაილი.

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

ასევე მინდა ვისაუბრო კომპონენტის წერის ლოგიკაზე და როგორ ჯობია რომ არქიტექტურა მოვაწყოთ:

• კომპონენტებში არ შეამომოთ რაიმე გლობალური რისი შეცვლაც ძნელია, მაგალითად თუ თქვენ გაქვთ navbar კომპონენტი და გინდათ რომ logout ღილაკი არ დაარენდეროთ თუ უსერი არის login რაუტზე, შეიძლება თქვენი პირველი აზრი ის იყოს რომ უბრალოდ რაუტი შეამოწმოთ, მაგრამ სანამ ამას დაწერთ ერთი ცხოვრების უნივერსალური წესი გახსოვდეთ "ის იდეა რომელიც პირველად მოგივათ თავში და ადვილი ჩანს ყოველთვის არის ყველაზე ცუდი გზა რამის გაკეთების და კვირების/წლების მერე თავს გაგახსენებთ". როცა ამას გაიხსენებთ მერე უმჯობესი იქნება თუ თქვენ იმის მაგივრად რომ ასე შიგნით შეამოწმოთ, პროპს დაამტებთ რომელსაც ერქმევა რაიმე ასეთი : "hasLogout" და უბრალოდ ამ პროპსს შეამოწმებთ იმის მაგივრად რომ რაუტები ამოწმოთ. ეს იმიტომ რომ მერე შეიძლება დაგჭირდეთ კიდე სადმე ამის გაქრობა, მერე დაგჭირდეთ რაიმე სხვა ღილაკის გაქრობაც, რამე გვერდი გამოჩნდეს სადაც ლოგაუთის მაგივრად სხვა ღილაკი დაგჭირდეთ და ასე შემდეგ. ამის გამო აჯობებს პროპი. ამ თემაზე კიდე ბევრს ვილაპრაკებ შემდეგ წესებში.

• ზემოთ რაც ვახსენე მაგას თუ გაყვებით შეიძლება შეკითხვა გაგიჩდეთ, აბა სად შევამოწმო რაუტები და რაიმე გლობალური. მე პირადად იდეურად ვყოფ ხოლმე კომპონენტებს, ზოგი კომპონენტი არის ისეთი რომელსაც ხშირად ვიყენებთ, ბევრი პროპი აქვს, ბევრ გვერდს უნდა მოერგოს. ამის საპირისპიროა კომპონენტები რომლებიც მარტო ერთხელ რენდერდება და უბრალოდ კომბინაცია არის სხვა რამდენიმე კომპონენტის ძალიან ცოტა ლოგიკით. თუ ამ იდეოლოგიას ეთანხმებით, მაშინ შეგიძლიათ ისე დაყოთ როგორც მე ვყოფ ხოლმე. თუ კომპონენტი ისეთია რომელსაც ალბათ ხშირად გამოვიყენებ და ბევრ ადგილს უნდა მოერგოს, უმჯობესია თუ ეს ფაილი გაკონტროლდება პროპებით და არანაირ გარეს არ შეამოწმებს და თუ კომპონეტი ისეთია რომელიც მარტო რამდენიმე ადგილზე კონტროლდება უმჯობესია თუ ის თავის თავს და თავის შვილ კომპონენტებს თავისით გააკონტროლებს თუ რაიმე სხვა მიზეზი არ არსებობს. ამ კომპონენტებში შეიძლება რომ ვნახოთ მომხმარებლის ავთენთიფიკაციის სტატუსი, ვნახოთ რა რაუტზე ვართ და სხვა უამრავი რამ, ეს ზემოთ ხსენებულები ხშირად გამოყენებად კომპონენტებში რომ დაწეროთ კი ადვილი იქნება თავიდან მარა in the long term ძალიან გაგიპრობლემებთ ყველაფერს და ამ კომპნენტთან მუშაობა ჯოჯოხეთი გახდება.

• კომპონენტების პროპებით კონტროლი როცა შემოდის მერე ჩნდება შეკითხვა prop drilling-ზე. ერთი ის დაიმახსოვრეთ რომ prop drilling არ არის 2-3 კომპონენტში ჩასვლა, აქ უფრო საუბარია 5-6 დონის სიღრმეზე. ამას თავი უნდა აარიდოთ. ლოგიკა ან უფრო დაბლა უნდა ჩაიტანოთ როგორმე ან კონტექტი/redux უნდა გამოიყენო. კი ზემოთ ვთქვი რომ უნდა ავარიდოთ ასეთ გლობალურ ჩეკებს თავი მაგრამ მე ეს ვიგულსიხმე ისეთ კომპონენტებში რომლებიც რამდენიმე გვერდზე რენდერდება. იმის შანსი რომ 6 დონის პროპ დრილინგი გაქვთ და ყველა კომპონენტი მანდ არის ბევრ ადგილზე გამოყენებული, საკმაოდ დაბალია და თუ ეგ ხდება მაშინ ჯობია ეგ კომპონენტები შეკრათ რამენაირად და პროპ დრილინგის პრობლემაც მოგვარდება

• ბევრი ვილაპრაკე პროპებით კონტროლზე, მაგრამ ესეც ძალიან ადვილად შეიძლება გაიქცეს ხელიდან. მოდი იმ მაგალითზე ვილაპარაკოთ, რომელსაც თქვენ ალბათ ხშირად შეხვდებით. გაქვთ მოდალი, მოდალი შედგება title-ისგან, ჩახურვის ღილაკისგან, body-სგან, და 2 გათიშვა და დასაბმიტების ღილაკისგან. ამ სცენარს ყველა დეველოპერი კარგად იცნობს, ასერომ მოდი დავფიქრდეთ თუ ამას როგორ დავწერდით. რათქმაუნდა პირველ რიგში კომპონენტს გავაკეთებდით, title-ის ტექსტი კონტროლდება გარედან, body იქნება როგორც ჩილდრენი და გათიშვა გახსნის ღილაკების ტექტი გაკონტროლდება გარედან, sounds great!, მაგრამ ზემოთ ხსენებული უნივერსალური წესი გაიხსენეთ! ეს ძალიან ცუდად დამთავრდება იმ დროს როცა მოგინდება რომ title-ს ფონტი შეცვალო, x ღიალკი გააქრო, backdrop-ის ფერი შეცვალო. cancel და confirm ღილაკი გადაანაცვლო. ამის გამო მოდი სხვა ვარიანტს შემოგთავაზებთ, ზოგადად როცა რაიმე პრობლემა გაქვთ ორგანიზაციასთან და არქიტექტურასთან გირჩევთ რომ რაიმე გარე ლაიბრარის მიმართოთ და შეხედოთ ისინი როგორ აწყობენ ამას, უამრავი UI ლაიბრარი არსებობს ვიღაცას კაი ვარიანტი მოფიქრებული ექნება! და რათქმაუნდა მართლაც რომ აქვთ:

  • მოდი ავიღოთ shadcn/ui და material ui. თუ მათ კომპონენტებს შევხედავთ უმეტესობა კომპონენტი საკმაოდ პატარაა და შედგება ე.წ. building block-ებისგან და ჩემი რჩევაც ეს იქნება რომ კომპონენტები ასე მოაწყოთ, ანუ ზუსტად რას ვგულსიხმობ იმ მოდალის მაგალითს რომ დავუბრუნდეთ. იმის მაგივრად რომ ერთი მოდალის კომპონენტი შევქმნათ ჩვენ მოდი ასე დავიწყოთ:

    • შევქმნათ მოდალის ღილაკის კომპონენტი

    • ბექდროპის კომპონენტი

    • ზედა title-ის კომპონენტი

    • ქვედა სექციის ღილაკიების კომპონენტები

    • ეს კომპონენტები გავსტილოთ მინიმალურად

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

    • ჩვენ ეხლა აწყობილი გვაქ building block component-ები და შეგვიძლიაა ავაწყოთ მოდალი როცა დაგვჭირდება ხოლმე. მაგრამ მოიცა ეს ტვინის ჭმა იქნება ყველა ჯერზე ამდენი რომ ვაკეთოთ 😢, ამის გამო ჩვენ შეგვიძლია შემდეგი რამის გაკეთება:

      • ავაწყოთ ერთი მოდალის კომპონენტი

      • ამ მოდალის კომპნენტში გავწეროთ ლოგიკა ჩახურვის, გახსნის და ასევე დავარენდეროთ ეს ყველა კომპონენტი რაიმე sensible default-ებით, მივცეთ საშულება ტექსტის კოფინგრაიციის და ასე შემდეგ. იგივეს დავუბრუნდით ეხლა 😒, დავუშვათ და მოგვინდა რომ ღილაკს ფერი შევუცვალოთ, ტექტის ფონტი გავზარდოთ, ბექდროპის ფერი შევცვალოთ, fear not ამდენი ტყუილად არ გაწვალეთ, ეხლა იმის მაგივრად რომ ოფშენი ვამატოთ ყველაფრისთვის ჩვენ შეგვიძლია რომ ამოცვლის საშულება მივცეთ კომპონენტს, ანუ ღილაკი დავარენდეროთ დეფოლტი მაგრამ თუ პროპად ჩამოაწოდეს სხვა ღილაკი მაშინ ეგ დავარენდეროთ და voilà, შევქმენით მოდალის კომპონენტი რომელიც საუკუნე გასტანს. თუ მოგვინდება რამის შეცვლა ძალიან ადვილად ამოვცვლით. ამ კომპონენტის გამოყნეებას ყველგან შევძლებთ

იმედია ბევრი კითხვა არ მოგივიდათ ამ კომპონენტების მოწყობაზე. გიხარდოდთ! კიდე მაქ სალაპარაკო

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

• ფუნქცები თუ რამე გიწევთ დაწერა ესენი თუ state-full არის გაიტანეთ ზემოთხსენებულ ჰუკში და თუ არ არის მაშინ helpers საქაღალდე შექმენით ამ კომპონენტის საქაღალდეში და ყველა ჰელპერს მანდ გაიტანთ თუ რამე საჭირო იქნება და სტეიტზე შეხება არ ექენბა ამ ფუნქციას

• რამე რთული if ლოგიკა არასოდეს არ გაწეროთ jsx-ში, 1 ტერნერის ჩეკი ნორმალურია, მაგრამ ჩანესტვა თუ გიწევთ რამდენიმე ტერნერის ჩეკის მაშინ პირველ რიგში შეხედეთ გამარტივება თუ შეიძლება, მაგრამ თუ არ შეიძლება ფუნქცია შექემნით ჰელპერში და იქ გაიტანეთ ეგ ლოგიკა დარენდერების და მერე იქ შეგიძლიათ ჩველებრივი if ჩეკები წეროთ რაც შედარებით ბევრად მარტივი წასაკითხია

• თუ უბრალო კომპონენტს აკეთებთ როგორიც არის ღილაკი, პროპების დეკლარაციისას უმჯობესია თუ მიცემთ საშულებას პროპების საშულებით რომ ყველაფერი დააკონფიგურირონ, ანუ ღილაკს რა პროპიც აქვს ყველაფრის ჩაწოდების შესაძლებლობა უნდა არსებობდეს. მე არ გეუნებით რომ ყველაფერი ხელით ჩამოწეროთ. თუ თქვენ js-ში ხართ უბრალოდ რაც გჭირდებათ უეჭველი ეგენი ხელით გაწერეთ და დანარჩენი spread operator-ით ჩააწოდეთ ბათონს ასე <button {...props}></button> და რაც შეეხება typescript-ს ტიპი ასე უნდა დააკლარიროთ:

import type { HTMLProps } from 'react';

export type Props = {
  variant: 'purple';
} & HTMLProps<HTMLButtonElement>;

აქ უბრალოდ ის ხდება რომ ღილაკის პროპები კომბინირდება და ყველაფერი რაც დეფოლტ ღილაკს აქვს იგივე პროპები გადაყვება ამ კომპონენტს და მერე ჩვენც შეგვიძლაი დავამატოთ თუ რამე გვიჭირდება

• კომპონენტი დეფოლტ ექსპოტი უნდა იყოს მუდმივად

• პირადი რეკომენდაცია და მესმის თუ არ გაითვალისწინებთ მაგრამ prop-ის დესტრუქტურიზაციას არ გირჩევთ და უმჯობესია თუ props.children-ს იზამთ და არა children. ეს ცოტა heated argument არის ასერომ მე მინდა ჩემი მხარე წარმოგიდგინოთ თუ რატო არ გირჩევთ დესტრუქტურიზაციას. პროპი არ არის ჩველებრივი ცვლადი, პროპი კომპნენტის რერენდერს იწვევს და განსაკუთრებულია. ისეთია რომელიც არ უნდა შევცვალოთ და ფრთხილად უნდა მოვექცეთ, ამის გამო ჩემი აზრით უმჯობესია თუ ასეთ ცვლადებს გამოვყოფთ. ეს ცვლადები სხვა კომპონენტის კუთვუნლებაა დღის ბოლოს და მაგიტომ არ ვუჭერ მხარს დესტრუქტურიზაციას, გარდა იშვიათი ქეისებისა სადაც მართლა საჭიროა

• jsx-ში კომპლექსურ ექსპრეშენებს მოერიდეთ და ჰელპერებში გაიტანეთ თუ რამე არის გასატანი. jsx საკმარისად ძნელად წასაკითხია ზემოდან რომ არ დავუმატოთ კიდე კომპლექსური js. მარტო მარტივი რაღაცები გაწერეთ inline