Що ж, вже за 10 хвилин ми розпочинаємо наш четвертий епізод "Резюме гриль", і він буде присвячений розбору резюме спеціалістів рівня Junior. 

⏰19.00
📍Де: Ютуб канал Juniverse

Чекаємо вас з нетерпінням😎

Коротенький підсумок по 1-2-1 зустрічам:

1. Заплановано сім зустрічей, з них п'ять відбулося, на дві люди чомусь не прийшли (сподіваюся що з вами усе гаразд, але якщо ви просто проспали то не треба так)
2. Теми дуже різні, від очікуваних про кар'єру/навчання до таких які сам мусив передивлятися (архітектура React з середини)
3. В цілому, мені здається такий формат ОК - але будь-ласка, хто був - дайте чесний відгук чи було це вам корисно (можна тут, можна в Link, можна в ПП)

На наступному тижні я відкрию один слот на тиждень (в понеділок або четвер) на наступний місяць і відпишусь про доступність

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

П.М. У кого є - відкладіть трохи грошей, треба Сергію допомогти зі збором на машину (700 грн з минулого збору я як раз туди сьогодні кину)

Всім продуктивного та тихого дня.

🎉Хм, схоже свабодніе вібарі на росії почалися трохи раніше запланованого🎉

В добрий путь, як то кажуть.

П.М, Ніколи не перестану дивуватися скільки ж всього корисного можна було зробити за всі витрачені рашкою ресурси.

Ну це просто не можу не пошарити - 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 гривень, скільки можете. І обов'язково напишіть слова підтримки в коментарях. Наші військові мають знати що їх чекають, вони мають знати що їх підтримують, що їм є за кого воювати.

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

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