Рэгулюванне стаўака UI у рэальным свете за дапамой умовнага атрыбута rendering у React
Выучыце, як ствараць інтэрфейсы аутантыкаціі, ролей, праваў, заваношчання дадзеных, адзначэння памылак і стану «пусто» ў React за дапамой практычных шаблонаў умовнага атрыбутавання.
У пакуальнай частцы вы розглянулі асновы умовайго атрыбутавання — выкарыстоўванне простых умов, каб падказаць React, чы рэштаціяваць адну складовую, іншую складовую чы нічога.
Аднак у рэальных застосоўаннях рэдка калі все застаецца такім простым:
isLoggedIn ? <Dashboard /> : <Login />
Разглянем рэальную панель керування. Пользователь можа знаходзіцца ў будзь-ям з наступных станоў:
- Выйшаў з акаунта
- У процесе входу
- Увійшаў у акаунт
- Адміністратар
- Звычайны корыстувач
- Няма неабходных прав
- Чакае на падачу даных
- Спрабоўвае рашыць проблему з API
- Адзірвае порожнюю сумку рэзультатаў
Кожны з гэтых сценарыяў выкалікае патрэбную інтэрфейсную архітектуру. Самэ гэтая ситуацыя прыводзіць да таго, што умовайга атрыбутавання перастае быць простым трюкам і стае справжнім інструментам для структуравання вашага застосоўання.
Пазірмо, як гэта выглядае ў кодзе React прыметнага рангу.
1. Адаптаванне на адміністрацыю на аснове аутантыкацыі
Класычны прыклад — аутантыкацыя. Уявіце прыклад дапрыгу, якай мае два можлівыя экраны:
Not Logged In
↓
Login Page
Logged In
↓
Dashboard
React можа легка выбраць адны з іх:
function App() {
const isLoggedIn = true;
return (
<>
{isLoggedIn ? <Dashboard /> : <Login />}
</>
);
}
Аднак у рэальных дапрыгах зазвычай патрэбны трэці стан: loading, каліжо дапрыг можа знадобіцца час, каб парадактуваць, чы рэштыткі пользователя ўважаюцца валіднымі. Тады прабег будзе такім:
Checking Authentication
↓
Loading
↓
Authenticated?
↙ ↘
YES NO
↓ ↓
Dashboard Login
У коде гэта можа выглядаць так:
function App() {
const isLoading = false;
const isLoggedIn = true;
if (isLoading) {
return <LoadingSpinner />;
}
return isLoggedIn
? <Dashboard />
: <Login />;
}
Вы пабачыце, як гэты точны шаблон павтараецца ў бесчыслах прыкладоў дапрыгаў на React у рэальных умовах.
2. Адаптаванне на адміністрацыю на аснове ролей
Аутантыкацыя паведамляе вас, хто ўвійшаў у систему. Автарызацыя паведамляе вас, што гэты чалавек можа робіць.
Вярнімся да прыклада інструменту для керавання співрабоцамі. Адміністратар можа бачыць:
View Employees
Add Employee
Edit Employee
Delete Employee
Тады як звычны корыстнік бачыць толькі:
View Employees
Можна умовна адаптаваць паказанне дзеянняў залежна ад ролі пользователя:
function EmployeeCard({ userRole }) {
return (
<div>
<h2>Employee Details</h2>
<button>View</button>
{userRole === "admin" && (
<>
<button>Edit</button>
<button>Delete</button>
</>
)}
</div>
);
}
З такой настройкай элементы керування, доступныя толькі адміністратарам, паказваюцца толькі для адміністратароў.
Важліва прыметка па абяцеце
Умовная візуалізацыя керуе тым, што паказваецца ў Інтерфейсе, але схованне элемента з візуальнага простору не є заменай рэальной абяцеці. Напрыклад:
{isAdmin && <DeleteButton />}
Это не дозволяе звычнаму пользователям бачыць кнопку, але сервер все рава должен самастоятельна паказаць, чы рошчапка дзейсна надходзіць ад чалавека, уповнаменаванага на выдаленне дадзэнняў. Розглядзіце це так:
Frontend
↓
Controls what users SEE
Backend
↓
Controls what users CAN DO
Ніколы не вважайце умовную візуалізацыю на стороне кліента сваім механізамам уповнаменавання.
3. Інтерфейс, заснованы на правах
Большыя прыкладнікі часта патрабуюць большай дзеярганізаванасці, чым простыя ролі, такія як:
Admin
User
У замену можна визначыць конкрэтныя права, такія як:
CAN_VIEW_USERS
CAN_EDIT_USERS
CAN_DELETE_USERS
CAN_EXPORT_REPORT
Компаненты можаць тады аддзейсаваць кожную дзеянне окалічна, на адказ да наяўных праваў:
function UserActions({ permissions }) {
return (
<>
{permissions.includes("CAN_EDIT_USERS") && (
<button>Edit</button>
)}
{permissions.includes("CAN_DELETE_USERS") && (
<button>Delete</button>
)}
</>
);
}
Такі падход дае вам набліжна болей тачны кантроль над тым, што можа рабіць кожны пользователя.
4. Станы заваношчання
Падазрóўце, што панель керування адправляе запыт да API, які трэба выкарыстоўваць два секунды, каб ён быў адпаведзены. Што павінна з’явіцца на экране ў гэты перыяд? З абавязку не порожняя стораніца — вам трэба індыкатор заваношчання:
if (loading) {
return <p>Loading products...</p>;
}
Загальны прайсэп выглядае так:
API Request
↓
Loading = true
↓
Show Loader
↓
API Response
↓
Loading = false
↓
Show Content
Індыкаторы заваношчання дапамагаюць зробіць прыстранне чутлівым нават тады, калі сеть медленная.
5. Індыкаторы-скелеты
У працоўку з звычным тэкстовым паведамленнем, напрыклад:
Loading...
багаты савэцкія інтэрфейсы паказваюць месца для замены, якое выглядае як контэнт, які зараз заваношваецца — індыкатор-скелет. Напрыклад:
┌──────────────────────┐
│ █████████████ │
│ ███████ │
│ █████████████████ │
└──────────────────────┘
Калі справжні даныя вяртаюцца, яны заменяюць местачык:
┌──────────────────────┐
│ MacBook Air │
│ ₹99,999 │
│ ⭐⭐⭐⭐⭐ │
└──────────────────────┘
Асновная логіка React застаецца такой жа простай:
return loading
? <ProductSkeleton />
: <ProductCard />;
Едынныя справжнія разлікі тут — гэта павышэнне якасці корыстніка.
6. Станы адзінакоў
Зв’язкі з API не завжды праходзяць гладка.
Зв’язак можа з’явіцца перерваным.
Сэрвер можа зламацца.
Запыт можа выйсці за часовы ліміт.
У замест на тое, каб ваша аплікацыя зламалася чы ўпэўнілася, трэба адобразіць стан адзінакоў.
if (error) {
return (
<div>
<h2>Something went wrong.</h2>
<button>Try Again</button>
</div>
);
}
Адпаведнае адрабатванне неудач — гэта атрыбут UI высокай якасці.
7. Завантажэнне + Адзінак + Успех
У практыцы гэтыя тры станы практычна завжды показуюцца разам.
function ProductList({
loading,
error,
products
}) {
if (loading) {
return <p>Loading...</p>;
}
if (error) {
return <p>Something went wrong.</p>;
}
return <Products products={products} />;
}
Вы можете уявіць прайом так:
Request
│
├── Loading → Loader
│
├── Failed → Error
│
└── Success → Data
Калі вы дасягнете до вызоў API і useEffect пазней у гэтай серыі, вы будете бачыць, як гэты самы шаблон з’яўляецца знова і знова.
8. Станы без данных
Тое, што запит успехаў, не гарантуе, што існуюць рэальныя даны для адображэння.
Спадзеймося, ўжо корыстувач шукае ўсё такое:
"React Quantum Pizza Developer"
Сам вызов API завершаецца без жадных адхылэнняў.
Але рэзультат можа выглядаць так:
products.length === 0
У замест на тое, каб заставіць экран порожнім, дайце корыстувачу ўсё-такі штось значныя для перагляду.
if (products.length === 0) {
return (
<div>
<h2>No Products Found</h2>
<p>Try changing your search.</p>
</div>
);
}
Станы без данных маюць вельмі важлівую ролю для якіснага корыстувацкага досвяду.
Завантажэнне, порожні стан і адхылення
Новыя разработчыкі React часта плутаюць гэтыя тры станы, але яны практычна выражаюць розныя ситуацыі.
LOADING
Data hasn't arrived yet.
EMPTY
Data arrived, but nothing exists.
ERROR
Something failed.
Хорашая аплікацыя розглядае ўсе тры станы окрема.
9. Калькольныя умовы
Інодзе тое, што вы выраховваеце, залежыць не толькі ад адной умовы, але і ад кантэйнуемых яе умоў.
Разглядзім такі прабег:
Is User Logged In?
↓
Is Subscription Active?
↓
Is User Admin?
↓
Show Admin Dashboard
Хочацца запхнуць усё гэта ў адну вялічыню-вкладаную тэрнарную умову:
condition1
? condition2
? condition3
? <A />
: <B />
: <C />
: <D />
Ёй легка скомпіляваць.
Але яе вельмі складна чытаць.
Кращы падход — чыста раздзеліць кожную умову.
if (!isLoggedIn) {
return <Login />;
}
if (!hasSubscription) {
return <UpgradePlan />;
}
if (isAdmin) {
return <AdminDashboard />;
}
return <UserDashboard />;
Эта версія значна простейшая для разумення.
10. Умовы-захаванні
Шаблон, які вы ўжо бачылі, мае назву: умовы-захаванні, таксама вядомыя як раннія вырахунакі.
У замест на вкладанне умоў ўнутрь умоў і ўнутрь яшчэ адной умовы:
if
└── if
└── if
└── UI
Спачатку разбірацца з крайнімі случаямі і рана вяртацца.
if (loading) return <Loader />;
if (error) return <ErrorPage />;
if (!user) return <Login />;
return <Dashboard />;
Рэзультат чысты.
Ёго легка чытаць.
І яго набагато проста дыбагаваць.
Думайце як разработчык React
Перш чым пісаць компонент, корисна запытаць ся:
«Каліясць можлівых станоў, у якіх можа знаходзіцца гэты экран?»
Для сторанцы, якая працуе на адказ API, гэты список можа выглядаць так:
Loading
Error
Empty
Success
Для процеса аутантыкаціі ён можа выглядаць так:
Logged Out
Checking Authentication
Logged In
Unauthorized
Планаванне гэтых станоў прычынам пачатку напісання коду робіць ствараны компонент набліжэй зрозумелым.
Паўзлівыя памылкі новачакоў
Накупленне вялікай колькасці вярстакавых умов
Не жертвуйце чытаемасцю толькі каб заўсёды захаваць калькі ліній коду.
Ігнораванне стана «пусто»
API, які вяртае пусты массив, — гэта не тое ж самае, што адказ пра аберанне; трэба ставіцца да гэтага як да окремага казу.
Плутанне сховвання UI з рэальным захавам
Сховванне чаго-небудзь такога:
<DeleteButton />
нічага не робіць, каб запярэчыць можласці каго-небудзь безпаснаўска прабавіцца да вашага канцэнтра API.
Рэальная автарызація павінна выконваліцца на бэкендзе.
Дазволаець && адразу вывести неправильны кантэнт
Зважайце на такі фрагменты коду:
{items.length && <ProductList />}
Якщо items.length доравае 0, React можа вывести:
0
самэ гэта на старонцы.
Безпечнейшая версія — гэта:
{items.length > 0 && <ProductList />}
Тепер умова вырахоўваецца як справжнія логічны значэнне.
Аптальнейшыя практыкі
У умовнай відрасці кантэнту чытаемасць завжды павінна быць на першай пазухе.
Вярніце прыоритэт такім патэранам:
if (loading) return <Loader />;
замест таго, каб складваць множлівыя умовы ў глыбокаяросткаваных JSX-структурах.
Для стаў, якія выводзяцца часта, перакладзіце іх у самостойныя компоненты, якія можна перывартаць:
<Loader />
<ErrorMessage />
<EmptyState />
Калі компоненты становяцца болей складнымі, аддзельнайце логіку бізнесу ад таго, што фактычна выводзіцца.
І не праектавайце толькі для оптымалнага сцэнарыю — планавайце кожны стан, у якім UI можа апынуцца на практыцы.
Міні-праект: Розумны панель керування
Як практыка, спробуйце стварыць панель керування, яка будзе врачаць такія ситуацыі:
User Not Logged In
↓
Login ScreenUser
Logged In
↓
Loading Dashboard
↓
┌──────┴──────┐
Error Success
↓ ↓
Error UI Data Exists?
↙ ↘
YES NO
↓ ↓
Dashboard Empty State
Потым дадзіце можлівасць роботы на адміністратывных ролях:
Admin
↓
Edit + Delete
User
↓
View Only
Такі праект адночасна выкарыстоўвае калькі концэпцый:
- Prop’ы
- Стан
- Падзеі
- Умовна адрасаванне
Самэ так, калі вы ствараеце рэальны продукт, адзінкавыя элементы React пачынаюць сумесна працаваць.
Запытанні пад час адзінкавання
Што такое умовна адрасаванне?
Это практыка адрасавання разных элементаў інтэрфейсу залежна ад текущага стану чы ўмов у вашай працоўнай супэрфісе.
У чым разлік межу && і тэрнарыянным выразам?
Іспользуйце &&, калі хочаце, каб элемент адразу быў атрыбутаваны толькі ў правядзячым стане, а іншыя варыянты не паказваліся. Іспользуйце тэрнары, калі патрабуецца разны выхід для правядзячага і неправядзячага станоў.
Шта лічыцца як порожні стан?
Это інтерфейс, які паказваецца, калі запит успехуе, але проста няма дадзеных для адображэння.
Чы хадзячая адгэнтнае адрасаванне дастаточна для безпекі?
Ня. Это толькі зручнасць інтерфейса — практычныя перакананні пра правыяхі все рава трэба выконваць на бэкенде.
Якая ўмяроць ранніх вяртанняў?
Яны зменшаюць колькасць вярстакоў, што спрабляе зробіць умовныя компаненты простэйшымі для чытання і адтульнення.
Ключовыя выводы
На гэты момент вы розглянулі весь спектр умовнай адрасаванне ў React.
Вы вже бачылі, як рэальныя дапрацоўкі справляюцца з варыянтамі з інсаляцыяй та без яе, абмежваючы доступ да экранаў па ролі, адкрываючы функцыяны толькі з паводлів дзеярых разрэшэнняў, паказваючы індыкаторы загрузкі дадзеных, выкарыстоўваючы шаблонныя элементы заместо звычайнага тэксту, адображаючы паведамленні пра аберанняя, калі запыты не выйшлі, падаючы месажы корыстнікам, калі набор рэзультатаў пусты, спаўнюючы калькольнае вырашэнне за дапамогою кількох умов у адны цэлеспрабавны лянцюг, спрасцаваючы вялікія калектары пераканальненняў за дапамогою клазаў-захоўнікаў, а таксама застосоўваючы шырэйшыя прыемы, якія дапамагаюць падтрымваць такую логіку ў рэальным кодбазе.
Умовнае адображэнне — гэта тое, што дазволяе вашай дапрацоўке паказаць той самы досвід, які ўзможліваны для данай ситуацыі.
Але ўперадзі яшчэ адна задача.
Пазначым, што API вяртае:
1,000 Products
Чы справды вы бы пісалі:
<Product />
<Product />
<Product />
...
тысячу разоў аднарозова?
Звычайна, што ні.
У React є набагато лепшы спосаб працавання з гэтым.
У Частцы 9A вы дазнаецеся, як адражаць спісы за дапамою map(), і пазірэце, як адна компанента можа стварыць сотні чыста тыячы элементаў UI працэсу з вашых дадзенняў.
Адразу пасля гэтага вы разбератеся з адным з найкласычнейшых запитанняў пад час адбору на работу ў React:
Чаму React выкалікае наявнасць
key?
Бачымся у Частцы 9A — Адражэнне спісаў і ключоў у React.
Супаўзяныя матэрыялы
- React 19.2 Explained: Activity, useEffectEvent, and Static Rendering — Дазнаецеся, як новы компонент Activity, хук useEffectEvent і часткова статычнае адражэнне у React 19.2 выправляюць скрытыя витраты на працэс у сучасных інтерфейсах.