Фото: Ryan Quintal на Unsplash
Пам’ятаєте відчуття, коли в дитинстві відкривали новий набір LEGO? Це хвилювання, зрозумілі інструкції, задоволення від того, як ідеально скріплюються частини. А тепер згадайте ваш останній код-рев’ю «гнучкого» корпоративного компонента. Не зовсім те саме, чи не так?
Після багатьох років спостережень за тим, як розробники (включаючи мене) боролися з надмірно складними рішеннями, я зрозумів, що найкращі архітектури React мають більше спільного з LEGO, ніж із складними механізмами, які ми часом намагаємося створити.
Принцип LEGO: прості частини, безмежні можливості
Фото: HONG LIN на Unsplash
Чого моя 5-річна донька навчила мене про дизайн API
Минулого тижня я спостерігав, як моя донька грається своїм набором LEGO. «Сьогодні ми будуємо парк для собак!» – захоплено заявила вона. Без жодної документації чи «старшого LEGO-архітектора», вона створила гірки, пісочниці, водну зону, місця для годування та ігрові зони для собак. Наступного дня? «Давай зробимо автомобілі!» І ось так весь парк для собак перетворився на автопарк із транспортними засобами.
Це дуже мене вразило. Ось моя 5-річна донька інтуїтивно розуміє те, що ми часто надмірно ускладнюємо у розробці програмного забезпечення: маючи правильні будівельні блоки, можна створити що завгодно, трансформувати все і перебудовувати без страху. Кожна деталь LEGO мала чітку мету, з’єднувалася очевидними способами і працювала надійно кожного разу.
Тим часом, на роботі, у нас був «гнучкий» компонент, який виглядав ось так:
// «Корпоративно готовий, гнучкий» підхід
const EnterpriseDataComponent = ({
data,
configurationMatrix,
transformationPipeline,
errorBoundaryStrategy,
optimizationHeuristics,
// … ще 20 страшних пропсів
{
useEffect(() => {
// 100 рядків логіки налаштування
залежностей, довший за мій список замовлень кави */]);
return (
// JSX, який змусив би старшого розробника заплакати
);
ось у нашому підході було дуже не так.
Посібник майстра LEGO для React
Фото: Glen Carrie на Unsplash
1. Почніть із ідеальних цеглинок
// Базова цеглинка LEGO – виконує одну річ досконало
const Button = => (
<button </button>
);
// Трохи більш спеціалізована цеглинка
const ConfirmButton = (props) => (
<Button```
### 2. Будуйте великі речі з простих частин
```javascript
// Комбінування цеглинок у щось корисне
const ConfirmationDialog = () => {
const { confirm,
return (
<div>
<p>Ви впевнені?</p>
<button onClick>
<button onClick={>
</div>
);
### 3. Ховайте складну логіку
```javascript
// Складна логіка присутня, але прихована
const useDialog = {
// Рівень 1: Простий сценарій (90% розробників використовують лише це)
const simplePath = {
confirm: () => handleConfirm(),
cancel: () => handleCancelівень 2: Розширені можливості (9% випадків)
if (options.
### Розширені можливості
```javascript
// Рівень 2: Розширені можливості (9% випадків)
if (options.advanced) {
return {
...simplePath,
onBeforeConfirm: handlePreConfirm,ень 3: Вихід для експертів (1% «суперкористувачів»)
if (options._superPowers) {
return {
...simplePath,
_internal: internalAPIs,
_context: Система дизайну: ваш набір майстра LEGO
Уявіть свою систему дизайну _не як набір компонентів_, а як _набір майстра LEGO_. Кожен елемент має бути:
_Фото: Eric & Niklas на Unsplash_
### Миттєво зрозумілим
```javascript
// Будь-хто може це зрозуміти
const Card = => (
<div className="card">
{title &&
</div>
);
Прогнозовано поєднуваним
// Елементи, які природно працюють разом
const ProductCard = ({ <Card title={product.namep>
<>
<Button onClick={product.addTo до кошика</Button>
</Card>
);
Безпечно розширюваним
// Старші розробники можуть додавати функціональність, не порушуючи простоти
const withAnalytics = (WrappedComponent) => {
return function EnhancedComponent(props) {
useAnalytics(props.analyticsEvent); // використання аналітики
return <WrappedComponent {... ще просто у використанні
const TrackableButton = withAnalytics(Button);
Перевага безпеки: менше точок входу, кращий контроль
Фото: Yulia Matvienko на Unsplash
Коли ви створюєте добре визначені «цеглинки LEGO», безпеку стає легше контролювати:
// Одна безпечна реалізація, яка використовується скрізь
const SecureButton = ({ onClick {
= useAuth(); // перевірка дозволів (Permissions)
const handleClick = () => {
if (validatePermissions()) {
onClick();
return <button on Розробники не можуть випадково обійти безпеку
const DeleteButton = () => (
<SecureButton onClick={() => console.log('Deleting...') Видалити
</SecureButton>
);
Неочікувані переваги
Після впровадження цих принципів ми виявили кілька несподіваних переваг:
Молодші розробники стали продуктивними швидше
— «Це просто зрозуміло» – так звучав частий відгук
— Менше часу на читання документації, більше часу на створення
Старші розробники легше оптимізували код
— Чіткі межі дозволяли ізолювати поліпшення продуктивності
— Було легше додавати складні функції без впливу на базове використання
Код-рев’ю стали обговореннями бізнес-логіки
— Замість «Чому це таке складне?»
— Ми чули «Це саме те, що нам потрібно»
Документація писалася майже сама
— Коли ваші API інтуїтивно зрозумілі, документації потрібно менше
— Те, що ви все ж пишете, зосереджене на складних сценаріях
Мудрість майстра-будівельника
Пам’ятайте:
1. Якщо ваші компоненти потребують ступеня доктора наук для розуміння, ви щось робите не так
2. Складні функції мають бути вибірковими (opt-in), а не обов’язковими (opt-out)
3. Найкращий код – це код, який не потрібно пояснювати
4. Створюйте для більшості, розширюйте для меншості
Дивлячись у майбутнє
Фото: Ravi Palwe на Unsplash
Майбутнє розробки на React – це не про те, хто може створити найскладнішу систему.
Йдеться про те, щоб зробити складні системи зрозумілими. Так, як LEGO робить це вже поколіннями.
Наступного разу, коли ви проєктуєте компонент чи систему, запитайте себе: «Чи міг би 5-річна дитина зрозуміти, як ці частини поєднуються?» (Добре, можливо, не сам код, але модель у вашій голові має бути настільки чіткою.)
— -
Як ви робите свої React-компоненти простими, але потужними? Поділіться своєю LEGO-мудрістю у коментарях нижче!
Перекладено з: LEGO Lessons in React: When My 5-Year-Old Made Me Rethink Component Design