Тут би ще про is, assert та дженерики. За їх правильного використання життя стає сильно краще

Initial stack: jQuery, Bootstrap, Backbone partially migrated to React 15

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

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

Блістаю на тех-співбесідах 🌝

Якби вам потрібно було створити дашборд, які підходи та інструменти ви б використали? (HTML, CSS)
Відповідь «в лоб» — CSS grid та @media й @container query.

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

Нахіба комусь треба форми з react-bootstrap, коли є reach-hook-form + literally будь-яка інша ліба компонентів/стилізації?

А потім в тебе з’являється необхідність зробити дропдаун, який закривається по кліку поза елементом. І добрий вечір.

А в наступний момент ти розумієш, що щось пішло не так, але івент в реакті-то несправжній! І ти мучиш stopPropagation через addEventListener.

Тоді скоріше вже обмежуся кастомним SSR-сетапом :)

Цікава стаття, цікавий погляд на ще один варіант структури проєкту.

Хотілося б більше бест-практіс по кастомним хукам. З мого досвіду найбільшою проблемою з ними є практика «sweep under the rug», коли складну логіку з величезного компонента виносять в хук, навіть не намагаючись відокремити generic логіку. А потім повторюють це кілька разів, огортаючи величезний хук в кілька рівнів інших величезних хуків.

Час від часу бувають невідтворювані помилки локально, але на проді все наче ок.

А от коли допомогав знайомому налаштувати i18next з AppRouter на робочому проєкті — було весело. Довелося пояснювати всі ці приколи з рантаймами, після яких хлопець дивився на мене як на психа.

До того ж, перемикання мови звичними API i18next теж не працює. Тільки через перехід на іншу лінку з префіксом мови (що теж підійде не всім)

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

Ауч. Мати з таким справу на комерційному проєкті, напевно, дуже неприємний досвід

А з приводу локалізації, до речі, саме мої юзкейси зв’язкою nextjs + i18next поки що покривались непогано

А що використовуєте для стилізації, якщо не секрет? В них були проблеми з css-in-js підтримкою на самому початку, але пофіксили доволі швидко. Я використовую Mui та css-modules для додаткової стилізації (хочу якось спробувати перевести все на stylex+radix, але поки не на часі)

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

Чув багато схвальних відгуків, але давайте чесно: переписувати на Nuxt аплікуху, написану до цього на React скоріше за все ніхто не буде, бо дуже великий оверхед і дуже складно зробити такий рефакторінг поступовим. Тож це виллється або в написання з нуля та підтримку двох паралельних проєктів протягом кількох років, або у франкенштейна Vue+React, який таким і лишиться до остаточної смерті проєкта.

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

Нажаль, ніколи до цього не використовував azure функції

З того, що я бачив в обговореннях — все зазвичай зводиться до Vercel KV (Redis, по факту). Але проблема неприємна, тож буду інвестігейтити далі.

Зазвичай публічні сторінки не дуже інтерактивні, і інтерактивність де треба в ssg може бути реалізована вже на клієнті, це не зробить SEO гіршим.

Так, розумію :) щонайменше часткове ssg справді звучить як гарна ідея і варто місцями переглянути підхід.

docs.aws.amazon.com/...​st/dg/best-practices.html

Дивіться на «Take advantage of execution environment reuse to improve the performance of your function».

А от це дуже цікаво, дякую! Не маю зараз часу прочитати вдумливо, але за посиланням написано, що всі ініціалізації конекшнів треба виносити поза контекст виконання лямбди (саме з причин, які я вказав в статті). Маються на увазі якісь додаткові вбудовані інструменти на базі лямбд? Чи мова як раз про окремі сервери чи мікросервіси для авторизації/БД тощо?

Можна зробити правила авторизації для різних сутностей в різних модулях, заімпортити їх в middleware.ts і наприклад зробити статичний Map зі строки роуту на відповідну функцію авторизації.

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

Є така абстракція :)