ბიბლიოთეკა
00/07 · ~36 წთ
GUIDEDECK · UI, რომელიც ზრდისასაც მარტივი რჩება

თანამედროვე
React, სააზროვნო
მოდელიდან ზემოთ.

36-წუთიანი სამუშაო სესია იმაზე, როგორ ფიქრობს React სინამდვილეში — კომპონენტები და ცალმხრივი მონაცემთა ნაკადი, ჰუკები, რომლებსაც ყოველდღე იყენებთ, ეფექტები, რომლებიც ჩვეულებრივ არ გჭირდებათ, და სად სრულდება თქვენი კოდი ახლა, როცა სერვერი ისევ სურათშია.

~36 წთდამწყები → საშუალოReact 19-ის ეპოქა
გადაახვიეთ
01 · სააზროვნო მოდელი 4 წთ

თქვენი UI არის მდგომარეობის ფუნქცია.

React-ის დიდი იდეა პატარაა: აღწერეთ, როგორ უნდა გამოიყურებოდეს ეკრანი მიმდინარე მონაცემებისთვის, DOM-ის ცვლილებები კი React-ს მიანდეთ. თქვენ არასდროს ძვრებით გვერდში და ხელით არ ასწორებთ ნოუდებს — ცვლით მდგომარეობას და თავიდან აღწერთ. მთელ მოდელს სამი ცნება ატარებს: კომპონენტები, JSX და ცალმხრივი მონაცემთა ნაკადი.

კომპონენტი — ფუნქცია, რომელიც იღებს შემავალ მნიშვნელობებს (props) და აბრუნებს UI-ის აღწერას (JSX). ერთი და იგივე შემავალი ყოველთვის ერთსა და იმავე შედეგს იძლევა, ამიტომ ეკრანს პატარა, პროგნოზირებადი ფუნქციების ხედ კითხულობთ და არა DOM-ში მჩხრეკავი კოდის ერთ დიდ გროვად.

UI = f(state)

  • თქვენ არ ეუბნებით React-ს, როგორ განაახლოს DOM (იმპერატიულად); თქვენ აცხადებთ, რა უნდა იყოს იგი მიმდინარე მდგომარეობისთვის (დეკლარაციულად).
  • შეცვალეთ მდგომარეობა და React ხელახლა გაუშვებს თქვენს კომპონენტს, ახალ აღწერას ძველს შეადარებს და მხოლოდ იმას განაახლებს, რაც განსხვავდება.
  • სწორედ ეს ერთი წესი — რენდერი მდგომარეობის სუფთა ფუნქციაა — ხდის React-ის აპლიკაციას გასაგებს.

შედის მდგომარეობა, გამოდის UI-ის აღწერა. მოვლენა ახალ მდგომარეობას აყენებს და ციკლი თავიდან ეშვება.

// a component is just a function returning JSX function Greeting({ name }) { return <h1>Hello, {name}</h1> } // JSX is sugar for function calls — this compiles to: React.createElement("h1", null, "Hello, ", name) // so {name} is plain JavaScript, not a template string

ცალმხრივი ნაკადი: მონაცემები ქვევით მიდის props-ად; მოვლენები ზევით ბრუნდება callback-ებად. ვერცერთი შვილი გვერდულად ვერ წვდება მეზობელს.

JSX

მარკაპი, რომელიც JavaScript-ია

გამოიყურება როგორც HTML, მაგრამ სინამდვილეში გამოსახულებაა: {} შიგნით ნებისმიერ JS მნიშვნელობას სვამს, className ანაცვლებს class-ს და ყველა თეგი უნდა დაიხუროს.

Props

შემავალი, read-only

მშობელი მონაცემებს ქვევით გადასცემს. კომპონენტი არასდროს ცვლის თავის props-ს — ეს მისი რენდერის ფუნქციის არგუმენტებია.

კომპოზიცია

ხეები და არა შაბლონები

ეკრანები პატარა კომპონენტების ჩალაგებით ააგეთ. children props კომპონენტს საშუალებას აძლევს, შემოახვიოს ყველაფერი, რასაც შიგნით ჩადებთ.

02 · მდგომარეობა, props და ჰუკების წესები 6 წთ

props ზემოდან მოდის;
მდგომარეობა კი კომპონენტის საკუთარი მეხსიერებაა.

თუ მნიშვნელობას მშობელი გადმოგცემთ, ეს prop-ია. თუ კომპონენტს რენდერებს შორის რაღაცის დამახსოვრება სჭირდება — მთვლელი, ფორმის ველი, გახსნილია თუ არა მენიუ — ეს მდგომარეობაა და ჰუკს მიმართავთ. ჰუკები use-ით დაწყებული ფუნქციებია, რომლებიც ჩვეულებრივ ფუნქცია-კომპონენტს მდგომარეობის ქონისა და React-ის შესაძლებლობებთან წვდომის საშუალებას აძლევს.

მდგომარეობა — მონაცემები, რომლებსაც კომპონენტი რენდერებს შორის ინახავს და რომელთა ცვლილებაც ხელახალ რენდერს იწვევს. მას პირდაპირ არასდროს ანიჭებთ მნიშვნელობას; იძახებთ მის სეტერს და React ახალი მნიშვნელობით ახალ რენდერს გეგმავს. მდგომარეობა სნეპშოტია: ერთი რენდერის ფარგლებში მნიშვნელობა ფიქსირებულია.
import { useState } from "react" function Counter() { const [count, setCount] = useState(0) // [value, setter] return ( <button onClick={() => setCount(count + 1)}> Clicked {count} times </button> ) }

სეტერი ერთადერთი კარია: ის ეუბნება React-ს, რომ მნიშვნელობა შეიცვალა და ხელახალი რენდერია საჭირო.

useState თუ useReducer

  • useState — იდეალურია დამოუკიდებელი მნიშვნელობებისთვის: ჩამრთველი, ინფუთი, მთვლელი. ჯერ მას მიმართეთ.
  • useReducer — როცა რამდენიმე მნიშვნელობა ერთად, ნათელი წესებით იცვლება, ლოგიკა ერთ reducer(state, action) ფუნქციაში გადაიტანეთ. კომპონენტი მხოლოდ აგზავნის ქმედებებს.
  • რედიუსერი რთულ გადასვლებს იზოლირებულად ტესტირებადს ხდის და განახლების ლოგიკას მოვლენების ჰენდლერებისგან შორს ინახავს.
function reducer(state, action) { switch (action.type) { case "add": return { ...state, items: state.items + 1 } case "reset": return { items: 0 } } } const [state, dispatch] = useReducer(reducer, { items: 0 }) dispatch({ type: "add" }) // აღწერს, რა მოხდა
ჰუკების წესები — ჰუკები გამოიძახეთ მხოლოდ კომპონენტის (ან სხვა ჰუკის) ზედა დონეზე და მხოლოდ React-ის ფუნქციებიდან. არასდროს გამოიძახოთ ჰუკი პირობის, ციკლის ან ჩადგმული ფუნქციის შიგნით. React მდგომარეობას გამოძახების რიგით აღრიცხავს, ამიტომ ეს რიგი ყოველ რენდერზე იდენტური უნდა იყოს.
ჰუკი პირობის შიგნით
function Profile({ user }) { if (user) { const [name, setName] = useState(user.name) // ✕ } // call order changes when user is null → // React loses track of which state is which }
ყოველთვის ზედა დონეზე
function Profile({ user }) { const [name, setName] = useState(user?.name ?? "") // same hooks, same order, every render ✓ if (!user) return <Empty/> return <Form value={name} onChange={setName}/> }

როგორც  დანომრილი ლოკერები — React მდგომარეობას იმ რიგით გცემთ, რა რიგითაც ითხოვთ, ამიტომ ყოველთვის ერთი და იმავე რიგით უნდა ითხოვოთ. props-ისა და ჰუკების დაბრუნებული მნიშვნელობების ტიპიზაცია ცალკე უნარია; იხილეთ TypeScript-ის დეკი.

03 · ეფექტები — და როდის არ გამოვიყენოთ 6 წთ

ეფექტი სინქრონიზდება
React-ის გარეთ არსებულ სამყაროსთან.

useEffect არ ნიშნავს „რენდერის შემდეგ რაღაც კოდის გაშვებას“ — ეს React-ის გარე სისტემასთან სინქრონში შენარჩუნების გზაა: ქსელური კავშირი, ბრაუზერის API, არა-React ვიჯეტი, გამოწერა. თუ სამუშაო მხოლოდ props-ისა და მდგომარეობის JSX-ად ქცევაა, მისი ადგილი რენდერშია და არა ეფექტში.

ეფექტი — კოდი, რომელიც თქვენს კომპონენტს გარე სისტემასთან ასინქრონიზებს; ის რენდერის შემდეგ ეშვება და მომდევნო სინქრონიზაციამდე ან კომპონენტის მოხსნისას იწმინდება. ის იღებს დამოკიდებულებების მასივს: React ეფექტს მხოლოდ მაშინ უშვებს ხელახლა, როცა ერთ-ერთი ეს მნიშვნელობა იცვლება.

აწყობა გარე სისტემას უკავშირდება; დაბრუნებული გაწმენდა კავშირს წყვეტს. ყოველი ეფექტი, რომელიც ხელს იწერს, უნდა გამოეწეროს კიდეც.

useEffect(() => { const conn = connect(roomId) // აწყობა conn.on("msg", addMessage) return () => conn.close() // გაწმენდა }, [roomId]) // ხელახალი სინქრონი, როცა roomId იცვლება // deps მასივის გარეშე → ეშვება ყოველ რენდერზე (იშვიათად გინდათ) // [] → ერთხელ მაუნთზე, გაწმენდა მოხსნისას

დამოკიდებულებების მასივი React-ისთვის მიცემული პირობაა: „ეს ეფექტი მხოლოდ ამ მნიშვნელობებზეა დამოკიდებული“. შეინარჩუნეთ პატიოსნება.

ალბათ ეფექტი საერთოდ არ გჭირდებათ

ეფექტით გამოთვლა
const [items, setItems] = useState([]) const [total, setTotal] = useState(0) useEffect(() => { setTotal(items.reduce(sum, 0)) // extra render + drift risk }, [items]) // total can briefly disagree with items
უბრალოდ რენდერში გამოთვალეთ
const [items, setItems] = useState([]) const total = items.reduce(sum, 0) // derived, always correct // no second state, no effect, no extra render // if it's ever slow, wrap it in useMemo — not an effect
ეფექტი არ გჭირდებათ:
  • მონაცემები, რომლებიც რენდერის დროს props-იდან ან მდგომარეობიდან გამოგყავთ.
  • მომხმარებლის ქმედებაზე რეაგირება — გააკეთეთ მოვლენის ჰენდლერში.
  • prop-ის ცვლილებაზე მდგომარეობის განულება — ამის ნაცვლად გადაეცით key.
ეფექტი ნამდვილად საჭიროა:
  • გამოწერები და კავშირები (სოკეტები, მოვლენების მსმენელები).
  • არა-React ვიჯეტების მართვა (რუკა, გრაფიკების ბიბლიოთეკა).
  • ბრაუზერის API-ები — სათაური, ფოკუსი, localStorage.
ყურადღება

გამოტოვებული გაწმენდა მსმენელებს ჟონავს; არაპატიოსანი დამოკიდებულებების მასივი მოძველებულ კლოჟერებს იწვევს. დეველოპმენტში Strict Mode ეფექტებს მაუნთზე განზრახ ორჯერ უშვებს — რომ დაკარგული გაწმენდა გამოაჩინოს.

04 · კონტექსტი და კომპოზიცია 5 წთ

გააზიარეთ მდგომარეობა ისე,
რომ ყოველ prop-ში არ გაატაროთ.

როცა მნიშვნელობა ხის სიღრმეშია საჭირო — მიმდინარე თემა, შესული მომხმარებელი, ლოკალი — მისი ყოველი შუალედური კომპონენტის გავლით ჩამოტანა prop drilling-ია: მოსაბეზრებელი, და ყოველი შუალედური კომპონენტი უკვე მიბმულია მონაცემზე, რომელსაც არ იყენებს. ამას ორი ინსტრუმენტი წყვეტს: უკეთესი კომპოზიცია და Context.

Context — გზა, რომ მნიშვნელობა პროვაიდერიდან გამოაქვეყნოთ და ნებისმიერმა შთამომავალმა პირდაპირ წაიკითხოს, შუალედური props-ის გვერდის ავლით. ის იშვიათად ცვალებადი, ფართოდ საჭირო მნიშვნელობებისთვისაა — თემა, ავტორიზაცია, ლოკალი — და არა სწრაფად ცვალებადი მდგომარეობის საერთო საცავად.
App
Provider
Page
Toolbar
Avatar
Avatar
prop drilling
კონტექსტი
useContext

მარცხნივ: მნიშვნელობა რგოლიდან რგოლში გადაეცემა. მარჯვნივ: Provider ერთხელ აქვეყნებს და სიღრმეში მყოფი შვილი პირდაპირ კითხულობს.

const ThemeCtx = createContext("light") // გამოაქვეყნეთ ზემოთ <ThemeCtx.Provider value={theme}> <App/> </ThemeCtx.Provider> // წაიკითხეთ ნებისმიერ ადგილას ქვემოთ — შუალედური props-ის გარეშე const theme = useContext(ThemeCtx)

ჯერ კომპოზიცია სცადეთ

„drilling“-ის დიდი ნაწილი ქრება, თუ მონაცემების გატარების ნაცვლად JSX-ს children-ად გადასცემთ. ლეიაუთის კომპონენტს არ სჭირდება იცოდეს, რას ახვევს.

// Layout არასდროს ეხება user-ს — უბრალოდ children-ს რენდერავს <Layout> <Toolbar><Avatar user={user}/></Toolbar> </Layout>

როდის რომელი

  • კომპოზიცია — მნიშვნელობა ერთი-ორი დონით ქვემოთ ან კონკრეტულ ქვეხეშია საჭირო. ყველაზე იაფი, მიბმის გარეშე.
  • Context — მნიშვნელობა ნამდვილად გლობალური და სტაბილურია (თემა, ავტორიზაცია, ლოკალი).
  • ნამდვილი საცავი — სწრაფად ცვალებადი ან სერვერიდან მოსული მდგომარეობისთვის Context მეტისმეტად ფართოდ იწვევს ხელახალ რენდერს. ეს State Management-ის საქმეა.

როგორც  შენობის გახმოვანების სისტემა — მიმღები ერთხელ აცხადებს და ყველა სართული ისმენს, იმის ნაცვლად, რომ ბარათი მაგიდიდან მაგიდაზე გადაეცეს. გამოიყენეთ განცხადებებისთვის და არა ჩურჩულისთვის.

05 · წარმადობა — რერენდერი და memo 6 წთ

რერენდერი იაფია.
ნაადრევი მემოიზაცია — არა.

React კომპონენტს ხელახლა რენდერავს, როცა მისი მდგომარეობა იცვლება ან მისი მშობელი რენდერდება ხელახლა. ეს ჩვეულებრივ სწრაფი და უპრობლემოა — რერენდერი JSX-ს ითვლის და DOM-ს არ ეხება, სანამ რეალურად რაღაც არ შეიცვალა. წარმადობაზე მუშაობა ძირითადად ორ რამეზეა: სიის სტაბილურ გასაღებებზე და იმაზე, რომ ძვირი სამუშაო უსაფუძვლოდ არ გამეორდეს. memo-ს მხოლოდ მას შემდეგ მიმართეთ, რაც გაზომავთ.

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

მშობლის რერენდერი ყველა შვილამდე მიდის. memo შვილს აძლევს საშუალებას, გამოტოვოს რერენდერი, როცა მისი props უცვლელია.

მემოიზაციის სამი ინსტრუმენტი

  • memo(Component) — გამოტოვებს რერენდერს, როცა props ზედაპირულად იგივეა, რაც წინა ჯერზე.
  • useMemo(fn, deps) — ინახავს ძვირი გამოთვლის შედეგს რენდერებს შორის.
  • useCallback(fn, deps) — ინახავს ფუნქციას, რომ memo-ში გახვეულმა შვილმა ყოველ რენდერზე „ახალი“ props არ დაინახოს.

სამივე მეხსიერებასა და სირთულეს ცვლის ნაკლებ რენდერზე. თუ ყველგან რეფლექსურად გამოიყენებთ, კოდი ძნელად წასაკითხი და ნელა დასაწერი გახდება — გაზომილი მოგების გარეშე.

React Compiler — ოფიციალური, ბილდის დროზე მომუშავე ინსტრუმენტი, რომელიც კომპონენტებსა და მნიშვნელობებს ავტომატურად ამემოიზებს. სადაც ის დანერგილია, ხელით დაწერილი useMemo / useCallback უმეტესად საერთოდ აღარ სჭირდებათ — თქვენ წერთ ჩვეულებრივ კოდს და ქეშირებას კომპილატორი ამატებს. ხელით მემოიზაცია გამონაკლისად მიიჩნიეთ და არა ჩვევად.

keys — ის, რაც აუცილებლად სწორად უნდა გააკეთოთ

მასივის ინდექსი key-ად
{todos.map((todo, i) => ( <Todo key={i} item={todo}/> // ✕ index ))} // reorder or delete a row and React reuses the // wrong DOM node — checkbox state jumps rows
მუდმივი უნიკალური id
{todos.map((todo) => ( <Todo key={todo.id} item={todo}/> // ✓ identity ))} // key tells React which item is which across // renders, so it moves nodes instead of rebuilding

key არის React-ის საიდენტიფიკაციო იარლიყი სიის ელემენტისთვის. გამოიყენეთ სტაბილური id თქვენი მონაცემებიდან — არასდროს მასივის ინდექსი იმ სიისთვის, რომელიც შეიძლება გადალაგდეს, შეივსოს ან შემცირდეს.

06 · სერვერული კომპონენტები, Suspense 6 წთ

რა სრულდება სერვერზე,
რა მიდის ბრაუზერში.

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

React Server Component (RSC) — სერვერზე დარენდერებული კომპონენტი, რომლის შედეგიც მონაცემად იგზავნება ნაკადად და კლიენტს საკუთარი თავისთვის JS-ს არ უგზავნის. ის შეიძლება იყოს async და მონაცემები ადგილზე await-ით აიღოს, მაგრამ ვერ გამოიყენებს მდგომარეობას, ეფექტებს ან ბრაუზერის API-ებს. ინტერაქტიული საზღვარი "use client"-ით მონიშნეთ.
// Server Component — runs on the server, async OK async function Page() { const posts = await db.posts() // no API route needed return <Feed posts={posts}/> } // Likes.tsx — opt into the client for interactivity "use client" function Likes() { const [n, set] = useState(0) }
სერვერი
fetch · JS არ იგზავნება
Page · Feed
ნაკადი
ბრაუზერი · state · ეფექტები · hydrate
Likes · "use client"

სერვერი რენდერავს და ნაკადად აგზავნის; JS-ს მხოლოდ "use client" კუნძულები აგზავნიან და ჰიდრატირდებიან.

Suspense — დეკლარაციული ჩატვირთვა

  • ნელი ნაწილი <Suspense fallback=...>-ში გახვიეთ და React fallback-ს აჩვენებს, სანამ კონტენტი მზად არ იქნება — შემდეგ კი მას ნაკადად ჩამოიტანს.
  • isLoading ფლაგების მთელ ხეში გატარება აღარ გჭირდებათ; ჩატვირთვის მდგომარეობას საზღვარი ფლობს.
  • use() ჰუკი კომპონენტს აძლევს საშუალებას, წაიკითხოს promise (ან context) და შეჩერდეს, სანამ ის არ დასრულდება.
<Suspense fallback={<Skeleton/>}> <SlowFeed/> // ნაკადად ჩამოდის, როცა მისი მონაცემები მზადაა </Suspense> // კომპონენტის შიგნით promise პირდაპირ წაიკითხეთ: const user = use(userPromise) // ჩერდება, სანამ არ დასრულდება

სად აიგება საბოლოოდ HTML — სერვერზე, კლიენტზე თუ სტატიკურად — ეს Rendering Strategies-ის თემაა.

React-ის ლანდშაფტი

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

Next.js

აირჩიეთ, როცა გინდათ, რომ სერვერული რენდერი და მონაცემების წამოღება თავიდან ბოლომდე თქვენ მაგივრად მოგვარდეს.

  • დადებითი — ყველაზე სრული RSC + App Router; უზარმაზარი ეკოსისტემა და დეპლოის ვარიანტები.
  • უარყოფითი — მკაცრი შეხედულებები და დიდი მოცულობა; ქეშირების მოდელს სწავლა სჭირდება.
React Router v7

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

  • დადებითი — Remix-ის მემკვიდრეობა; აშკარა loaders/actions, მუშაობს როგორც ფრეიმვორკი, ისე უბრალო როუტერი.
  • უარყოფითი — RSC-ის უფრო ვიწრო მხარდაჭერა; Next-ზე ნაკლები მზა ფუნქციონალი.
Vite SPA

აირჩიეთ შიდა ინსტრუმენტებისა და ავტორიზაციის მიღმა მყოფი დაშბორდებისთვის, სადაც SEO და პირველი დახატვა მთავარი არ არის.

  • დადებითი — ყველაზე მარტივი მოდელი: სუფთა კლიენტზე დარენდერებული აპლიკაცია, სწრაფი dev სერვერი, სერვერული რანტაიმის გარეშე.
  • უარყოფითი — სერვერული კომპონენტები არ არის; SEO, მონაცემების წამოღება და კოდის დაყოფა თქვენი პასუხისმგებლობაა.

პატიოსანი ნაგულისხმევი: შიდა აპლიკაცია ყველაზე კარგად Vite SPA-დ გრძნობს თავს; საჯარო, კონტენტით სავსე პროდუქტს სერვერული ფრეიმვორკი უნდა. ნუ აიღებთ RSC-ს იმ აპლიკაციისთვის, რომელსაც სერვერი არასდროს სჭირდებოდა.

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

Radix / React Aria

აირჩიეთ, როცა გჭირდებათ საკუთარი დიზაინ-სისტემა, მაგრამ არა ხელმისაწვდომობის თავიდან გამოგონება.

  • დადებითი — უსტილო, ხელმისაწვდომი ქცევის პრიმიტივები (მენიუები, დიალოგები), რომლებსაც თავად აფორმებთ.
  • უარყოფითი — მთელი ვიზუალი თქვენზეა; მეტი საწყისი სამუშაო.
shadcn/ui

აირჩიეთ, როცა გინდათ სწრაფი დასაწყისი და კოდზე სრული კონტროლი.

  • დადებითი — გაფორმებულ კომპონენტებს (Radix-ზე აგებულს) თქვენს რეპოზიტორიაში აკოპირებთ; კოდი თქვენია და თქვენვე ცვლით.
  • უარყოფითი — ეს საწყისი წერტილია და არა ვერსიონირებული დამოკიდებულება; მისი მხარდაჭერა თქვენზეა.
MUI / Mantine

აირჩიეთ შიდა ინსტრუმენტებისთვის ან როცა სისწრაფე საკუთარ ბრენდს სჯობს.

  • დადებითი — სრულად აღჭურვილი დიზაინ-სისტემა; გამართული აპლიკაცია სწრაფად გამოდის.
  • უარყოფითი — უფრო მძიმე ბანდლი; ბიბლიოთეკის იერსახიდან გამოსვლა ძნელია.

პრიმიტივები იქ მთავრდება, სადაც დიზაინის შეხედულებები იწყება: პრიმიტივი გაძლევთ სწორ, ხელმისაწვდომ ქცევას; UI ბიბლიოთეკა ზემოდან ვიზუალურ სისტემას ამატებს. მდგომარეობის ინსტრუმენტები ცალკე ღერძია — იხილეთ State Management.

07 · მონაცემების წამოღება + შეჯამება 3 წთ

წამოიღეთ იქ, სადაც იაფია;
შემდეგ კი ხუთი წესით გახვედით.

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

ჯერ სერვერი

წამოიღეთ სერვერულ კომპონენტში და მონაცემები ქვევით გადაეცით. არანაირი ჩატვირთვის ფლაგი, არანაირი კლიენტის ჩანჩქერი — მონაცემები HTML-თან ერთად მოდის.

სერვერის state კლიენტზე

ბრაუზერში წამოღებული მონაცემებისთვის გამოიყენეთ TanStack Query ან SWR: ქეშირება, დუბლიკატების მოცილება და ფონური ხელახალი წამოღება. ნუ შეინახავთ სერვერის მონაცემებს useState-ში.

მუტაციები

Actions და useActionState უვლის ფორმების გაგზავნას და მოლოდინის თუ ოპტიმისტურ UI-ს ხელით დაწერილი fetch-ისა და setState-ის ცეკვის გარეშე.

გაყოფა სერვერულ მდგომარეობასა (მონაცემები, რომლებსაც ბექენდიდან ქეშირებთ) და კლიენტის მდგომარეობას (მხოლოდ UI) შორის State Management-ის დეკის გულია — „React ძნელია“ ტკივილის უმეტესობა სინამდვილეში შენიღბული სერვერული მდგომარეობაა.

1UI მდგომარეობის ფუნქციაა. შეცვალეთ მდგომარეობა და ეკრანი თავიდან აღწერეთ — არასდროს შეცვალოთ DOM ხელით.
2props ქვევით, მოვლენები ზევით. ცალმხრივი მონაცემთა ნაკადი, ჰუკები კი ყოველთვის ზედა დონეზე და ერთსა და იმავე რიგით.
3ეფექტები გარე სამყაროსთან სინქრონიზაციისთვისაა. თუ რენდერში გამოგყავთ ან მოვლენაში დაამუშავებთ, ეფექტი არ გჭირდებათ.
4მემოიზაციამდე გაზომეთ. სტაბილური keys ყოველთვის მნიშვნელოვანია; memo — იშვიათად, და მის უმეტეს ნაწილს კომპილატორი აკეთებს.
5იცოდეთ, სად სრულდება კოდი. სერვერული კომპონენტები მონაცემებისა და ნულოვანი JS-ისთვის; "use client" კუნძულები ინტერაქტიულობისთვის.
  • საჯარო, კონტენტზე ან SEO-ზე ორიენტირებული პროდუქტი? → Next.js (ან React Router v7) — სერვერული რენდერი ამართლებს.
  • შიდა ინსტრუმენტი ან დაშბორდი ავტორიზაციის მიღმა? → Vite SPA; ნუ აიღებთ სერვერს, რომელიც არ გჭირდებათ.
  • კლიენტზე წამოღება? → TanStack Query / SWR და არა შიშველი ეფექტები.
  • გინდათ memo ყველგან დაამატოთ? → ამის ნაცვლად ჩართეთ React Compiler და გაზომეთ.
ცოდნის შემოწმება

დაგამახსოვრდათ?

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

შეაფასეთ ეს დასტა
იყავით პირველი

ნავიგაცია ← → ღილაკებით ან სქროლით · უკან ბიბლიოთეკაში