Ну це просто не можу не пошарити - It Juniors роблять стрім з АНТАРКТИКИ!

Ефір вже завтра, подробиці тут. А ще можна спробувати поставити своє питання.

Як пропатчити KDE під FreeBSD вже було - тому можемо запитати чи не мерзнуть Fiber дерева в Антарктиці. Спитайте га?

💪💪💪 Оце я розумію рівень стріму)

Next.JS проектували

=> Ногами
=> Не люди
=> Не для людей

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

В Next.JS ви не можете налаштувати глобальну обробку серверних помилок (наприклад логування).
Все потрібно робити для кожного API вузла окремо. А оскільки обробники ендпоінтів це звичайні функції - на них навіть декоратор так просто не повісиш.

Обговорення цієї теми висить всього на всього сім років, без жодного руху.

Такими темпами я скоро стану Next-о фобом.

А як ще можна сказати про тих, хто використовує похилу в якості негативного значення.

- Ти сьогодні ЗП отримав?
- /

Бам...💥

UPD:

Вибачайте за негатив, але ну це ж просто не серйозно, такі дитячі хвороби мені можна вибачити а не Prod ready enterprise solution

Понеділок 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