Писати full-stack додатки в одному фреймворці?

Зазвичай для фронтенду ви обираєте React, Vue, Angular або щось подібне. Для бекенду може бути Nest.js, Express, Koa, Fastify та інше.

А чому не робити фронт та бек на одному фреймворці? 🤔

Nuxt та Next вже давно мають можливість створювати власні API. Але й досі мало хто використовує їх серверну частину як справжній бекенд, обираючи інші фреймворки.

❓Чому так?

Не дивлячись на багато можливостей бекенду всередині Nuxt та Next, їх все ще може бути недостаньо для великих проєктів. До того ж деякі компанії бояться робити продукт на одному фреймворці, бо впаде він - впаде все.

Особисто для нас є ще один мінус - відсутність бібліотек для бекенду. Якщо взяти той же Nest.js, він дає з коробки все, що треба для бекенду: логи, корси, валідації тощо. Nuxt та Next же мають недостатньо функцій.

❓В яких випадках ми би рекомендували використовувати один фреймворк?

🧑‍💻Ви маленька компанія або фрілансер
Ви витратите набагато менше часу на написання цілого додатку, використовуючи лише один фреймворк.

💵 Фінансові обмеження
Обираючи тільки Nuxt чи Next, ви можете відмовитись від другого розробника, серверу та девопсу, до того ж створений додаток можна з легкістю самостійно задеплоїти на Vercel чи Netlify.

⚙️ Наявність бібліотеки
Якщо ви знайдете бібліотеку, яка вирішить всі проблеми з архітектурою, логами, плагінами тощо.

За таким підходом майбутнє, треба лише трішки почекати 🤫

@wannabe_javascript

AI всюди, навіть в комітах?

Багато хто з вас вже користується плагіном під назвою GitHub Copilot, який в рази пришвидшує розробку за допомогою підказок ШІ при написанні коду. А також його молодшим братом GitHub Copilot Chat - аналогом ChatGPT, тільки для програмістів.

Можливо, комусь приглянувся Cursor - редактор з вбудованим AI на основі VS Code. Або ви віддаєте перевагу Tabnine, який додає той самий функціонал, що і Copilot, тільки по своєму.

AI всюди і далі його буде ставати тільки більше.

А зараз ми би хотіли розповісти про, здавалося би, дрібничку, яка насправді дуже спрощує найнеприємнішу частину при написанні коду - вигадування назв для комітів 😨

GitLens нещодавно додав генерацію комітів в експериментальному режимі.

Плюси тут очевидні: GitLens сканує змінені файли і генерує для них ім'я коміту 🤯

Також відзначили декілька мінусів:

❌ якщо ви використовуєте Conventional Commits неймінг, то він не буде враховуватися при генерації;

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

Так, ця фіча досі експериментальна, проте вона вже доволі добре працює, і ми можемо сміливо рекомендувати її використовувати.

❗️Майте на увазі, що генератор використовує ChatGPT, тому ваші дані можуть потрапити в базу OpenAI.

На відео приклад її працездатності.

@wannabe_javascript

БЕМ - ворог, який став союзником.

БЕМ (Блок Елемент Модифікатор) - це методологія написання імен CSS класів, яка розповсюдилася на увесь світ. Наразі її використовують найбільші компанії світу.

Чому ворог? БЕМ був придуманий в компанії яндекс, офіс якої знаходиться в тій самій сусідній країні.

Чому тоді ми розповідаємо про дану методологію? 🤯 Бо вона вже давно вийшла за рамки компанії яндекс і почала розвиватися самостійно.

❗️Ми наполегливо рекомендуємо використовувати дану методологію іменування класів у власних проєктах.

Як все ж таки іменувати? Розберемо приклад багатофункціональної кнопки та уявимо, що вона зелена ✅.

<button class="button">✓</button>

Виглядає не складно, а тепер почнемо додавати функціонал: наприклад, кнопка матиме лоадер всередині себе.

<button class="button">
  ✓
  <div class="button__loader" />
</button>

До лоадеру додався клас button__loader з двома підкреслюваннями, і тим самим ми вказали, що loader є елементом button і не може бути використаним ніде, окрім самого button.

Уявимо, після цього ми вирішили, що кнопка може не бути зеленою, а тільки мати зелений border. І що тепер, копіювати? 😢 Ні, копіювання - це зло. Краще зробити наступним чином:

<button class="button button--outline">
  ✓
  <div class="button__loader" />
</button>

Ми додали клас button--outline, який є модифікатором. Таким чином у нас з'явилася структура:

• button - сам блок
• button--outline - модифікатор, який змінює тільки незначні стилі
• button__loader - елемент

В SCSS це можна описати так:

.button {
  background: green;

  &--outline {
    background: none;
    border: 1px solid green;
  }

  &__loader {
    // якісь інші стилі
  }
}



@wannabe_javascript

CSR, SSR, SSG. Який тип рендерингу обрати? 🤔

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

📐

CSR, або Client Side Rendering, – це класичний метод рендерингу у більшості сучасних SPA-фреймворків, таких як React або Vue. Він працює дуже просто:

• браузер завантажує ваш скомпільований JS-код
• код інтерпретується браузером
• ваш JS вставляє HTML-елементи та CSS-стилі

Звучить зрозуміло і не вимагає використання сервера, але чому не всі використовують цей метод?

• поки браузер завантажує JS, юзер бачить лише білий екран
• страждає SEO
• при пересиланні у Telegram або інші соцмережі неможливо додати картинку та опис до сторінки
• все навантаження лягає на браузер

📐

Тому на допомогу прийшов SSR, або Server Side Rendering. Як він вирішує ці проблеми?

• перший рендер відбувається на сервері
• після рендеру сторінка передається браузеру
• відбувається гідрація (розповімо про це пізніше)
• користувач отримує сайт з мінімальним очікуванням

Але і у SSR є недоліки

• потрібен сервер для рендерингу
• не такий простий у розумінні
• проєкт збільшується в розмірі

📐

А що як використовувати CSR та SSR одночасно? Тут на допомогу приходить SSG (Static Site Generation).

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

SSG також має свої недоліки

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

Тож що і коли обрати?

💪 CSR – для динамічних сайтів, де не важлива SEO-оптимізація. Наприклад, адмін-панелі та проєкти, до яких пошукові системи не мають доступу.

💪 SSR – для проєктів, де важливі SEO-оптимізація та швидкість завантаження. Це можуть бути, наприклад, інтернет-магазини, де корисно отримувати контент швидше, ніж за допомогою CSR.

💪 SSG – ідеально підходить для документацій, блогів, лендінгів, оскільки вся інформація відома заздалегідь.

@wannabe_javascript

Expo - найпростіший спосіб створювати мобільні додатки📱

JavaScript - це неймовірно велика екосистема, на базі якої можна створювати безліч речей, в тому числі й мобільні додатки.

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

І це ідеальний випадок звернути увагу на Expo. Він є оболочкою до react-native та пропонує великий набір сервісів - від ліхтарика до пуш-повідомлень.

Створення мобільного додатку починається зі звичних React та JavaScript.

npx create-expo-app my-app

Майте на увазі, що дана команда встановлює мінімальний набір, навіть без TypeScript.

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

npx create-expo-app -t expo-template-blank-typescript

Expo дає можливість одночасно писати додаток під iOS, Android та веб, використовуючи одну кодову базу.

Також Expo є сервісом, який допомагає робити білди та деплоїти проєкти в стори, такі як Google Play та App Store 💪

Тому для старту вашої мобільної розробки ми рекомендуємо придивитися саме до Expo 🔥

@wannabe_javascript

Гідрація - як оживають сторінки після рендеру на сервері?

У пості про методи рендерингу ми згадували гідрацію в контексті SSR. Тож, що це таке? 🤔

Гідрація в SSR - це процес, в якому HTML, що був згенерований на сервері, оживає на клієнті завдяки JavaScript. Це дозволяє вашому додатку й надалі бути реактивним у браузері, не дивлячись на те, що браузер отримав тільки HTML.

Чому на клієнт потрапляє HTML, який не є реактивним?

У процесі рендерингу ваших компонентів на сервері неможливо передати всі обробники, змінні, функції та подібне на клієнт. Це теж саме, що намагатися передати JS код в GET запиті.

Але оскільки сучасні мета фреймворки, наприклад, Nuxt або Next, мають доступ як до сервера, так і до клієнта, вони можуть проаналізувати, що відрендерив сервер і оживити його тими самими компонентами, які рендерилися на сервері 😵‍💫.

Дуже спрощена версія гідрації:

// серверна частина
import { renderToString } from 'framework';

return renderToString(<MyApp />);

// клієнтська частина
import { hydrate } from 'framework';

hydrate(<MyApp />, document.getElementById('root'));

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

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

Рекомендуємо ознайомитися з поняттям ClientOnly в Nuxt та з Server Components в Next.js, щоб більше зрозуміти, де та що саме вам може знадобитися.

@wannabe_javascript

Новий рік - новий Vue.

Ось і закінчився 2023 рік, а разом з ним - підтримка Vue 2.

24 грудня вийшла версія 2.7.16 Swan Song та 31 грудня Vue 2 офіційно перейшов в статус EOL (End of Life).

Тому всі, хто не встиг перейти на Vue 3, саме час почати міграцію 😉

Vue 2.0 вийшов 7 років тому і з тих пір подарував нам багато нових можливостей для створення додатків. А тепер давайте подивимося, що нам подарувала нова версія Vue:

Vite - один із найпопулярніших бандлерів для JavaScript. Має 4 мільйони скачувань на тиждень.

Vitest - зручний тул для тестування, який прийшов на заміну Jest. Має майже 1.5 мільйони скачувань на тиждень.

unjs - екосистема JavaScript, яка налічує понад 50 пакетів та має загалом майже 250 мільйонів скачувань на тиждень.

nitro - SSR фреймворк, на якому працює Nuxt.

Та ще купа корисного: UnoCSS, Vike, Volar, VitePress, unplugin тощо.

Vue, як один із головних фреймворків сучасного JavaScript, дає нам, розробникам, неймовірно велику екосистему, яка інтегрується з багатьма іншими фреймворками та бібліотеками.

Тому добра конкуренція з React, Angular, Svelte та іншими тільки вдосконалює наш з вами код.

Vue 2. F. 🫡

@wannabe_javascript

Слідкування за об'єктами та їх значеннями?

Ви коли-небудь задумувалися, як можна реагувати на якісь зміни в об'єктах? Наприклад, всередині форми на кожен інпут дані одразу зберігати в базі.

Звичайно, в першу чергу ви подумаєте про useEffect в React чи watch у Vue, але уявимо, що будь-який фреймворк для нас недоступний.

Який нативний спосіб в JavaScript існує для реагування на зміни?

Поганий варіант 👎

Повісити на кожен <input> новий addEventListener('input', () => {}) та всередині надсилати запит.

Проблема 🤔

Якщо ми повісимо debounce на кожен такий addEventListener, то на якомусь моменті деякі дані можуть загубитися, бо немає єдиного стейту даних.

Насправді проблем може бути багато, але debounce найкращий приклад.

Рішення 💡

Створити об'єкт та огорнути його в new Proxy, а кожен <input> просто буде зберігати дані в цьому об'єкті.

const obj = {};
const proxy = new Proxy(obj, {
  set(obj, prop, newVal) {
    // Записуємо дані
    obj[prop] = newVal;

    // Тут можемо надіслати запит на бекенд

    // Кажемо, що все добре
    return true;
  },
});

input.addEventListener('input', ({ target }) => {
  proxy.firstName = target.value;
});

console.log(obj);
// => { firstName: 'Valerii' }

Деякі фреймворки, як Vue 3, використовують Proxy, як головний спосіб реагування на зміни юзера.

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

@wannabe_javascript

TypeScript для фізичних девайсів 📟

Екосистема JavaScript виходить за межі інтернету. Спочатку придумали TypeScript, який перевернув розробку на JS, а тепер ще й з'явився DeviceScript 😱

DeviceScript був створений компанією Microsoft на основі TypeScript. Назва говорить сама за себе: тепер ми можемо створювати нові додатки не тільки у браузерах, на серверах, десктопах чи мобільних, а ще й на фізичних пристроях.

Чи каже вам про щось назва Raspberry Pi? Якщо так, тоді ви вже розумієте, до чого йде діло. 😉 Raspberry Pi - це фізична плата, до якої можна під'єднувати різні речі, такі як:

- лампочки
- датчики температури
- датчики вітру
- вібромоторчики
- тощо

Список девайсів, як і драйверів, неймовірно великий. Тому ми наполегливо рекомендуємо ознайомитися із DeviceScript.

А якщо у вас немає часу або вам взагалі не цікава розробка на фізичних девайсах, тоді можете подивитися принаймні приклад зі створенням показу температури на дісплей 🤫

Ви тільки уявіть, знаючи лише один JavaScript, ми можемо стільки всього створювати, хіба це не чудово? 🤩

@wannabe_javascript

Як розширити вже існуючий глобальний інтерфейс в TypeScript?

1️⃣ Якщо в TypeScript ви спробуєте записати будь-яку змінну в глобальний об'єкт, то отримаєте помилку:

window.newVariable = 'Hello';
// Property 'newVariable' does not exist

2️⃣ Або нам треба розширити вже існуючий глобальний інтерфейс:

Array.prototype.filterMap = function (callback) {
  return this
    .map(callback)
    .filter((value) => value);
};
// Property 'filterMap' does not exist

3️⃣ Чи якимось чином TS інтерфейс бібліотеки не має опису змінної:

import { userInfo } from 'lib';

userInfo.fullName
// Property 'fullName' does not exist

Для всіх цих кейсів існують способи розширення TypeScript інтерфейсів❗️

1️⃣ В першому прикладі нам допоможе розширення інтерфейсу Window, в нього ми можемо записувати будь-що:

declare global {
  interface Window {
    testVariable: string;
  }
}

2️⃣ Другий приклад розширює існуючий клас Array, бо нам захотілося створити свій метод роботи з масивами:

declare global {
  interface Array<T> {
    filterMap(
      callback: (
        value: T,
        index: number,
        array: T[]
      ) => unknown): unknown[];
  }
}

3️⃣ А якщо нам треба розширити інтерфейс бібліотеки, то код стає більш цікавішим, оскільки нам треба знайти оригінальний інтерфейс, імпортувати його ➡️ і тільки після цього ми зможемо розширяти. Без імпорту така схема працювати не буде:

import { UserInfo } from 'lib';

declare module 'lib' {
  interface UserInfo {
    fullName: string;
  }
}

Глобальні розширення зазвичай створюють в файлах global.d.ts або declarations.d.ts 😉

@wannabe_javascript

Усім привіт! Сьогодні не зовсім навчальний контент, але це напряму з ним повʼязано 😉

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

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

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

⭐️ З нас буде велика подяка у вигляді промокоду на знижку 50% на будь-який наш продукт, які почнуть виходити вже на початку весни.

Заздалегідь дуже дякуємо кожному, хто зможе долучитися і допомогти нам в цьому!

Посилання на опитування: https://forms.gle/S67K6oNvk3ZQPjFs8

Як правильно іменувати гілки та коміти?

Всі ми використовуємо Git, проте як часто ви задумуєтеся, чи правильно ви це робите? 😉

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

Іменування гілок 🤓

Найкращий спосіб - це додавання префіксів та номерів ваших задач, якщо вони є, наприклад:

type/PRJCT-NUM

type - це префікс, замість якого ви підставите тип своєї задачі.

Основними типами є:

📌 feature, bugfix, hotfix, release, docs

Також PRJCT-NUM може замінюватися на назву тікету, наприклад, в Jira або GitHub Issue. А якщо ви працюєте без тікетів, то можна легко придумати зрозумілу назву до вашої задачі.

Приклади коректних імен гілок:

📌 bugfix/WNB-100, feature/add-header, release/1.0.0, hotfix/101

Іменування комітів 😏

Правила іменування комітів схожі на іменування гілок, але з додаванням деталей.

Для найкращої перевірки правильності імен комітів існує Conventional Commits, який може перевіряти ім'я вашого коміту, тож якщо помилка є, він не дасть зробити коміт.

Формат запису такий:

type: message

або

type(SCOPE): message

Основними типами є:

📌 fix, build, chore, ci, docs, style, refactor, perf, test

Приклади коректних імен комітів:

📌 feat(api): implement user login, fix: login button, docs: add login information

@wannabe_javascript

Верстати імейли можна без болі!? 😱

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

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

Що дає React Email? 🤔

🖥️ CLI

Верстайте імейли з власним дев-сервером, використовуючи знайомі команди, як email dev, email build та email start. А для відправки згенеруйте чистий HTML, написавши email export.

🖥️ Компоненти

На даний момент React Email налічує близько 20 різних компонентів для спрощення верстки. Від чистого HTML та тайтлу до сітки та Markdown.

🖥️ Tailwind

Якщо ви звикли додавати класи, а не стилі, то React Email підтримує Tailwind.

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

🖥️ Різні типи рендеру

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

А ви знали, що Gmail вважається інтернет експлорером серед поштових клієнтів? 🤭

@wannabe_javascript