Какво трябва да има професионалният фронтенд и как да го структурирате

Фронтендът не е „красивата част“

За потребителя на вашата компания фронтендът е продуктът: именно там се печели или губи офертата, регистрацията или плащането. И въпреки това е една от най-малко одитираните части. Една система може да има безупречен бекенд и фронтенд, който никой не може да поддържа, който не се чете добре на телефон, който Google не разбира или който се чупи всеки път, когато марката се промени.

Това е списъкът с това, което според нас един професионален фронтенд трябва да има, и защо. Не е рецепта: това е, което си струва да поискате от екипа си или от доставчика си, и как да познаете дали го има.

1. Компоненти с посока, а не папка с „неща“

Професионалният интерфейс се изгражда от малки, преизползваеми части. Самата документация на React го казва така: компонентът в идеалния случай трябва да се грижи за едно-единствено нещо, а ако порасне, се разделя на подкомпоненти.

Полезен речник е този на Atomic Design (Brad Frost): атоми (бутон, поле), молекули (поле със своя етикет и своята грешка) и организми (заглавна част, цял формуляр). Разширяваме го със секции и страници, когато помага да се управлява продуктът. Това е конвенция, не закон. Стойността ѝ идва от едно-единствено правило: зависимостта тече в една посока. Основната част не познава продуктовите части, които я използват.

И още една дисциплина, която спестява много разходи: да се абстрахира късно. Един модел става споделен компонент, когато вече се е повторил и вариантите му са се установили; абстрахирането по-рано често струва повече от едно видимо дублиране.

Знаете ли днес кои екрани се променят, ако утре се смени основният цвят на вашата марка?

2. Дизайн система с токени

Токенът за дизайн е, според определението на групата, която работи по неговия формат, информация с четливо име: като минимум двойка име и стойност (например цветът на основния текст). Принципът е прост: цветът, типографията и разстоянията не се пишат в компонента, а се вземат от токен. Смяната на марката се свежда до смяна на една стойност, а не до редактиране на всеки екран.

Честно уточнение: стандартният формат за токени на Design Tokens Community Group все още е чернова и в собствения си текст моли да не се прилага засега. Токените могат да се определят още днес във вашата система и да се експортират, когато стандартът се установи.

3. Storybook и какво се предава с него

Компонент без документация е труден за правилно използване от този, който не го е писал. Storybook позволява всеки компонент да се изгражда и преглежда изолирано, с неговите варианти и трудно достижими случаи, и служи като документация, генерирана от самите истории (функцията за автоматично документиране го прави от метаданните на компонента), така че остава близо до кода; все пак тя струва колкото струват историите: те трябва да отразяват реалната употреба. За една компания важното е какво получава: каталог за разглеждане, който дизайнът, QA и бизнесът могат да отворят, а не снимка на екрана в чат.

Как да се организира, за да служи като договор – с йерархия, състояния и прегледи – обясняваме отделно: Как да структурираме Storybook, който служи като договор. Тук само изискването: каталог, който зависи от това някой да си спомни да го публикува, остарява; публикувайте го автоматично при одобряване на промените.

4. Тестове на три нива и защо едно не е достатъчно

• Модулни и компонентни (с Jest или съвременния му еквивалент), които проверяват логиката и видимото поведение.
• От край до край (например с Playwright), които обхождат потоците, които плащат сметките: регистрацията, офертата, плащането. Ръководството му за добри практики препоръчва да се тества това, което потребителят вижда, а не вътрешните подробности, и всеки тест да е изолиран от останалите.
• Достъпност и визуална регресия. Сравняването на снимки помага да се открие промяна, която никой не е отварял, макар че документацията на Playwright предупреждава, че изобразяването варира според операционната система, браузъра и хардуера, и затова еталоните трябва да се генерират в същата среда, в която се сравняват.

За достъпността – едно ограничение, което е добре да се каже на глас: според документацията на Playwright автоматичните тестове откриват някои често срещани проблеми, но много от тях се откриват само с ръчен преглед. Автоматизирайте каквото може и запазете човешкия преглед, с клавиатура и екранен четец, за критичните потоци.

Нивото, което си струва да се изисква, е WCAG 2.2 AA. Два конкретни примера от стандарта: текстът трябва да има контраст най-малко 4,5:1 (3:1 за едър текст), а елементите, които се докосват или натискат, трябва да са най-малко 24 на 24 CSS пиксела, с някои изключения.

Колко от вашите критични потоци имат тест, който се изпълнява сам при всяка промяна?

5. CI/CD на фронтенда: това, което трябва да може да се спре

Конвейерът на един фронтенд е начинът качеството да не зависи от добрата воля на когото и да било. Като минимум трябва да проверява стил, типове, тестове и изграждане, и да преглежда зависимостите с известни уязвимости (npm audit изпраща описанието на зависимостите до регистъра и връща отчет за известни уязвимости; това е полезен контрол, но сам по себе си не е достатъчен анализ на сигурността). Всяка стъпка може да спре пускането; подробностите как се изгражда път на пускане са в Да пускате без страх във вашата собствена инфраструктура.

За анализа на качеството – какво трябва да изпълнява. Стандартната врата за качество на SonarQube Server, „Sonar way“ (според актуалната му документация; това е конфигурация на един продукт, а не универсално определение за качество), поставя четири условия върху новия код: без нови проблеми, прегледани критични точки по сигурността, покритие най-малко 80 % и дублиране 3 % или по-малко. Ценна е философията: не става дума да се поправи всичко старо, а да не се добавя нов дълг. И един нюанс, който ни е важен: изключена врата или такава, която не се изпълнява, не е същото като такава, която минава. Изисквайте да видите изпълнението, а не само цвета на таблото.

6. SEO и четене от ИИ: съдържание, което може да се обхожда и проверява

Ако вашият сайт е публичен, важното му съдържание трябва да е достъпно за търсачката и, когато е уместно, за асистентите с ИИ. Това трябва да се проверява върху HTML, който реално се доставя и изобразява, а не да се предполага. Google препоръчва уникални и описателни заглавия и собствени описания за всяка страница и предупреждава, че ако важното съдържание е скрито зад JavaScript, може да не бъде разбрано. Ръководството на web.dev за стратегиите за изобразяване обяснява компромиса: статичното изобразяване при изграждането дава най-добро време за отговор, но се мащабира зле при много уникални URL адреси; изобразяването от страна на клиента изисква да се следи теглото на JavaScript.

Върху тази основа – три практики: структурирани данни в JSON-LD (форматът, който Google препоръчва като най-лесен за поддържане в голям мащаб), един каноничен адрес на страница, за да се избягват дубликати, и, ако има няколко езика, указване на алтернативните версии по език (това са два различни механизма). И едно предложение, llms.txt, което предлага на агентите резюме на сайта в Markdown. Не е официален стандарт: това е отворено предложение на общността, а различните агенти с ИИ се държат по различен начин, така че няма универсално изискване като това към търсачките. Най-доброто условие е тези проверки да са част от изграждането, а не списък, за който някой се сеща накрая.

7. Производителност: измерва се с това, което преживява потребителят

Google определя три сигнала за потребителското изживяване, оценявани на 75-ия персентил от зарежданията на страници и разделени между мобилни устройства и компютри. Измерват се с реалната употреба на вашите потребители; тест на една-единствена машина дава ориентир, но не замества това измерване:

• LCP (колко бързо се появява основното съдържание): 2,5 секунди или по-малко.
• INP (колко бързо отговаря на докосване или натискане на клавиш): 200 милисекунди или по-малко.
• CLS (колко се премества съдържанието, докато се зарежда): 0,1 или по-малко.

Две инженерни идеи стоят зад тези стойности. Първата: да не се зарежда от самото начало това, което не се използва от самото начало. React позволява кодът да се разделя и компонентът да се зарежда само когато е нужен.

// Илюстративно, взето от документацията на React (lazy + Suspense).
const VistaPrevia = lazy(() => import('./VistaPrevia.js'));

<Suspense fallback={<Cargando />}>
  <VistaPrevia />
</Suspense>

Втората: тази идея да не се прилага към това, което потребителят вижда първо. Според web.dev изображението – кандидат за LCP, никога не бива да се зарежда отложено, защото се забавя точно това, което измерва този сигнал.

8. Сигурност: браузърът е враждебна територия

Всичко, което стига до браузъра, е публично; никаква тайна не живее там. Две основни идеи:

• XSS. React по подразбиране екранира това, което изобразява, но предлага изход за заобикаляне, dangerouslySetInnerHTML, който собствената му документация нарича опасен: със съдържание, на което не може да се има доверие, е тривиално да се внесе уязвимост. OWASP препоръчва почистване със специализирана библиотека и предупреждава, че никоя техника сама не предотвратява XSS.
• Защита в дълбочина. Политиката за сигурност на съдържанието (CSP) ограничава какво може да прави кодът на страницата (откъде зарежда ресурси и към какво се свързва, наред с други неща) и помага срещу XSS и clickjacking. MDN е ясна: тя не замества почистването; използва се освен него.

И едно просто правило за преценка: не оставяйте в браузъра, четими от всеки скрипт, удостоверения за многократна употреба или чувствителни данни. И не забравяйте, че проверката от страна на клиента никога не замества тази на сървъра: разрешението за достъп винаги се решава от страна на сървъра.

9. След пускането: устойчивост и наблюдаемост

Професионалният фронтенд предполага, че нещо ще се провали. Всяко извикване на услуга има състояния на зареждане, празно, грешка и повторен опит, а провалът се показва, не се крие зад бял екран. И някой трябва да научи за грешката, преди клиентът да я съобщи: грешки на браузъра, уловени с минимален контекст и без лични данни, и сигналите за производителност от раздел 7, следени с реални потребители. Ако сайтът зарежда етикети за анализ или от трети страни, те също са код: тежат върху производителността и трябва да са в рамките на бюджета.

Добре е също да се уговори какво се поддържа: браузъри, скромни устройства и бавни мрежи. И една дизайн система, накрая, се нуждае от отговорник, версии и начин да се изтеглят компоненти, без да се счупи този, който ги използва.

Какви доказателства да поискате, преди да одобрите

За един комитет фронтендът се одобрява с доказателства, а не с демонстрация. Поискайте: публикувания каталог с компоненти; отчета от тестовете на последното пускане, с брой, прочетен от обобщението; резултата от вратата за качество с условието, което е паднало, ако е падало; прегледа на достъпността с ръчната му част; сигналите за производителност с реални данни; и кой разрешава изключение и как то се записва.

Какво почти всеки екип отлага

Две неща: тестовете от край до край на всички критични потоци и провал в достъпността да спира публикуването, вместо само да предупреждава. Контрол, който не може да спре една промяна, е препоръка. Казваме го, защото отричането не го оправя и защото точно това си струва да се попита всеки екип, включително вашия.

Заключение

Професионалният фронтенд не се познава по външния си вид в деня на премиерата, а по това, което издържа след това: смяна на марка, одитор, скромен телефон, търсачка, нападател. Когато това се провали, цената не е техническа: това са изгубени продажби, преработка и одит, който трудно се преминава. В Hábil сме експерти в това. Изграждаме фронтенда на вашия продукт с управлявани компоненти, дизайн система, тестове, достъпност, производителност и сигурност, преглеждани при всяка промяна, и можем да започнем, като сравним приоритетния ви дигитален път с този списък.