А ну давайте маленький тестик

Як ви знаєте, в #React функціональні компоненти рендеряться заново, в тому числі, коли рендериться їх батьківський компонент (якщо не використовувати React.memo)

Тепер власне тест:

Маємо звичайний, майже класичний React counter:

function Counter({ children }) {
  const [c, setCounter] = useState(0);
  const increment = () => setCounter(c + 1);
  return (
    <button onClick={increment}>
      {children} {c}
    </button>
  );
}

Єдиний нюанс з ним - він приймає в пропс children, який відмальовує всередині. В середину ми передаємо отакий примітивний компонент:

function ClickMeText() {
  console.log('ClickMeText rendered');
  return <>Clicked: </>;
}

Цей компонент - просто текст, який також містить консоль лог, щоб ми бачили коли він рендериться. В цілому виглядає це так:

const App = () => <Counter>
  <ClickMeText />
</Counter>

Тепер питання: Я запустив сторінку та ТРИЧІ клікнув на каунтер. Скільки ClickMeText rendered я побачу в консолі, за умови що strict mode вимкнено?

1 раз - ставимо ❤️
3 рази - 👍
4 рази - 🔥

З вас смайлики, з мене пояснення)

Друзі, запускаю в пілотному режимі (два тижні) календлі

Якщо вам потрібна порада з #React, або #FrontEnd, або розробкою в цілому - букайте таймслот (понеділок, четвер з 9 по 10 годину)

Також приймаю побажання щодо часу, але не обіцяю що виконаю)). Ну і оскільки це пілот - то буду дуже вдячний за відгуки.

Як проведемо, буду бачити що далі.

Прохання підтримати пост і обов'язково приходьте сьогодні, о 19:00.

Буде і цікаво і корисно.

ПМ (міг - впади!)

@reactbeginners

Я вивчив #React і що далі?

React це лише бібліотека для відображення, його одного для повноцінної роботи не достатньо.

Вам також знадобляться:

1. UI бібліотека, щоб зекономити на розробці власних компонентів та вберегтися від багів. Ви не хочете писати модалку або data grid самому. Популярні UI бібліотеки MUI (3.7M*), AntDesign (1.3M), ReactBootstrap (1.6М)

2. Стейт менеджер, щоб спростити роботу з даними. Найпопулярніший Redux Toolkit (3.3M), ще можете подивитися MobX(1.3M), або Zustand (3М).

3. Бібліотека для роботи з формами. Якщо у вас на проекті багато форм, раджу розглянути react-hook-form (4.7М) як інструмент що спрощує роботу зі станом форм (touched, dirty, error) та валідацією. Formik, нажаль, більше не підтримується командою (перевірив).

4. Інструменти валідації, які допоможуть спростити валідацію форм та даних що літають між сервером та клієнтом - Yup (5.6М), Joi (9.2M).

5. Якщо у вас багато роботи з часом - розгляньте Luxon (7.4M) або DateFNS (18.5M). Робота з часом буває дуже не тривіальною, тому не створюйте собі баги на пустому місці, беріть ліби.

6. Переклади та інтернаціоналізація - дивимося react-i18next (3.2M) або react-intl(1.4M). Спробуйте відмалювати текст: "У мене N користувачів", де N довільне число, а фраза для перекладу має бути лише одна.

7. Транспорт. Раніше Node.JS не підтримував fetch, та й сам fetch був більш обмежений (наприклад не підтримував відміну запиту), тому зараз на проектах є спеціалізовані бібліотеки для комунікації з сервером. Подивіться axios (47M), він мега популярний.

Але не кидайтесь на цей список одразу. Спокійненько йдіть по пунктам, пробуйте на якомусь пет проекті. Всі ці ліби живі, всі використовуються в комерційних проектах і стануть вам у нагоді.

Ну і ще одне - ліб звичайно більше (той самий React Query) просто все не влізло в список. Але якщо що - пишіть в коментарях, я доповню.

* В дужках - завантажень на тиждень, 7М = 7 мільйонів завантажень на тиждень

Бережіть себе, допомагайте ЗСУ
@reactbeginners

Явно погані практики в #React, або що НЕ варто робити без особливих причин

1. Збереження даних в стейті, які можна вирахувати. Якщо дані можна порахувати під час рендеру, просто зробіть це, не треба їх десь зберігати.

2. Використання useEffect для даних, які можна вирахувати. Вам не потрібен useEffect для того щоб порахувати дані - це можна зробити прямо в рендері.

3. Відсутність відписок в useEffect від асинхроних запитів, timeout-ів, подій через .addEventListener. Просто гарна практика яка може врятувати вас від memory leaks, особливо з interval та подіями.

4. Використання useCallback та useMemo без попередніх вимірювань. Використання useCallback та useMemo ускладнює читання вашого коду  - ви зобов'язані пересвідчитись що воно того варте.

5. Збереження локальних даних в глобальному стейті. Всі локальні дані, що потрібні одному компоненту повинні лежати лише локально - не захаращуйте глобальний стейт зайвим, вам з ним ще далі жити.

6. Використання випадкових ключів в списках, або не використання ключів взагалі. Зміна ключа призводить до видалення компоненту з DOM дерева і створення його заново. Це дорого, користуйтеся ключами правильно.

7. Оголошення структур які не залежать від компоненту в самому компоненті (функції, словники, тощо) . Якщо ви можете викинути щось з компоненту просто перемістивши його - зробіть це. Код стане простіше читати і він стане навіть трохи швидше.

8. Використання context-у для швидкозмінних даних (mousemove, scroll, etc). Зміна контексту змушує перерендерюватися усі компоненти що його використовують, а ці події спрацьовують сотнями. Воно вам треба?

Якщо якийсь пункт треба розкрити детальніше - пишіть під постом.

Плейліст присвячений цій темі

Бережіть себе, допомагайте ЗСУ

@reactbeginners

Навіщо потрібен React.Context і як не відстрелити собі ногу

Контекст в #React це засіб передачі даних та сутностей всередині застосунку.

Найкраще він підходить для двох речей:

Зберігання даних що потрібні всьому застосунку і які майже ніколи не змінюються, а їх зміна має призводити до перемалювання більшої частини застосунку, наприклад:

1. Дані користувача та стан аутентифікації
2. Локаль та часовий пояс
3. Налаштування теми, якщо ви використовуєте CSSinJS

Передачі сервісів, які потрібні всьому застосунку:

1. Ваша обгортка над fetch або налаштований екземпляр axios
2. Обгортка над LocalStorage, SessionStorage, IndexedDb
3. Обгортка над Navigator

Використання цих сервісів через контекст (а не напряму) дасть вам можливість легко протестувати код який їх використовує. Для цього достатньо лише передати фейкову реалізацію сервісу через провайдер і код готовий до тестування. Поставте 🤝 якщо потрібен окремий приклад такого підходу (викладу на gist)

Чому не використовувати контекст у якості стейт менеджера? Відповідь дуже проста - швидкодія. Коли змінюється значення контексту, всі хто використовує useContext з цим контекстом будуть перемальовані автоматично. Оскільки контексти зазвичай знаходяться "згори", а більшість наших компонентів функціональні, це призводить до перемалювання майже всього застосунку що може дуже не очікувано вилізти боком під час подальшого розвитку застосунку.

А якщо у вас є дані які потрібні по всьому застосунку і які часто змінюються - використовуйте стейт менеджер, наприклад RTK або MobX. Вони спроектовані саме для цього.

Хто дочитав - тримайте маленький лайфак:

Якщо ваші дані ніколи не змінюються - використання Context.Provider взагалі не обов'язкове. React буде використовувати ті дані що ви передали під час створення контексту 😎. А разом з кастомною обгорткою над useContext створення та використання сервісів стає дуже простим.

Корисно? Тоді закиньте 20 гривень на збір на "електрохарчування" для підрозділу 112 бригади ТРО - це дуже важливо, хлопці вирушають на 0. Ще й шанс виграти гарну і корисну книжку або гільзу від ППО.

Дякую пану Дмитру за ідею для допису,

Бережіть себе, допомагайте ЗСУ,
@reactbeginners

Як #React контекст допомагає в тестуванні

Найкращий спосіб пояснити - показати на прикладі. Відкрийте цей гіст і давайте його розберемо

1. Створюємо об'єкт API який буде відповідати за комунікацію із зовнішнім світом і кладемо цей об'єкт в контекст за допомогою createContext
2. В довільному компоненті витягуємо об'єкт API з контексту і використовуємо його.

Поки все зрозуміло, правда? Та "магія" починається далі.

3. В нашому тесті, ми створюємо новий об'єкт API який буде більш підходящий для тестування - він не ходить в мережу, а просто повертає проміс з гарантованим результатом. Далі, ми огортаємо компонент який бажаємо протестувати в ApiContext.Provider, а в value - підсовуємо йому нашу фейкову реалізацію.

Коли React рендерить наш тестовий компонент, він знаходить наш провайдер і замість справжньої реалізації бере нашу нову, фейкову яку і використовує. Так ми можемо протестувати будь-які дані та симулювати будь-які помилки. Спробуйте, наприклад, замість Promise.resolve передати Promise.reject і побачите що станеться з цим компонентом якщо, наприклад не буде інтернету)

Питаннячка?)

П.М. Доречі, код робочий можете спробувати, треба тільки vitest доналаштувати для тестів

Бережіть себе, допомагайте ЗСУ,
@reactbeginners

ЗБІР ЗАКРИТО! ЗВІТ ТА РОЗІГРАШ НА НАСТУПНОМУ ТИЖНІ!

Збір завмер майже на самому фініші - залишилося зібрати 7_910 гривень і я знову буду мучати вас матеріалами про #React

А щоб все було чесно - мої 3000 гривень теж пішли на збір. Долучайтеся, поширюйте, залишилося ще трохи!


1. І трохи статистики - найбільша пожертва 10_000 гривень
2. Кількість людей що вже прийняли участь - більше 110 осіб
3. Кількість організацій що прийняли участь - 1, дякую Fwdays
4. Найкращий коментар - "Не багато, але від щирого серця!"

Кожні 50грн - шанс виграти розфарбовану гільзу від ППО, якими Київ відбивав шахедів

Всім дякую, давайте сьогодні дотиснемо аби на цьому тижні все передати

Як писати чистіший код на #React

1. Робіть маленькі компоненти. Не треба складати все в купу, навіть якщо зараз це виглядає зручно - підтримувати потім буде дуже важко.

2. Розділяйте компоненти на ті що отримують дані та ті що їх відображають. Такий підхід спрощує підтримку та тестування.

3. Пишіть мінімум коду в JSX - виносьте його в блок до return. Так у вас буде блок логіки (до return, та блок відображення - те що в return)

4. Виносьте логіку в окремі функції або кастомні хуки. Компоненти потрібні для відображення, бізнес логіка має лежати окремо і бути протестована.

5. Взагалі виносьте з функцій будь-який код, що не залежить від компоненту. Оці всі магічні числа, масиви для дропдаунів - все це геть, чим менше в компоненті коду що його не стосується тим легше його читати та підтримувати.

6. Мінімізуйте useEffect. Використовуйте useEffect лише якщо немає іншого виходу - наприклад для асинхронних запитів. Намагайтеся його уникати.

7. Зберігайте локальний стейт локально. Якщо дані компоненту потрібні лише цьому компоненту - не варто додавати їх в глобальний стор.

8. Гарно спіть та повільно думайте. Вам платять за вирішення бізнес задачі, а не за кількість символів. Ясний розум - одна з основ чистого коду.

Якщо у вас є бажання та готовність пройти CodeReview в прямому ефірі - пишіть в ПМ.

Бережіть себе, допомагайте ЗСУ,
@reactbeginners

Поки я тут погоджую що можна і що не варто - напишу ще про розробку

Головне правило гарного коду - простота. Написати складно може кожен. Написати просто і очевидно - це те до чого ми маємо прагнути, коли пишемо код.

Навіть складний код, завжди можна загорнути в абстракцію яка дозволить цю складність приховати.

1. Не нехтуйте класами (навіть в #React) вони дають зручний доступ до стану
2. Пишіть маленькі функції які роблять щось одне - їх простіше підтримувати
3. Дробіть компоненти на підкомпоненти - якщо що їх завжди можна об'єднати
4. Мінімізуйте використання глобальних змінних
5. Запобігайте props drilling (моя хвороба) за допомогою стору та контекстів

І, дуже важливо, перед тим як мерджити код - дайте йому постояти трохи і критично оцініть його на простоту. Якщо код виглядає складно - скоріше за все ви десь помилилися.

Бережіть себе, допомагайте ЗСУ.

@reactbeginners

Як я розділяю застосунок на компоненти (про декомпозицію)

Якщо коротко - то за їх функціоналом, так щоб при погляді на код ви могли назвати одну і лише одну задачу яку виконує цей код.

Якщо компонент або клас або функція робить декілька речей одразу - вони кандидати для декомпозиції.

Наприклад нам потрібно відобразити список втрат русні за всі роки. Для цього нам потрібно - завантажити дані, обробити потенційну помилку, зберегти дані в стейт, відмалювати дані, відмалювати помилку, відмалювати індикатор завантаження.

Все це можна покласти в один компонент, але краще розділити код на окремі частини:

1. Код що вантажить дані. Зазвичай це код навколо fetch, він не залежить від #React - його зручно тримати окремо
2. Код який зберігає дані в стейт. Це можна тримати в компоненті, а можна викинути в окремий кастомний хук
3. Компонент що відображає результат. Відображення даних краще відділяти від їх завантаження, так код компонента вьюшки буде простішим
4. Компоненти що відображають помилку та завантаження - вони мінімально залежать від батьківського компоненту і можливо ви їх навіть використаєте повторно.

В результаті ми отримаємо один батьківський компонент, який займається композицією, і декілька дрібних підкомпонентів кожен з який займається однією єдиною задачею:

export function DemoApp() {
  const { casualties } = useCasualtiesData();
  const { status } = casualties;
  return (
    <main>
      <H1>Втрати русні</H1>
      <p>
        {status === "loading" && <LoadingIndicator />}
        {status === "failed" && <LoadingError />}
        {status === "ok" && <CasualtiesView casualties={casualties.data} />}
      </p>
    </main>
  );
}

Підхід рекурсивний, допоки не дійдете до бажаного результату.

Раджу спробувати!

@reactbeginners

Коротко про декомпозицію коду в #React (19:00)

Завтра відбуваю на навчання тож на останок тримайте відео про React та декомпозицію, яке виходить сьогодні о 19:00.

Знімав трохи поспіхом, але наче вийшло. Поставте під відео декілька лайків - буду радий побачити що не просто так робив)

А ви бережіть себе, допомагайте ЗСУ і скоро побачимося!

Хто бажає підтягнути трохи свій рівень #React раджу подивитися наш плейліст - React Code Smells: https://www.youtube.com/playlist?list=PLx9b8ngesbGG_kYzCcPBg8F96f9mhhN-e

Також до нього є відкритий репозиторій з прикладами.

Бережіть себе, допомагайте ЗСУ і скоро побачимось!

Вибираємо систему керування станами

Крок перший - оцінити чи потрібна нам вона взагалі

Деяким застосункам система керування станом може бути взагалі не потрібна. Якщо в застосунку не велика глибина, немає значної взаємодії між користувачем та апкою, стан локальний (не потрібен в усьому застосунку одразу) цілком можна обійтися без системи керування станом, а використовувати звичайний стейт.

Але, скоріше за все, вам так не буде (С)

Крок другий - оцінити чи можете ви використати контекст

#react потрібен лише тоді коли у нас є багата взаємодія з користувачем (не робіть лендінги на react, навіть якщо вас просять). Тому скоріше за все дані у вас будуть, і їх треба буде зручно отримувати та змінювати. Але чи потрібна при цьому система керування станом? Якщо дані змінюються не часто, зміни не є особливо складними - можливо вам влаштує звичайний контекст.

Так, контекст не є системою для керування станом, а скоріше шиною передачі, але і для роботи зі станом він може стати в нагоді. Подумайте про те, чи варті фічі нової бібліотеки тої складності яку ви додаєте в проект.

Крок третій - вибрати стейт менеджер під задачу.

Якщо ви все таки впевнені що вам потрібна система керування станом, не беріть першу ліпшу про яку почули.

Наприклад redux чудовий якщо вам потрібна можливість відміняти зміни, або у вас вся команда працює саме з ним. MobX, в свою чергу, зручний для тих хто звик до ООП підходу (раджу спробувати). А #tanstackquery (#reactquery) буде корисним якщо у вас багато мережевих запитів.

Якщо це все підсумувати - завжди намагайтеся зрозуміти навіщо ви робите той чи інший крок і все у вас буде добре)

П.М. Спонсор цього посту - мій увал,
Ваш зампомиш)

Я тут трохи облажався, але cordova схоже мене спасе, та давайте спочатку (багато тексту)

UPD: Переїхали на capacitor

Зробили ми нещодавно апку (react, vite, react-router-dom) одна з основних фіч якої була у максимально простій доставці до кінцевого користувача. Буквально: скинув ОДИН файл і все працює з коробки, без танців з бубнами - відкрив в Chrome і маєш щастя. А HTML, ну начебто, як раз саме про це, то ж в теорії ідея була зашибісь)

То ж ми зробили, протестили під віндою і наче все супер. Залили на android - а там білий екран... Як так? Почали копати, виявилося що react-router-dom не дуже любить коли його запускають на чомусь що не схоже не справжній URL, наприклад content://com.google.android і просто тупо кидає exception, що обвалює весь застосунок на корені.

Але ми то не пальцем роблені, то ж за дві години зробили патч в react-router-dom (може доречі його викласти?) і воно ожило Але тут друга халепа - зображення. Зображення тупо не працюють хоч ти трісни.

Чотири години шаманізму, кави, коли, матюків і ні... Не працюють. Що робити?

Вирішили пакувати в APK. Першою ідеєю було взяти #reactnative. Тут #React і там React - все наче сходиться. Але ж ні, у react-native розмітка йде власними компонентами, а у мене оці всякі div, span, article і прости нас main з nav...

І тут приходить Cordova яка каже - а давай мені свій HTML а я вже далі якось сама... І ви знаєте - полетіло. Так прийшлось помучитися з установкою android, раз 20 перезавантажити ноут бо на вінді ж PATH не оновлюється одразу, але вчора я залив на телефон APK який працює))

Так там теж є складнощі з підписом, з тим що ЗАСТОСУНОК НЕ ПЕРЕВІРЕНИЙ КИНЬ КАКУ ВІДПРАВ ГУГЛУ НЕ ЧІПАЙ СТРАШНО, але в цілому схоже що це наш варіант.

То ж кому потрібно портувати react в andoid - подивіться в сторону #cordova. Так, вона старенька, але схоже що ще може дати джазу.

Бережіть себе, допомагайте ЗСУ,
Ваш Зампомиш

Антипаттерни в #UX для #web розробників

- Не використовувати тег form
Якщо у вас є форма, наприклад реєстрації або логіну - використовуйте для неї теги form та button. Як мінімум - це дає можливість користуватися ентером для сабміта форми, що дуже зручно якщо у вас є автозаповнення. Плюсом іде доступність.

- Ігнорувати label та атрибут for
Якщо ми вже заговорили про форму - не забувайте використовувати label та атрибут for або htmlFor в #React. Це дає можливість тицьнути на лейбу і одразу почати взаємодію з інпутом. Для маленьких чекбоксів та радіобаттонів на телефоні - просто must have. Доречі, ще один спосіб зробити життя користувача телефону краще - використовувати атрибут inputMode - дуже гарна штука.

- Span/div замість справжніх кнопок та посилань
Посилання це завжди тег а. Хоча б тому що на ньому можна клікнути середньою кнопкою щоб відкрити у новому вікні. А ще вони обидва мають додаткову поведінку, правильну роль та табаються. Бонусом SEO та доступніть.

- Відсутність префікса tel: в лінках з телефонами
Я про це вже писав але повторю ще раз: дайте людям можливість подзвонити з телефону, а не копіювати цей клятий номер по одній цифрі. Просто зробіть це.

- Автоматичне закриття нотифікацій критичною помилкою

Якщо стається критична помилка, наприклад не збереглися дані які користувач вводив 10 хвилин - користувач має про це знати. Показати йому червоний тост на 1 секунду - просто не достатньо. Ви маєте дати можливість користувачеві прочитати важливе повідомлення, а не закривати його самостійно.

- Відсутність індикації тривалих процесів
Ще один антипаттерн який я часто зустрічаю. Користувач натискає на кнопку зберегти і ... нічого не відбувається. Чи пішло збереження, чи сторінка не працює - ніхто не знає. І лише секунд через 20 з'являється черговий тост що все пройшло успішно. А за ці 20 секунд користувач ще раз 10 тицьнув цю кнопочку... В результаті злий користувач і 10 зайвих запитів на сервер.

- Ховати скрол, бо "у користувача стрибає лайаут"
Якщо так робити, то рано чи пізно, на маленьких екранах контент стане не доступним,а користувач нещасливим і, або буде редагувати HTML вручну, як я, або тупо піде з вашої сторінки (ситуація не вигадана). На щастя у нас є css властивість scrollbar-gutter, яка може з цим допомогти. На горе - Safari поки її не підтримує, тому треба городити костилі. Але навіть костилі краще ніж замовник який не зміг нічого придбати, бо його 30 продуктів зсунули кнопку купити за межі екрану.

Про що не згадав - зображення однієї якості для всіх пристроїв, заборона виділяти текст та користуватися меню правої кнопки, валідаційній повідомлення які зсувають вниз контент і таке інше. Про це напишу наступного разу.

Бережіть себе, допомагайте ЗСУ!
Ваш зампомиш.

Логічний оператор && в #react

Часто* бачу використання логічного && в React для виведення на екран якогось контенту з умовою. Наприклад десь так:

logged && <Greetings/>

І, зазвичай все йде добре, а поки в нашу умову не потрапляє 0. І тоді замість "нічого" ми побачимо 0

Що робити? Або використовувати тернарний оператор разом з null

logged ? <Greetings/> : null

Або, просто перетворити logged на true/false за допомогою !!

!!logged && <Greetings/>

Так і код буде коротшим, і проблем не буде.

П.М. Так, я повернувся з відрядження)
П.П.М. * Ну зараз не часто, але раніше було, це правда 😃

Питання зі світу #React і, якщо дуже не пощастить, співбесіди:

Коли ви не можете використати <></>, а змушені використовувати <Fragment>?

Коротка відповідь:
Тоді, коли нам потрібно використати властивість key, яка не існує в <></>

Довга відповідь:
У React компоненті, може бути лише один нащадок нащадок першого рівня. Але, іноді, нам потрібно їх декілька, і раніше нам доводилося створювати зайвий елемент, просто для групування. Це призводить до засмічення коду та появи зайвих елементів в DOM.

Для того щоб із цим боротися з'явився компонент <Fragment>, який потім спростили до конструкцію <></>. Але ця конструкція не може мати атрибутів, в тому числі key який потрібен під час генерації списків. І ось тут то і може стати в нагоді старий <Fragment:

[].map((user, i) => <Fragment key={i}>{user}</Fragment>);

І тут постає ще одне питання - чому ж не винести це в окремий компонент, на якому ми зможемо використати свій key? Як ви думаєте?

Повернемося до #React. В #reactrouter є цікава можливість - винесення завантаження даних на рівень роута

Це може спростити ваш код оскільки тепер за обробку помилок а також за обробку стану завантаження буде відповідати код роутера.

Якщо виникне помика - буде показаний errorElement
Поки код буде вантажитися - буде показаний hydrateFallbackElement

А вам, в свою чергу більше не треба засмічувати свій компонент зайвим кодом, або створювати власні обгортки щоб то сховати.

Для отримання завантажених даних достатньо використати хук useLoaderData, який буде доступний по усьому застосунку нижче рівня цього роуту.

Можливо систему зі складними правилами інвалідації кешу на ньому не побудуєш, але для простих застосунків можливість цікава і зручна. Ну і так, трохи холіварна))

Початкові налаштування нового #react проекту

Видаліть все зайве - зайвий код, зображення, іконки, тощо.

Передивіться вже встановлені залежності коду і перенесіть в секцію dev ті залежності, що призначені для розробки (eslint, prettier, jest). Це буде корисно коли/якщо ви будете налаштовувати npm audit --omit=dev`

Налаштуйте форматування за допомогою prettier

та одразу застосуйте його з прапором --write. Досить сперечатися про крапки з комами.

Встановіть і налаштуйте лінтер - eslint під себе, або за правилами команди. Наприклад для не використаних змінних я ставлю warning замість error, не так сіпається око.

Встановіть та налаштуйте систему хуків для git - husky. Так ви зможете виконувати будь-які додаткові дії перед/після коміту/пушу. Наприклад ви зможете налаштувати husky автоматично запускати форматування staged коду. Тепер код у всіх і завжди буде виглядати одноманітно і без зусиль.

Напишіть readme - Два речення про що проект, як встановити залежності (навіть якщо це тривіальний npm install бо може бути і yarn install), як запустити dev збірку, та які правила ви налаштували (а в ідеалі ще й чому)

Все, можна плисти далі.

Але якщо хочеться більшого то... це буде в наступному пості :)

П.М. Амеліансе, я пам'ятаю що ти не фанат прітієра, та поки краще не зустрічав)