Понеділок One to One

Кожен понеділок, 9:00 - 9:30
Якщо потрібна допомога з React|FrontEnd|Розробки - букайте мітинг

@reactbeginners

Моє бачення розвитку junior+ спеціаліста:

1. Поглиблення і систематизація основ. React зміниться на щось інше, а JavaScript буде актуальним ще дуже довго. Мені в цьому допомогла книжка "Секрети JavaScript Ніндзя" (шукайте останнє видання).

2. Поглиблене вивчення основного фреймворку/бібліотеки. Шукаємо щось накшталт React in depth. Це дасть вам змогу писати більш якісний код за допомогою вашого основного інструменту

3. Вивчення кращих практик. Спочатку читаємо про загальні підходи - (той самий "Чистий код" Мартіна), потім шукаємо специфічне для React.

➕Додатково, якщо вам важко дається написання коду взагалі - рекомендую LeetCode - це досить гарний тренажер алгоритмічного мислення. Головне не пишіть код в проекті так як там 😂

Також раджу відвідувати конференції - чудово розширюють світогляд та надихають.

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

Навчайтеся, розвивайтеся і все буде.

@reactbeginners

Як правильно віддати код на перевірку

0. Код має працювати*. Обов'язково додайте до репозиторію package-lock.json або yarn.lock файли для того щоб гарантувати ідентичність залежностей, що будуть встановлені на машині у перевіряючого. Якщо запуск коду вимагає чогось більш складного ніж npm i; npm start - вкажіть це в readme.md та в супровідному листі

1. Форматування**. Весь код має виглядати одноманітно і форматовано. Раджу використовувати prettier через його популярність. Команда npx prettier . --write вам у цьому допоможе. Не забудьте додати конфігураційний файл .prettierrc.json або .editorconfig

2. Приберіть зайве. Видаліть закоментований код, код що не використовуються та залежності які не потрібні. Перевірте що в репозиторій не включена*** тека node_modules, dist або build

3. Розберіться з усіма попередженнями від лінтера. Він ваш друг і намагається допомогти вам пройти рев'ю. Намагайтеся не допускати попереджень та помилок у консолі браузера чи Node.JS

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

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

@reactbeginners

У мене все працює😎

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

1. В секцію script файлу package.json додайте наступну команду

"type-check": "tsc -p tsconfig.json --pretty --noEmit && echo"

2. Перед комітом виконайте в консолі npm run type-check

Перевага цього способу полягає в тому, що ви будете точно впевнені, що:

* Будуть перевірені всі файли, а не ті що відкриті зараз
* Перевірка коду відбувається за налаштуваннями проекту, а не IDE
* Перевірка відбудеться проектною версією TypeScript

А для того щоб не робити це кожен раз руками - візьміть hasky та налаштуйте автоматичну перевірку перед кожним комітом. Один з прикладів налаштування husky можна знайти тут

П.М. Якщо й це не допомогло - встановіть залежності з нуля та стукніть в бубен)
@reactbeginners

Там у Львові планується безкоштовний мітап від Sigma Software University про GraphQL.

Хайп на GQL спав, але технологія корисна і жити вона буде, тому можна сходити та послухати + нетворкінг зараз дуже корисний

Тому:

📆 3 квітня, 18:00
🌐 Sigma Software офіс у Львові (вул. Наукова, 7д, БЦ Оптима Плаза, 4 поверх) або онлайн
👉 Реєстрація

Чекліст перед початком нового #FrontEnd проекту

Мінімальний розмір екрану
Визначаємо мінімальний розмір екрану і верстаємо одразу під нього. Перероблювати потім - дорого і довго. Перевіряємося за допомогою Google Developer Tools

"Найгірший" браузер
Дізнаємося який "найгірший" браузер хоче бачити наш замовник і перевіряємо на ньому. Найгірші в моєму порядку черговості - IE (хвала всім його дропнули), Safari, Firefox. Але може бути вимога щоб працювало в Opera Mini або на якійсь екзотиці, тоді готуйтеся страждати.

#SEO
Якщо потрібно SEO - беремо Server Side Rendering (#NextJs/Remix) або взагалі не React. Перероблювати потім суттєво дорожче. Якщо SEO не потрібно - #SSR брати не варто.

Доступність
Якщо треба то який рівень? Норвегія, США, зазвичай це WCAG AA (перекладено українською) для публічно доступних сторінок. Ставимо wave і перевіряємося постійно. Як варіант - в playwright є можливість писати тести для доступності. Дороблювати потім - неймовірно боляче.

Мультимовність.
Якщо так - налаштовуємо одразу і не хардкодимо тексти, а одразу використовуємо компонент що вміє перекладати (FormattedMessage як приклад).

Ще трохи (швидкодія, безпека) є тут

Складно? Так. Рівень джуна? Ні. Але краще про все це думати одразу і домовлятися на березі, аби потім не було дуже боляче. І не забувайте фіксувати ці домовленості письмово - бо усні домовленості люди чомусь "забувають".

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

⛏ Як розібратися з React трохи глибше

Якщо ви вже достатньо впевнені з React-ом, але хочете розібратися з ним глибше пропоную спробувати наступну схему

1. Відкриваємо цей репозиторій і знаходимо хук, який ви б хотіли бачили в своєму проекті.
2. Реалізуємо цей хук самостійно, нікуди не підглядаючи.
3. Відкриваємо код, який було написано іншим розробником і порівнюємо. Головне питання - чому ваш код відрізняється і який код краще.
4. Повторюємо з п.1 за бажанням

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

Наступний крок - спробувати написати спрощений React з 0. Інструкція англійською №1, та інструкція №2 . Це більш глибоке занурення в React, але воно дасть вам більше розуміння як саме працює React і чому JSX це просто синтаксичний цукор для створення певних об'єктів.

В сумі ви вчитеся читати чужий код, розбираєте підходи інших розробників та вивчаєте React, маємо win-win.

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

Сьогодні у Сергія Бабіча буде досить цікавий ефір про "мертві" мови програмування та застарілі технології.

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

Не буде сьогодні навчальних матеріалів. росія країна терорист, країна вбивця. Кожен день вони це доводять, а світ і досі не вірить.

Корисні вбудовані типи #TypeScript з прикладами.

TypeScript містить набір із 17 + 4 допоміжних типів. Розберемо найкорисніші.

1. Record<Keys, Type>
Найкорисніший допоміжний тип з усіх - словник

const dictionary: Record<string, string> = {};
dictionary['hello'] = 'world';

Стане в нагоді для конструювання динамічних об'єктів, коли ви заздалегідь не знаєте структуру майбутнього об'єкту. Дозволяє уникнути any.

2. Omit<TObject, TKeys>
Допоможе прибрати небажані властивості з об'єкту, наприклад пропси, що вже не потрібні:

type TextProps = { color: 'red' | 'green'; children: ReactNode };
const Text = (props: TextProps) => <></>;
const RedText = ({ children }: Omit<TextProps, 'color'>) => (
  <Text color="red">{children}</Text>
);

Також стане в нагоді для кастомізації існуючого типу, який ви не бажаєте писати заново:

type AppRequestInit = Omit<RequestInit, 'body'> & { body: object };
const data: AppRequestInit = { body: {} };

Для того щоб "взяти" якість властивості з об'єкту, ви можете використовувати Pick<TObject, TKeys>

3. Parameters<Type>
Дозволяє отримати тип аргументів функції/компоненту, якщо пакет їх напряму не експортує.

const Text = (props: TextProps) => <></>;
type Props = Parameters<typeof Text>[0];
const props: Props = { color: 'red', children: 0 };

Parameters повертає масив типів аргументів функції, тому ми за допомогою індексатору беремо перший тип.

Компліментарним до Parameters є тип ReturnType<Type> який дозволяє отримати тип значення, що функція повертає.

4. Partial<T>
Ще один досить корисний тип, який можна використати під час написання тестів. Робить усі властивості першого рівня не обов'язковими, але зберігає intellisense.

type User = {name:string}; 
type MockedUser = Partial<User>;
const mockedUser: MockedUser = {};

Протилежним до нього є тип Required<T> який робить всі властивості обов'язковими.

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

Бережіть себе, допомагайте ЗСУ,
@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

Якщо вам подобаються мої пости - у мене прохання

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

Це дуже дуже важливо ❤️‍🔥

Ми маємо триматися разом, нам ще треба перемогти. Дякую вам.

Вибираємо бібліотеку для проекту

1. Бібліотека має виконувати задачу. Беремо функціонал який ви вважаєте найскладнішим і шукаєте його в документації. Якщо з документації не все очевидно, або задача складна - зробіть proof of concept щоб позбавитися сумнівів

2. Бібліотека має бути відносно популярна. Чим популярніша бібліотека, тим більше по ній додаткових матеріалів та людей, що прийдуть вам на допомогу у випадку проблем. Плюс більше шансів що популярна бібліотека буде мати зручний дизайн та буде протестована (але це не точно). Перевірити це можна по "зіркам" в GitHub та кількістю завантажень в npm.

3. Бібліотека має підтримуватися. Відкрийте репозиторій та npm, перевірте останню активність. Якщо активності немає протягом тривалого часу (більше пів року), а issue багато - це поганий знак. Ми так влізли в халепу з UI бібліотекою, яка "застрягла" на react 17. Snyk показує рівень "здоровості" пакету, але бажано розуміти самому що там так або не так.

4. Бібліотека має бути без вразливостей. Якщо це dev залежність, то цей пункт можна спробувати ігнорувати, але за умови що вразливість не є бекдором або іншою схожою на це халепою. Якщо ви не впевнені, краще не ігнорувати.

5. Бібліотека має бути відносно маленька. Відносно, тому що якщо складні речі можуть потребувати багато коду. Але бібліотека яка лише перевіряє чи є щось об'єктом, не може важити 100Kb. В кінці кінців сам react-dom важить 130Kb. Пам'ятайте, що для проектів де швидкодія критична - у вас є приблизно 350kb для JavaScript в gzip Якщо ви пишите адмінку - цей пункт можна пропустити.

То ж коли обираєте собі бібліотеку - можете зробити собі табличку з цих пунктів для порівняння. Заодно задокументуєте чому було обране те чи інше рішення.

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

@reactbeginners

До речі - не потрібно шукати бібліотеку на все підряд

Для прикладу ось бібілотека - is-object яка має 3.4M завантажень на тиждень і зводиться до одного єдиного рядка:

const isObject = (obj) => typeof obj ==='object' && obj !== null;

Такі, або подібні до цього речі, варто робити самому, тому що кожна додаткова бібліотека вимагає:

1. Догляду. В бібліотеках бувають баги, бувають вразливості - відповідно вам треба оновлюватися і за цим слідувати. Звісно, у власному коді теж бувають і баги і вразливості, але коли весь код у вас - виправити простіше. Та й бекдор під час наступного оновлення ви не зловите.

2. Місця. Код який написали ви - використовується на 100%. А якщо ви берете з lodash один єдиний метод - то все інше просто сповільнює ваш застосунок (так, навіть якщо прямо не використовується). Це не запас на випадок кризи - "про всяк випадок" тут не працює.

3. Часу в пайплані. Кожна додаткова бібліотека це + до install часу. І, якщо на початку це не критично, то потім це дуже дратує, коли білд на сервері йде 18 хвилин, а без нього PR з виправленням однієї літери не проходить.

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

Я не хейчу подібні бібліотеки, у самого є така is-number-strict :)

@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

Щира думка про IT курси

Хайп трохи спав, тому можу висловитися спокійно. IT курси можуть бути корисними, але є кілька але.

1. Термін - курси з Front-End мають тривати щонайменше пів року. Можуть бути виключення у зв'язку з форматом, але десь так. Тільки на сам React ми виділяли два місяці і то я не можу сказати що цього було достатньо. А тут треба ще базу вивчити. Про курси full-stack я вже мовчу.

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

3. Люди. Курс мають викладати практикуючі розробники (Front-End постійно змінюються), які мають хоча б якийсь хист до викладання. Вивчати розробку під бу-бу-бу це int він займає 4 байти, а це bool він займає 1 біт (не завжди) така собі ідея - чесно кажу. Тому, якщо є можливість - сходіть на ознайомче заняття з тим хто буде вести вам лекції

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

Ще один дуже важливий момент - не очікуйте що "гарантоване працевлаштування" дійсно гарантоване, щоб вам не казали. Зараз ринок роботодавця, вакансій junior рівня мало, а бажаючих багато. Якщо ви вибрали цю стежку зараз - налаштовуйтесь на "довгий забіг" одразу.

А як же наявність програми? Звичайно що програма має бути обов'язково, але дати характеристики хорошій/поганій програмі досить складно та і немає гарантії що хороша програма буде викладено гарно, а проста програма - погано.

Я сам проходив платні курси 9 чи 10 років тому і в одному випадку мені пощастило, в іншому ні, хоча організація була одна й та сама)

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

@reactbeginners

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

Тому, я вирішив, що було б непогано перед цим принести трохи користі вам та ЗСУ:

На наступному тижні, з ПН по ПТ, я відкриваю календлі на 17:30-18:00, 18:05-18:35 для консультацій з Front-End/React. Вхід - будь-який донат на збір Сергія Бабіча на авто для кулеметного взводу 26-го окремого стрілецького батальйону 47-ї окремої механізованої бригади. Сума - на ваш розсуд. А з Сергія ми потім щось струсимо)

Бронюйте і приходьте, допоможу чим зможу. Завтра пошерю в LinkedIn, а поки у вас пріорітет.

З ким вже провів 1-2-1 - напишіть будь-ласка відгук під цим постом.

П.М. Якщо це таки дійсно станеться (це не 100%), я відпишу з певними деталями. Але поки так, в стилі інструктор ua (але не Тиса😃)

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

Наступне відео про Next.JS та API майже готове і виходить на цьому тижні, але дочитайте до кінця.

Це що б ви не думали що я нічого не роблю 😆

Але зараз не про це, а про збори.

По-перше, дуже дякую 🤗 всім хто долучився до збору Сергія (він теж дякує) - ми закрили всі слоти на one to one лише спільнотою, я навіть не викладав це в LinkedIn. Вже сьогодні починаю консультації.

А, по-друге, буквально через годину після того як я запостив про збір Сергія, до мене по допомогу звернулися мої дуже добрі знайомі які через два тижні відправляються на 0 і їм потрібен генератор та сонячна панель задля автономності, тому вибору немає - я оголошую збір на передчасний день народження

⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️

ЗБІР ЗАКРИТО!

Передчасне день народження, або збори ніколи не бувають вчасно

Одному з підрозділів 112 батальйону ТРО (який доречі приймав активну участь в захисті київського неба) терміново потрібне живлення - хлопці вже найближчим часом відправляються працювати на 0. Хлопців я знаю особисто, просто так вони не просять.

Їм потрібні гарна сонячна панель та комбінований дизель генератор, загальна ціна питання на сьогодні - 64_000 гривень.

В якості подяки, через монобанк, я розіграю:

1. Дві розписані гільзи 30 калібру які були випущені нещодавно під час відбиття атаки шахедів на Київ. Доречі, шахед таки поцілили то ж ці гільзи з цілою історією.

2. За найбільший донат - книгу "Грокаємо алгоритми" українською.

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

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

Монобанка
Номер картки - 5375411215740007

Якщо з грошима все складно (розумію) - будь-ласка, напишіть коментар підтримки збором в LinkedIn та пошерте, аби його побачило якомога більше людей.

Звіт і фото будуть обов'язково, всім дякую!

@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