Анонс прямого ефіру 🤩

Мені дали відпустку, так що якщо нічого не станеться то:

Коли: 28.01.24, о вівторок, о 19:00 (через 10 днів)
Де: Ютуб, не забудьте підписатися
Про що: Пет проекти, як доводити їх до кінця і чи потрібно це взагалі.

Буду вдячний за поширення і всіх чекаю.

П.М. Я ж казав що буде нове відео :)

Подкасти повертаються! Уже цього четверга відбудеться запис випуску на тему "Хто такі, курвамать, ті синьйори, як їх відрізнити від нормальних людей і чи варто ломиться в синьйори усім поголовно".

А допоможе мені розібратися в цій темі неперевершений Нікіта Галкін, найбільший експерт з NodeJS, якого я знаю, справжній системний архітектор (не то шо я), Google Developer Expert і просто неймовірної душі людина.

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

ВАЖЛИВО
1. Запис буде. Але згодом. Змонтований.
2. Під час етеру будемо збирати донати на ЗСУ та розіграємо подарунки
3. Виключно під час етеру ви матимете нагоду поставити своє запитання гостю
4. Ще раз: запис буде викладено згодом, відредагований.
5. Приходьте на етер, буде цікаво ;)

23 січня, канал "Сергій Бабіч та Дивовижний світ веброзробки", 19:00

.

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

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

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

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

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

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

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

Про пет проекти - їх потрібність, як обирати тему і як довести все до кінця - поговоримо вже завтра, 28.01 о 19:00 в прямому ефірі на ютубі

Приходьте, буде цікаво. І завжди вдячний за поширення 😉

П.М. Буду вдячний якщо пошерите в LinkedIn

Невтомлююся радіти людям поруч зі мною. Провів чудовий день разом з @FwDays, які вчергове не відмовили допомогти нам зі збором. Хлопці, дівчата, вся ваша команда крута та неймовірна! Та й і програма була цікава, особливо сподобалася остання доповідь.

П.М. Сподіваюся наш маленький інтерактив нікого не розлякав) Якщо так то на наступну конфу ще щось придумаємо)
П.П.М. Респект Serhii Nemchynskyi за доповідь Українською, дуже круто!
П.П.М. Живий, здоровий, часу на ТГ майже немає :( Але прорвемося!

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

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

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

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

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

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

Так панство, тут Genesis Front-End School відкриває безкоштовні курси з побудови фронт-енд застосунків.

З плюсів - в теорії можуть після навчання можуть взяти на роботу
З мінусів - відбір, який треба буде пройти: HTML, CSS, JavaScript/TypeScript, React. Але думається мені ви впораєтеся (або дехто взагалі ментором туди піти може 😅).

Дедлайн 13 квітня, старт 19 травня.

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

Тут деталі, якщо хтось влаштується буде супер.

П.М. Вибачайте що контенту мало, тексту мало, всього мало. Телеграму під рукою немаю, бачу його вряди годи (лінкедин і то частіше). Та й трохи втомлююся якщо чесно. Останнім часом все дуже нервово і не просто. Напевне війна...

Тримайтеся. Дотянемо, переживемо і ще посидимо на березі річки....
Всіх обняв, ваш ЗамПоМиш

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

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

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

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

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

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

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

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

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

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

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

Продовжуємо серію про налаштування #frontend проекту і тепер потурбуємося про #websecurity.

1. Перевірте, що файл .env.local або його аналог не доданй під git. Так ваші паролі або токени не потраплять в мережу, а ви не отримаєте додаткові рахунки. Всі ключі/токени/паролі які ви використовуються мають зберігатися окремо або в key vault, або хоча б на білд машині яка готує реліз.

2. Налаштуйте перевірку ваших залежностей за допомогою команди npm audit. Ця команда покаже вам пакети, що містять вразливості та допоможе оновити їх щоб це виправити. Для того щоб було менше false positive спрацювань:
- - Перенесіть в dev секцію вашого package.json файлу всі залежності що стосуються розробки - prettier, eslint, jest, і т.д.
- - Використовуйте npm audit з прапорцем --production або --omit=dev.
- - Передайте привіт create-react-app :)

Гарною ідеєю буде інтегрувати цю перевірку в merge фазу пулл реквесту. Або раніше якщо не хочеться все перероблювати :)

3. Безпека runtime. Через особливість налаштування, частіше цим займається команда інфраструктури або бекенду, але частково це можемо налаштувати і ми. Особливо якщо у нас щось накшталт #nextjs

Мова йде про основні безпекові заголовки - Content-Security-Policy (CSP), X-Content-Type-Options, Feature-Policy. А якщо ви ще й піклуєтеся про приватність ваших користувачів то й Referrer-Policy. В разі правильного застосування, за заголовки можуть запобігти або суттєво зменшити шкоду користувачам вашої веб сторінки.

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

Ваш ЗамПоМиш.

П.М. Ви тут як? Бо останнім часом такий цирк на дроті що голова обертом.

Всім привіт!

Кажуть що збори загинаються, люди перестали підтримувати #ЗСУ. А у мене завтра #деньнародження, мені потрібна ваша допомога щоб повернути в стрій наше авто. От і давайте перевіремо. В 22 році з цим не було ніяких проблем, кожен допомагав чим міг. Подивимось що буде зараз :) Отже, на мій день народження, замість купляти собі стім дек, оголошую збір на ремонт зеленого буцефала - нові передні амортизатори (9000) та нову резину (16000). Бо аморти убиті в хлам , а резина лиса як більярдна куля та дірява як друшляк. Буду дуже вдячний за вашу допомогу. Звіт буде під цим постом.

П.М. Стрім обіцяти не можу, але постараюся організувати це найближчим часом.

👉Монобанка тут

Ваш ЗамПомиш,
#ЗСУ #ДеньНародження

Збір закрито, в чому я й не дуже сумнівався. Дякую всім за підтримку та свідому позицію.

А тепер серйозно.

Перемовини гальмуються не просто так. За підтримки трампа, русня вибила можливість заморозки фронту по лінії зіткнення (так, трамп зараз грає на боці русні, йому це просто вигідно). русня накопичила сил та літню кампанію через це зараз зупинятися їй просто немає сенсу. Тому, як мінімум літньо-осінню кампанію ми побачимо. Розвідка Америки взагалі прогнозує повторний наступ на Київ. І від того як нам вдасться відбитися - будуть залежати умови завершення війни.

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

Всіх обіймаю, поїхав купляти собі нові штани)

П.М. А це я - в багажнику бусіка. Не так там то і погано з кавою)

Отже про заголовки #websecurity для #frontend

Заголовків багато, різних, та нас цікавлять наступні:

1. Content-Security-Policy. Уявіть простий сценарій. На вашій сторінці знайшли XSS взраливість (треба про це розповідати?) і вбудували туди свій код. А він бах - і не працює. Чому? Тому що за допомогою CSP ви можете заборонити виконувати вбудований код. Тоді зловмисник може спробувати підвантажити код зі стороннього ресурсу. А це теж не працює, тому що ви обмежили завантаження JavaScript своїм доменом. Так само ви можете задати правила для будь-якого ресурсу - хоч JavaScript, хоч зображення, хоч CSS.

Що цікаво, що для налаштування цього заголовку вам не потрібно турбувати бекенд. Ви можете вказати його за допомогою тегу meta з властивістю http-equiv="Content-Security-Policy"

Правда є з ними і проблеми - складність налаштування (раджу використовувати CSP builder) та конфлікти з Google Analytics домен якої залежить від регіону. Відповідно вам доведеться додавати всі піддомени гугла у white list. Таке собі.

Детальніше почитати можна тут

2. Другий заголовок який нас цікавить - X-Content-Type-Options

Цей заголовок забороняє браузеру тип змісту ресурсів що завантажуються. Це протидії наступній цікавій атаці. Уявіть собі що ви налаштували CSP і заборонили виконувати JS. Зловмисник це побачив і замість файлу з content-type text/javascript відправляє той самий JS але не вказуючи тип. Деякі браузери (не всі), можуть спробувати подивитися в зміст файлу, і спробувати самостійно визначити його тип. Якщо тип буде визначено як JS цей файл буде виконано в обхід CSP.

Заголовок X-Content-Type-Options забороняє браузеру "вгадувати"

Нажаль, для цього заголовку, немає http-equiv, тому віддавати його має саме бекенд

Детальніше можна почитати тут

3. Третій заголовок - Feature Policy або його менш підтрумувана версія - Permission Policy. Тут все просто - цей заголовок вмикає/вимикає певні фічі WebAPI. Наприклад, якщо вашій веб сторінці не потрібна камера, ви можете повідомити браузеру що її вмикати взагалі заборонено. Якщо хтось таки зможе вбудувати XSS у вашу сторінку, камеру увімкнути він все одно не зможе. Так само можна вимкнути геолокацію, оплати, тощо. Це може захистити ваших користувачів раптом щось піде дуже не так.

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

Заголовків ще є, наприклад X-Frame-Options, Referrer-Policy. Раджу їх також подивитися.

А у мене поки все, дякую всім хто дочитав.

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

Вітаю всіх причетних, та й нас звісно)

А ви будьте уважні, наступні тривоги не ігноруйте.
Побачимося, почуємося :)

Ваш зампомиш.

Харків, співчуваю. росії байдуже кого вбивати. Власне їй навіть на своїх глибоко байдуже.

А з КАБами зараз можна боротися лише вибиваючи їх літаки. Робота ведеться але це займе час.

Харків, тримайся(

Паршива нічка. Як раз приїхав проходити ВЛК і тут таке.

В такі моменти шкодуєш що не служиш в ппо або не розробляєш далекобійну зброю.

Співчуваю...

Там Доу просить допомогти, заповнити зарплатне опитування. Доу постійно проводить збори для ЗСУ тому давайте і ми їм трохи допоможемо.


П. М. Трохи прогулявся по Києву - гарно, тихо. Наче все й добре. Тільки ціни на каву злетіли :'(

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

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

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

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

Другий момент - загальний loader який блокує геть весь екран, хоча заблокувати потрібно, наприклад, лише кнопку submit, або якийсь конкретний віджет. Звісно, нам так простіше - але, заблоковано має бути лише мінімально необхідна частина UI. Це дозволить продовжити роботу зі сторінкою поки користувач чекає на результат.

Тому, коли ви проектуєте щось з мережевими запитами - починайте з помилок. Замість fetch зробіть throw і подивіться як реагує ваш UI. І чи ок вам така реакція. Сповільніть інтернет через Google Developer Tools і вам одразу стане зрозуміло що не так.

Що ви тут взагалі?

Що нового в React? Що в NextJS? Як ринок - чи є робота?

Бачив що з'явилися нові ШІ для розробки (типу Cursor) але сам ще спробувати не міг, обмеження і все таке. Як воно вам?

Окрім обробки завантаження та обробки помилок, не забувайте також відписуватися від асинхронних подій - таймаутів, таймерів, requestAnimationFrame та запитів на сервер.

Зробити все це дуже просто - головне не забути про це :)

Для відміни мережевого запиту потрібно:

1. В useEffect створити екземпляр класу AbortController
2. Передати властивість signal в поле signal методу fetch (Axios це також підтримує)
3. Повернути з useEffect метод, який викличе abort на екземплярі AbortController

Все... Тепер, коли зміняться залежності ефекту, або коли компонент буде демонтовано, асинхронний запит буде відмінено.

З setTimeout, setInterval, requestAnimationFrame ще простіше. Вони повертають спеціальний id і все що вам треба зробити - викликати clearInterval, clearTimeout, cancelAnimationFrame у функції, яку повертає useEffect.

П.М. Планую зробити ефір в якому потоптатися по типових помилках в React. + Можливо зробити розіграш під благодійний збір на майстерню. Але поки це лише в планах.

Бережіть себе.