[Senior] Render Phases: Render, Pre-commit, Commit

Հարց: Ի՞նչ փուլերով է անցնում React-ը update-ի ժամանակ։

Սխալ պատասխան:
Շատերը render phase-երը շփոթում են lifecycle method-ների հետ կամ մտածում են, որ render-ը DOM update-ն է։

Ճիշտ պատասխան։ Update-ի ժամանակ React-ը անցնում է հետևյալ phase-երով.

1️⃣ Render phase
- React-ը հաշվարկում է նոր tree-ն
- Կատարում է reconciliation
- DOM-ին չի դիպչում
- Պետք է լինի pure (no side effects)
- React-ը կարող է render phase-ը ընդհատել կամ կրկնել (Concurrent rendering)

2️⃣ Pre-commit phase
- React-ը պատրաստվում է commit անել փոփոխությունները
- Այստեղ հավաքվում են effect-ները
- Տեղի է ունենում useEffect / useLayoutEffect registration

3️⃣ Commit phase
- React-ը update է անում DOM-ը
- Կանչվում է useLayoutEffect (synchronously)
- Տեղի է ունենում browser paint
- Ապա կանչվում է useEffect (asynchronously)

💡 Tip: Lifecycle method-ները abstraction են, իսկ render phase-երը React-ի իրական աշխատանքային մոդելն է։
Interview-ում տարբերությունը հստակ բացատրելը senior signal է։

Եթե ուզում եք փորձել ձեզ իրական React mock interview-ում և ստանալ structured feedback՝ գրեք ինձ DM → @lianavagyantech

[Senior] React Reuse Patterns

Հարց: Ինչպե՞ս reuse անել logic-ը React-ում՝ առանց duplication-ի։

Սխալ պատասխան։ Շատերը անմիջապես ասում են՝ ուղղակի component ստեղծել։

Ճիշտ պատասխան։ Reuse-ը React-ում տարբեր մակարդակներ ունի.

1️⃣ Custom Hooks
Logic reuse առանց UI coupling-ի → separation of concerns։ Օր.՝ useAuth, useDebounce, useFetch

2️⃣ Higher-Order Components (HOC)
Component wrapper pattern
→ cross-cutting concerns (permissions, logging).
Այժմ ավելի քիչ է օգտագործվում custom hook-երի պատճառով, քանի որ նրանք լուծեցին logic reuse-ը ավելի պարզ ձևով։

3️⃣ Render Props
Dynamic rendering pattern.
Երբ component-ը ստանում է function prop և այդ function-ի միջոցով որոշվում է, թե ինչ render անել։

Ինչու՞ է սա կարևոր.

Եթե reuse-ը անում եք միայն copy-paste-ով, կուտակվելու են bug-եր և առաջանալու է tight coupling։

💡 Tip: Լավ reuse pattern-ը լուծում է duplication-ը՝ առանց ավելացնելու unnecessary abstraction։

Եթե ուզում եք փորձել Ձեզ իրական React mock interview-ում և ստանալ structured feedback՝ գրեք ինձ DM → @lianavagyantech

[Mid+] React.memo

Հարց: Ի՞նչ է React.memo-ն և ինչպիսի՞ համեմատություն է անում այն props-երի միջև։

Սխալ պատասխան: React.memo-ն խորը (deep) համեմատում է props-երը և եթե տարբերություն չգտնի՝ render չի անում։

Ճիշտ պատասխան: React.memo-ն Higher Order Component է, որը memoize է անում component-ի render արդյունքը։ By default անում է shallow comparison: Յուրաքանչյուր prop համեմատվում է Object.is-ով: Reference type-երի դեպքում համեմատվում է reference-ը։ Այսինքն եթե փոխանցենք.



<Component data={{ a: 1 }} />



Ապա յուրաքանչյուր render-ի ժամանակ նոր object կստեղծվի, ինչի արդյունքում reference-ը կփոխվի, և component-ը re-render կանի։

Ինչպե՞ս անել deep comparison:

React.memo-ն ունի optional 2-րդ պարամետր.



React.memo(Component, areEqual)



areEqual(prevProps, nextProps)-ը ֆունկցիա է, որը վերադարձնում է boolean: Եթե վերադարձնում ենք true, render-ը skip է արվում։ Խորը համեմատություն կարելի է անել օրինակ՝



(prev, next) => deepEqual(prev.data, next.data)


կամ օգտագործելով library (օր. lodash isEqual)։
Բայց այստեղ կա կարևոր nuance։ Deep comparison-ը կարող է ավելի expensive լինել, քան render-ը։ Այդ պատճառով React-ը by default shallow comparison է անում։

💡 Tip: Եթե պետք է deep comparison անել, հաճախ ավելի ճիշտ լուծումը stable reference ապահովելն է (useMemo, useCallback) կամ component boundary փոխելը։

Եթե ուզում եք փորձել Ձեզ իրական React mock interview-ում և ստանալ structured feedback՝ գրեք ինձ DM → @lianavagyantech

[Mid+] Rules of Hooks

Հարց: Որո՞նք են Hook-երի հիմնական կանոնները և ինչու՞ են դրանք պարտադիր։

Սխալ պատասխան: Hook-երը պարզապես պետք է կանչել component-ի top level-ում, որովհետև React-ն այդպես է պահանջում։

Ճիշտ պատասխան: React-ում կան hook-երի օգտագործման 3 հիմնական rule-եր.

1️⃣ Hook-երը պետք է կանչել միայն component-ի կամ custom hook-ի top level-ում։
Չի կարելի կանչել if-ի, loop-ի կամ nested function-ի ներսում, քանի որ React-ը hook-երին չի տալիս անուններ, այլ հիշում է նրանց ըստ call order-ի.



useState();
useEffect();
useMemo();



Եվ եթե render-ներից մեկում որևէ hook conditionally skip անենք, React-ը կշփոթի mapping-ը։

2️⃣ Hook-երը պետք է կանչել միայն React function component-ից կամ custom hook-ից։ Պատճառը նույնն է՝ React-ը պետք է լինի render context-ի ներսում, որպեսզի hook call-ը գրանցվի համապատասխան Fiber node-ի վրա։

3️⃣ Custom hook-ը պարզապես function է, որը կանչում է այլ hook-եր, բայց այն պարտադիր պետք է պահպանի նույն rule-երը։

💡 Tip: Եթե interview-ում կարողանում եք բացատրել, որ hook-երի կանոնները կապված են call order-ի հետ, դա արդեն ցույց է տալիս, որ հասկանում եք ներքին մեխանիզմը, այլ ոչ թե միայն ESLint rule-ը։

Եթե ուզում եք փորձել Ձեզ իրական React mock interview-ում և ստանալ structured feedback՝ գրեք ինձ DM → @lianavagyantech

[Mid] Controlled vs Uncontrolled Components

Հարց: Ո՞րն է Controlled և Uncontrolled component-ների տարբերությունը React-ում։

Սխալ պատասխան: Controlled component-ը այն է, երբ input-ը ունի state, իսկ Uncontrolled-ը՝ երբ չունի։

Ճիշտ պատասխան:
Controlled component-ի դեպքում input-ի արժեքը պահվում է React state-ում և վերահսկվում է React-ի կողմից։ Value-ն գալիս է state-ից, իսկ onChange-ը թարմացնում է state-ը։
Այսինքն UI-ի single source of truth-ը React state-ն է։

Uncontrolled component-ի դեպքում input-ի state-ը պահվում է հենց DOM-ում, և React-ը անմիջապես չի կառավարում այն։ Այս դեպքում արժեքը ստացվում է ref-ի միջոցով։

Use case-եր.

Controlled component
• form validation
• complex form logic
• conditional UI

Uncontrolled component
• պարզ form-եր
• native form behavior
• performance-sensitive input-ներ

⚠️ Interview trap
Եթե controlled input-ին սկզբում տանք defaultValue, հետո փորձենք այն դարձնել controlled value-ով, ապա React-ը warning կտա։
Պատճառն այն է, որ component-ը render-ների ընթացքում չի կարող փոխել իր controlled/uncontrolled nature-ը։ Այսինքն component-ը պետք է լինի կամ controlled, կամ uncontrolled ամբողջ lifecycle-ի ընթացքում։

💡 Tip: Controlled component-ները տալիս են predictable data flow, բայց ընտրությունը իրականում կախված է use case-ից։

Եթե ուզում եք փորձել Ձեզ իրական React mock interview-ում և ստանալ structured feedback՝ գրեք ինձ DM → @lianavagyantech

[Mid+] Keys in React

Հարց: Ինչու՞ են key-երը կարևոր React-ում։

Սխալ պատասխան: Key-երը պետք են, որ React-ը կարողանա որոշել, թե որ element-ը փոխվեց և update անի DOM-ը։

Ճիշտ պատասխան: Key-երը օգտագործվում են reconciliation-ի ժամանակ՝ նախորդ render-ից հետո list-երում element-ները match անելու համար՝ ամբողջ tree-ն խորությամբ համեմատելու փոխարեն։ Օրինակ.

items.map((item, index) => <Item key={index} />)



Այս դեպքում եթե list-ում reorder լինի, index-ը կփոխվի ու React-ը կմտածի, որ բոլոր element-ները փոխվել են։ Արդյունքում կլինի unnecessary re-render, state mismatch ու UI bug-եր։

Ինչ է իրականում անում React-ը.

• Եթե key-ն նույնն է, reuse է անում existing component-ը
• Եթե key-ն փոխվել է, unmount է անում, ապա mount անում նոր component

Այսինքն key-ն component identifier է։

💡Tip: Index-ը որպես key օգտագործելը ապահով է միայն, եթե.
• list-ը static է
• reorder / insert / delete չկա
Հակառակ դեպքում կարող ենք ստանալ շատ բարդ debug արվող bug-եր։

Եթե ուզում եք փորձել Ձեզ իրական React mock interview-ում և ստանալ structured feedback՝ գրեք ինձ DM → @lianavagyantech

[Mid+] useRef vs useState

Հարց: Ո՞րն է useRef-ի և useState-ի տարբերությունը։

Սխալ պատասխան: useRef-ը նույնն է ինչ useState-ը, պարզապես re-render չի առաջացնում։

Ճիշտ պատասխան: useState-ը պահում է state, որի փոփոխությունը առաջացնում է re-render, իսկ useRef-ը պահում է mutable value, որի փոփոխությունը չի առաջացնում re-render։ useRef-ը վերադարձնում է object.

const ref = useRef(initialValue);



ref-ը object է, որը պահպանում է նույն reference-ը render-ների ընթացքում, իսկ ref.current-ը պահում է արժեքը։

Եթե useRef-ով պահեք value, որը օգտագործվում է render-ում, React-ը չի իմանա, որ պետք է re-render անի, և UI-ը update չի լինի։

Use case-եր.

useState
• UI state (input value, toggle, data)
• այն ամենը, ինչ պետք է render-ում երևա

useRef
• DOM reference (focus, scroll)
• mutable value, որը չպետք է trigger անի render
• previous value պահելու համար

💡 Tip։ useRef-ը “escape hatch” է React rendering model-ից։ Interview-ում կարևոր է ցույց տալ, որ հասկանում եք ոչ միայն տարբերությունը, այլ նաև render cycle-ի վրա ազդեցությունը։

Եթե ուզում եք փորձել Ձեզ իրական React mock interview-ում և ստանալ structured feedback՝ գրեք ինձ DM → @lianavagyantech

[Mid+] useEffect dependencies

Հարց: Ինչպե՞ս են աշխատում useEffect-ի dependency-ները, և ինչու՞ են դրանք կարևոր։

Սխալ պատասխան: Dependency array-ը որոշում է, թե երբ effect-ը պետք է աշխատի։

Ճիշտ պատասխան: Dependency array-ը չի կառավարում effect-ը, այլ ասում է React-ին՝ երբ պետք է effect-ը վերագործարկվի render-ներից հետո։
Այսինքն.
- Effect-ը միշտ կապված է render-ի հետ
- Dependency-ները որոշում են՝ արդյոք պետք է reuse անել նախորդ effect-ը, թե ստեղծել նորը

Ինչ է իրականում տեղի ունենում։
Յուրաքանչյուր render-ի ժամանակ React-ը.
1️⃣ Ստեղծում է նոր effect function
2️⃣ Համեմատում է dependency-ները նախորդ render-ի հետ
3️⃣ Եթե գոնե մեկը փոխվել է, ապա տեղի է ունենում cleanup + նոր effect

Օրինակ՝

useEffect(() => {
  console.log("run")
}, [count])

Եթե count-ը չի փոխվել՝ effect-ը rerun չի լինի։ Եթե փոխվել է՝ տեղի կունենա cleanup, ապա՝ նոր effect։

Եթե dependency array-ը սխալ է, կարող ենք ստանալ.
• stale value-ներ (հին state/props)
• infinite loop • side effect-ներ սխալ timing-ով

Օրինակ՝

useEffect(() => {
  fetchData()
}, [])

Եթե fetchData-ն օգտագործում է props/state, ապա կարող ենք ունենալ stale closure։

💡 Tip։ Dependency array-ը optimization չէ, այլ ճիշտ աշխատանքի համար է։ Եթե effect-ը կախված է ինչ-որ value-ից, այն պետք է լինի dependency-ում։
Interview-ում կարևոր է բացատրել closure-ի գաղափարը, այլ ոչ թե միայն, թե ինչ է պետք դնել array-ում։

Եթե ուզում եք փորձել Ձեզ իրական React mock interview-ում և ստանալ structured feedback՝ գրեք ինձ DM → @lianavagyantech

[Mid → Senior] React Ecosystem

Մինչ այս մենք անցնում էինք React Core թեմաների վրայով։ Սակայն React-ը միայն UI library է, և իրական նախագծերում այն միայնակ չի օգտագործվում։

Կան մի շարք կարևոր ուղղություններ և գործիքներ, որոնք կազմում են React ecosystem-ը։

Այն սովորաբար ներառում է.

• TypeScript - type safety, scalable codebase
• State management (օր. Redux) - shared state-ի կառավարում
• Routing (React Router) - էջերի միջև navigation-ի կազմակերպում
• Automated testing - unit / integration tests
• SSR / SSG - performance և SEO optimization
• Building - bundlers, code splitting, production optimizations

💡 Insight։ Interview-ում սովորաբար ստուգում են ոչ միայն React core-ի իմացությունը, այլ թե ինչպես եք կառուցում ամբողջ application-ը՝ end-to-end։

Հաջորդիվ կանդրադառնանք ecosystem-related topic-ներին։ Stay tuned! 🙂

Իսկ եթե ուզում եք փորձել Ձեզ իրական React mock interview-ում և ստանալ structured feedback՝ գրեք ինձ DM → @lianavagyantech

Եթե ուզում եք փորձել Ձեզ իրական React mock interview-ում և ստանալ structured feedback՝ գրեք ինձ DM → @lianavagyantech

[Mid+] TypeScript - any vs unknown

Հարց: Ո՞րն է any-ի և unknown-ի տարբերությունը TypeScript-ում։

Սխալ պատասխան: Դրանք գրեթե նույնն են, պարզապես unknown-ը ավելի «նոր» տարբերակ է։

Ճիշտ պատասխան: any-ն անջատում է type checking-ը, իսկ unknown-ը պահպանում է type safety-ն։

any-ի դեպքում.

let value: any = "hello";

value.toUpperCase(); // ok
value.notExistingMethod(); // ok (սխալը կտեսնենք runtime-ում)

Այսինքն TypeScript-ը չի ստուգում ոչինչ։

unknown-ի դեպքում.

let value: unknown = "hello";

value.toUpperCase(); // error

Error-ից խուսափելու համար անհրաժեշտ է նախ narrow անել type-ը.

if (typeof value === "string") {
 value.toUpperCase(); // ok
}

Ավելի պատկերավոր՝
any → “I don’t care”
unknown → “I don’t know yet”

Շատերը օգտագործում են any, որպեսզի «լռեցնեն» TypeScript-ին, ինչի արդյունքում կորցնում ենք ամբողջ type safety-ն։

💡 Tip: Եթե տվյալը unknown է, պետք է այն narrow անել։ Եթե օգտագործում ենք any, ապա դուրս ենք գալիս type system-ից։

[Mid+] TypeScript - interface vs type

Հարց: Ո՞րն է interface-ի և type-ի տարբերությունը։

Սխալ պատասխան: type-ը interface-ի նոր տարբերակն է, և պետք է միշտ օգտագործել type։

Ճիշտ պատասխան: interface-ը և type-ը մրցակիցներ չեն։ Դրանք ունեն տարբեր use case-եր և տարբեր խնդիրներ են լուծում։

interface
• նախատեսված է object shape նկարագրելու համար • կարող է extend անել • ունի declaration merging

interface User {
  name: string
}

interface User {
  age: number
}

// արդյունքը { name: string; age: number }

type
• ավելի ճկուն է
• կարող է աշխատել union / intersection-ների հետ
• կարող է նկարագրել ոչ միայն object-ներ, այլ նաև primitive-ներ

type ID = string | number;

type User = {
  name: string
} & {
  age: number
}

Կարևոր տարբերություններից է նաև այն, որ class-ը կարող է implements անել.
• interface - միշտ
• type - միայն եթե այն object shape է

type User = { name: string };

class A implements User {
  name = "John"
}


Բայց երբ.


type ID = string | number;

class A implements ID {} // չի աշխատի


💡 Insight: Ընտրությունը կատարում ենք ըստ use case-ի.
• interface - երբ նկարագրում ենք entity / API contract
• type - երբ պետք է flexibility և composition

[Mid+] Generics in React

Հարց: Ինչու՞ են generic-ները կարևոր React-ում։

Սխալ պատասխան: Generic-ները պարզապես type-երը reusable դարձնելու համար են։

Ճիշտ պատասխան: Generic-ները թույլ են տալիս գրել type-safe և reusable component-ներ՝ առանց կորցնելու type information-ը։

Օրինակ՝ reusable List component.

type ListProps<T> = {
  items: T[]
  renderItem: (item: T) => React.ReactNode
}

const List = <T,>({ items, renderItem }: ListProps<T>) => {
  return <div>{items.map(renderItem)}</div>
}

// use
<List
  items={[1, 2, 3]}
  renderItem={(item) => <span>{item}</span>}
/>

Այստեղ item-ը ավտոմատ number է։

Շատերը գրում են reusable component, բայց կորցնում են type-ը.

type Props = {
  items: any[]
}

Սա ամբողջությամբ անջատում է type safety-ն։

Այսպիսով, ինչ են տալիս generic-ները.
• Type inference (ավտոմատ type-եր) • Reusability առանց any-ի • Strong contract-ներ component-ների համար

💡 Insight։ Generic-ները պարզապես syntax չեն։
Դրանք reusable code գրելու միջոց են՝ առանց type information կորցնելու։
Պետք է կարողանալ գրել generic component, որը ճիշտ type inference է ապահովում։

[Mid+] Typing hooks & events

Հարց: Ինչպե՞ս ճիշտ type անել hook-երը և event-ները React-ում։

Սխալ պատասխան: Կարելի է օգտագործել any, կամ TypeScript-ն ինքը կհասկանա։

Ճիշտ պատասխան: TypeScript-ը շատ դեպքերում inference է անում, բայց React-ում կան դեպքեր, որտեղ պետք է հստակ type տալ։

🔹 useState
Պարզ դեպքերում տիպավորման անհրաժեշտություն չկա.

const [count, setCount] = useState(0); // number inferred



Բայց complex դեպքերում.

type User = { 
  name: string 
}

const [user, setUser] = useState<User | null>(null);



🔹 useRef
DOM էլեմենտների ref-ը պահելու դեպքում կարևոր է նշել կոնկրետ type-ը.

const inputRef = useRef<HTMLInputElement>(null);

🔹 Event typing
Շատերը գրում են any.

const handleChange = (e: any) => {}



Սա սխալ է։
Ճիշտ տարբերակը.

const handleChange = (e:React.ChangeEvent<HTMLInputElement>) => {

console.log(e.target.value);

}



🔹 Click event

const handleClick = (e:React.MouseEvent<HTMLButtonElement>) => {}



Այսպիսով, շատերը չեն տարբերակում event type-երը և օգտագործում են any՝ կորցնելով autocomplete-ը և type safety-ն։

💡 Insight։ Event typing-ը պարզապես type գրել չէ։
Դա օգնում է.
• ճիշտ օգտագործել event property-ները
• խուսափել runtime սխալներից
• ունենալ ավելի լավ DX

Օգտակար տեղեկություն

Երբ նոր էի սկսում իմ ճանապարհը IT-ում, ամենաբարդը սովորելը չէր, այլ հասկանալը՝ որտեղից սկսել։
Շատ ինֆորմացիա, շատ ուղղություններ, ու ոչ մի հստակ ճանապարհ։

Հիմա, հետ նայելով, հասկանում եմ, թե որքան կարևոր են ճիշտ կառուցված, սկսնակին հարմար ծրագրերը, հատկապես երբ սկսում ես 0-ից կամ ժամանակդ սահմանափակ է։

Դրա համար ուզում եմ կիսվել մի հնարավորությամբ, որը ինքս կօգտագործեի, եթե նոր սկսեի։

Մենք ունենք EPAM Campus հարթակը, որտեղ հասանելի են անվճար դասընթացներ տարբեր IT ուղղություններով՝ ինքնուրույն ուսուցումից մինչև մենթորի աջակցությամբ training-ներ և internship-եր։

Իմ կարծիքով, սա հատկապես օգտակար է նրանց համար, ովքեր դեռ փորձում են հասկանալ, թե ինչից սկսել։

EPAM-ը փորձում է նաև զարգացնել IT Community-ն ՀՀ մարզերում՝ պահանջված մասնագիտությունները հասանելի դարձնելով նաև Երևանից դուրս։ Այս պահին բաց են անվճար training-ներ Automated Testing և Java ուղղություններով Գյումրիում։

Եթե մտածում եք IT ոլորտ մտնելու մասին, սա կարող է լավ սկիզբ լինել։

Մանրամասները՝
https://epa.ms/free-it

[Mid+] TypeScript - Utility Types

Հարց: Ի՞նչ են utility type-երը և ինչի՞ համար են օգտագործվում։

Սխալ պատասխան: Utility type-երը պարզապես կարճ ձև են type-եր գրելու համար։

Ճիշտ պատասխան: Utility type-երը built-in helper-ներ են, որոնք թույլ են տալիս ձևափոխել արդեն իսկ գոյություն ունեցող type-երը՝ առանց նորից գրելու ամբողջ structure-ը։

Ամենահաճախ օգտագործվողներն են.

🔹 Partial - բոլոր դաշտերը դարձնում է optional

type User = {
  name: string
  age: number
}

type UpdateUser = Partial<User>
// { name?: string; age?: number }



🔹 Required - բոլոր դաշտերը դարձնում է պարտադիր

type UserOptional = {
  name?: string
  age?: number
}

type FullUser = Required<UserOptional>
// { name: string; age: number }



🔹 Pick<T, K> - ընտրում է կոնկրետ դաշտեր

type UserPreview = Pick<User, "name">



🔹 Omit<T, K> - հանում է կոնկրետ դաշտեր

type UserWithoutAge = Omit<User, "age">



🔹 Record<K, T> - ստեղծում է key-value type

type UsersMap = Record<string, User>



Շատերը ձեռքով են կրկնում type-երը՝ utility type-եր օգտագործելու փոխարեն, ինչի արդյունքում ունենում ենք duplicated logic։

Այսպիսով, utility type-երը.
• Կրճատում են boilerplate-ը
• Պահպանում են consistency
• Օգնում են ավելի հեշտ refactoring անել

💡 Insight։ Utility type-երը պարզապես shorthand չեն։
Դրանք օգնում են պահել codebase-ը DRY և scalable։
Պետք է կարողանալ reuse անել type-երը, ոչ թե ամեն անգամ նորից գրել դրանք։

[Mid+] Redux - երբ է պետք օգտագործել և երբ՝ ոչ

Հարց: Ե՞րբ պետք է օգտագործել Redux React project-ում։

Սխալ պատասխան: Redux պետք է օգտագործել այն ժամանակ, երբ ունենք մեծ state։

Ճիշտ պատասխան: Redux պետք է օգտագործել, երբ ունենք complex shared state, որը դժվար է կառավարել component tree-ում։

Որ դեպքերում է Redux-ը լավ ընտրություն.
• state-ը օգտագործվում է շատ տարբեր component-ներում • կա բարդ business logic • state-ը հաճախ է փոփոխվում տարբեր տեղերից • պետք է predictable state flow

Որ դեպքերում Redux-ը պետք չի.
• local UI state (modal, input, toggle) • փոքր կամ միջին complexity ունեցող app • երբ Context + hook-երը բավարար են

Ինչու՞ են մարդիկ սխալ օգտագործում Redux-ը։ Շատերը փորձում են կենտրոնացնել ամբողջ state-ը մեկ տեղում, նույնիսկ այն state-ը, որը պետք է մնա local։ Սա բերում է.
• ավելորդ complexity • boilerplate • դժվար debug

💡 Insight։ Redux-ը լուծում է կոնկրետ խնդիր, ոչ թե default ընտրություն է։ Անհրաժեշտ է իմանալ, թե երբ օգտագործել այն, ոչ թե օգտագործել “just in case”։

[Mid+] Redux - 3 հիմնական սկզբունքները

Հարց: Որո՞նք են Redux-ի 3 հիմնական սկզբունքները։

Ճիշտ պատասխան: Redux-ը կառուցված է 3 հիմնական սկզբունքի վրա, որոնք ապահովում են predictable state management։

1️⃣ Single source of truth
Application-ի ամբողջ state-ը պահվում է մեկ store object-ում։ Սա թույլ է տալիս ունենալ կենտրոնացված տվյալների աղբյուր ամբողջ app-ի համար։

2️⃣ State-ը read-only է
State-ը չենք կարող փոխել directly։ Այն կարելի է փոխել միայն action dispatch անելով, ինչը կանխում է անկանխատեսելի փոփոխությունները։ Action-ը pure JavaScript object է, որի type property-ն բնութագրում է, թե ինչպես պետք է փոխվի state-ը։

3️⃣ State-ի փոփոխությունները կատարվում են reducer-ի միջոցով
Reducer-ը pure function է, որը ստանում է նախորդ state-ը և action-ը ու վերադարձնում նոր state՝ առանց side effect-ների։

💡 Insight։ Redux-ը լուծում է ոչ միայն այն խնդիրը, թե որտեղ պահել state-ը, այլ նաև՝ թե ինչպես կառավարել փոփոխությունները predictably։

[Mid+] Redux - Data normalization

Հարց: Ի՞նչ է normalized state-ը Redux-ում և ինչու՞ է այն կարևոր։

Սխալ պատասխան: Normalization-ը պարզապես data-ն «սիրուն» պահելու ձև է։

Ճիշտ պատասխան:
Normalized state-ը state structure է, որտեղ entity-ները պահվում են flat ձևով՝ id-ներով։

Այսինքն nested data-ի փոխարեն.

posts: [
  {
    id: 1,
    author: {
      id: 10,
      name: "Liana"
    }
  }
]


պահում ենք.

posts: {
  byId: {
    1: { id: 1, authorId: 10 }
  },
  allIds: [1]
}

users: {
  byId: {
    10: { id: 10, name: "Liana" }
  }
}



Ի՞նչ խնդիր է սա լուծում։

Nested state-ի դեպքում.
• առաջանում է data duplication
• update-ները դառնում են բարդ
• immutability պահելը դժվարանում է

Normalized state-ը ապահովում է.
• single source of truth
• ավելի հեշտ update-ներ
• predictable state structure
• ավելի քիչ unnecessary re-render-ներ

💡 Insight։ Շատերը կարծում են, որ normalization-ը պետք է միայն մեծ app-երում։ Իրականում այն պետք է այնտեղ, որտեղ entity-ները reuse են լինում տարբեր տեղերում։
Redux-ում state structure-ը նույնքան կարևոր է, ինչքան reducer logic-ը, և վատ structure-ը ժամանակի ընթացքում ավելի մեծ խնդիր է դառնում, քան վատ reducer-ը։

Եթե ուզում եք փորձել Ձեզ իրական React mock interview-ում և ստանալ structured feedback՝ գրեք ինձ DM → @lianavagyantech