Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Час написати бекенд на TypeScript? Що таке T3 Stack

Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!

Я — FullStack-розробник, який вже декілька років працює з React, TypeScript та Laravel. У фронтенд-розробці я часто використовую TS і я обожнюю типи. Так, Laravel мені подобається, проте думка про написання бекенду на TypeScript мене не покидає вже давно. Недавно я побачив create-t3-app (пакет, який дозволяє швидко розгорнути T3 Stack) і задумався, що час спробувати щось нове. Час написати бекенд на TS.

Я вирішив зробити простий сайт, де я міг би перевірити зручність нового стеку за вечір чи два. Стаття знизу — це узагальнення мого досвіду й реакція на інструмент, не туторіал. Сам проєкт доступний на GitHub, якщо потрібно подивитися на код. Якщо хтось задумується про перехід на T3 Stack (або бажає використати якісь інструменти з цього стеку), надіюся, мій досвід вам допоможе.

Що таке T3 Stack

T3 Stack — це набір інструментів, популяризований розробником Theo. В його філософії лежить обов’язкова типізація всіх частин сайту. Автор стеку пропонує використовувати наступні інструменти для того, щоб досягти повного type safety (безпека за допомогою типізації):

  • Для фронтенду використовується Next.js (надбудова над React) разом із TypeScript.
  • tRPC — типізований бекенд, який передає свої типи до React. У випадку з Laravel тобі завжди потрібно писати вручну типи для будь-якого запиту до API. З tRPC це не потрібно, тому що і те, які дані запит може отримати, і те, які дані запит може віддати, ми отримуємо автоматично з того коду, який ми написали.
  • Prisma — зв’язок з базою даних. Звичайно ж, типізований. Створив модель — у тебе автоматично створюється тип цієї моделі в твоєму проєкті.
  • Tailwind — легкий спосіб стилізувати ваші макети. Мені особисто інструмент подобається, проте він необов’язковий. Можна встановити те, що вам зручно (правда, уже вручну).
  • NextAuth.js — бібліотека для авторизації. Теж не обов’язково, проте має допомогти з доволі важливим завданням.

Сайт

Я зробив сторінку логіну, сторінку реєстрації та сам профіль. Три сторінки, щоб використати всі наявні інструменти й дати їм якусь оцінку. Увесь код ви можете знайти в репозиторії на GitHub, а демо — ось тут. Так виглядає фінальний сайт:

Початок роботи

По аналогії з create-react-app, ми використовуємо create-t3-app, щоб швидко почати роботу. Заходимо в папку з проєктами й запускаємо команду npx create-t3-app. Я вибираю всі доступні пакети: nextAuth, prisma, tailwind, trpc.

Ця команда створює нам початкову систему папок в проєкті:

Важливо! Жоден із інструментів, наявних тут, не каже вам, як потрібно структурувати проєкт. Я звик до Laravel, який точно визначає папки, в яких ви маєте зберігати ту чи іншу частину сайту, і це я вважаю недоліком. Проте для когось, хто має інші уявлення про структуризацію проєкту, це буде перевагою.

Зараз процес набагато швидший, ніж якби я намагався встановити це вручну й поєднати між собою. Нам залишається лише створити .env файл та додати туди змінні середовища (ось посилання на те, як згенерувати NEXTAUTH_SECRET):

Висновок. Напишіть npx create-t3-app і через декілька хвилин у вас буде декілька інструментів, які вручну потрібно було би встановлювати годинами. Головне, не забудьте вказати змінні середовища.

Фронтенд

Я вже працював з TypeScript, React та Tailwind, тому вирішив почати роботу з макетів. Для цього мені потрібно створити три сторінки: логін, реєстрація, профіль.

Важливо! Для того, щоб створити сторінки, в Next.js використовується особлива система, яка створює посилання на основі папок і файлів. Якщо ви плануєте зробити сторінку за посиланням /admin/dashboard, ви створюєте папку /src/pages/admin, а в ній файл dashboard.tsx. Ця система для мене незвична, проте зручна.

У нашому випадку система папок виглядатиме так:

Робота з макетами розпочинається з визначення головних кольорів та стилів та налаштування проєкту. Ми розміщуємо головні кольори у файл tailwind.config.js. Пишемо глобальні стилі в /src/styles/globals.css. Та створюємо псевдоніми для папки src/components (@components) і src (@src), щоб до них можна було легко дістатися з будь-якої частини проєкту.

Приємний бонус від Next.js. Aliases (псевдоніми) для часто використовуваних шляхів — необхідна частина сучасної розробки. Працюючи із create-react-app мені потрібно було встановлювати @craco/craco та craco-alias, щоб псевдоніми в tsconfig.json працювали під час білду. Next.js робить це за замовчуванням. Можна добавити «paths» в tsconfig.json і вони будуть працювати як псевдоніми без встановлення додаткових пакетів.

Я не буду надсилати кожен файл, який я створив. Надішлю лише один, щоб було уявлення, як виглядає проста сторінка в такому проєкті.

У проєкті встановлено два додаткових пакета для зручності: react-hook-form та @svgr/webpack (на відміну від create-react-app, цю бібліотеку в create-t3-app треба встановлювати вручну). <Button /> — це компонент, написаний вручну. Login.protected — це спосіб захистити сторінку й перенаправляти людей, які вже авторизовані. Next.js у своїй документації вказує це як один із можливих способів вирішення цієї задачі.

NextAuth.js дає доступ до зручної функції signIn(). Увесь процес логіну стандартними способами (наприклад, через GitHub) вимагає на стороні клієнта тільки цю функцію. Сесія оновлюється самостійно і автоматично заново рендерить додаток. Саму логіку перенаправлення треба написати вручну. У моєму випадку ця логіка схована в /src/middleware/guest.ts (будь-яку авторизовану людину ми перенаправляємо до профілю).

Отже, якщо порівнювати create-react-app та create-t3-app, то зручність розробки такого маленького додатку мало чим відрізняється. Так, доведеться звикнути до нового способу налаштовувати URL (я звик до React Router, наприклад). Так, деякі пакети, до яких ти звик, треба встановлювати вручну. Але, зрештою, це — просто React із новими можливостями.

База даних

T3 Stack не каже вам, яку базу даних треба встановити. При встановленні create-t3-app встановлює SQLite. Бажаєте MySQL чи MongoDB? Потрібно встановити самому. Для зв’язку з базою даних використовується Prisma. Теоретично, можна встановити іншу ORM, проте в нашому випадку продовжимо з нею.

Якщо ми вибираємо NextAuth.js при запуску проєкта, create-t3-app автоматично створює схему бази даних, необхідних для цієї бібліотеки:

Усе, що потрібно зробити розробнику — запустити команду npx prisma db push і схема автоматично згенерується. Зверну увагу, що цю команду не варто використовувати в реальному проєкті. Для цього в Prisma є міграції.

Якщо потрібно швидко глянути на базу даних, напишіть npx prisma studio. Цей інструмент дозволяє швидко перевірити, які моделі вже існують у проєкті, і дає можливість їх редагувати.

Prisma — типізований модуль і в цьому його головна перевага. Функцію на сайті він виконує ту саму, що й Laravel Query Builder, проте синтаксис, мені здається, менш зручний. З іншого боку, підказки, які виникають від типізації, безцінні. Лише подивіться, що відбувається, коли я намагаюся оновити користувача:

IDE (у моєму випадку VSCode) знає про те, які можливі значення приймає модель User. По досвіду з React я знаю, що це може зекономити години в досить великому проєкті. Особливо це спростить роботу будь-якому новому розробнику, який намагатиметься розібратися в коді. Мені здається, що в Laravel це не буде можливим ще багато років, а тут це існує вже.

Висновок. Prisma має новий синтаксис, до якого треба звикнути після Laravel. Але типізація й автопідбір точно вартує цього.

Авторизація

NextAuth.js в цьому стеку мене, щиро кажучи, розчарував. З самого початку я планував створити сторінку логіну (емейл та пароль) та сторінку реєстрації (ім’я, емейл та пароль). Мені здавалося, що це доволі поширений спосіб створення авторизації, проте NextAuth.js так не вважає.

По-перше, NextAuth.js не має метода signUp. Якщо ти хочеш такий метод, маєш сам його написати. На думку авторів бібліотеки має бути лише один метод: signIn. І якщо користувач залогінився, а його не існує в базі даних — то відразу ж і створи його. Не маю нічого проти такого підходу, проте звичний потік це зламало. Це змусило мене залишити лише одну сторінку — логін. А замість повноцінної реєстрації — сторінка, де ти дописуєш свої дані, якщо ти вперше залогінився.

По-друге, бібліотека має дуже слабку підтримку входу за допомогою емейлу й паролю (credentials). Автоматично вона не створює запис в базі даних (при тому, що при авторизації через GitHub цей процес відбувається автоматично). Тому це все у твоїх руках. І в мене не було бажання створювати самостійно систему пошуку користувача, порівняння та хешування паролів, тому я обрав варіант авторизації через GitHub. Цей варіант вимагав від мене лише 29 рядків коду, які я просто скопіював з документації:

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

Ще є недолік, який варто згадати. Чомусь NextAuth.js не має функції, яка може оновити сесію на клієнті за твоїм бажанням. Коли користувач змінює дані про себе, логічно показати йому оновлений профіль, проте в бібліотеці стандартними способами це неможливо зробити. Мені в проєкті довелося створити функцію reloadSession самостійно, яку я успішно запозичив із StackOverflow.

Бекенд

tRPC — це зручний інструмент, який замінює звичний REST API. Зв’язок із бекендом стає набагато простішим. По-перше, тому що є типізація на сервері. По-друге, тому що ця типізація видна фронтенду автоматично, і для даних, які ми надсилаємо, і для даних, які ми отримуємо. Якщо ви не зрозуміли, про що я, то я спробую пояснити на прикладі.

До речі, tRPC можна використовувати разом із іншими фреймворками: Express, Fastify та іншими. Мені не доводилося це робити, проте я впевнений, що це важлива інформація для будь-кого, хто вже з ними працює.

У моєму додатку є форма, яка має оновлювати дані в профілі. І функція в tRPC з ім’ям profile.update за це відповідає:

У цій функції написано, що бекенд приймає { city: string, name: string } параметри (це валідація за допомогою zod), оновлює дані в моделі й нічого не вертає. Що розробник бачить, коли намагається викликати цю функцію? Перш за все, IDE турботливо вказує всі ендпоїнти, які є на бекенді. У тому числі, потрібний нам profile.update:

Вражаюче. Якщо ми збираємося надіслати цей запит, IDE допомагає нам зрозуміти, що саме ми можемо надіслати:

При вдалому запиті tRPC також показує той тип відповіді, який передбачається функцією. У нашому випадку void:

Висновок. Типізація бекенду і доступність цих типів під час розробки фронтенду — безцінна. Працюючи над React-додатком, який отримує дані від REST API, я часто писав типи самостійно. Проблеми виникали тоді, коли тип на фронті був або неповний (тому що я людина й міг помилитися або не знати всіх можливих відповідей), або він змінювався (тому що бекенд змінюється й змінюються задачі). Із tRPC ця проблема вирішується, тому що будь-яка зміна на бекенді автоматично відображається на фронтенді. Як результат, менше багів і швидша робота з API на проєкті.

Узагальнення

T3 Stack — це чудова можливість почати розробку з TS. І так, я знаю, це не простий стек технологій (знання TypeScript є однією з найбільшою перепон). Мій перехід з PHP-бекенду на TS-бекенд не пройшов так просто, як я би хотів. Напевне, це не буде просто й для вас. Я очікував, що поширені задачі типу авторизації можна буде зробити без проблем. Проте деякі аспекти розробки на нових технологіях не настільки очевидні, щоб розібратися в них без підготовки.

Незважаючи на це, T3 Stack та інструменти в ньому пропонують можливості, які будуть недоступні на Laravel роками. Як фулстак-розробник я особливо ціную, наскільки легшою може стати розробка, де обмін типами між фронтендом і бекендом є безперервним. Якщо за TypeScript майбутнє, то ці технології або технології, схожі на ці, точно будуть з нами. Варто на них звернути увагу.

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному9
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Якісна стаття, неочікувано бачити адептів T3 тут :D

TypeScript на беке для меня это нонсенс)

а давайте все писати на brainfuck?

класно б було щось типу Sr. full stack brainfuck developer на проекті з Minisoft Amur де NoShit DB )))

Тааааак. Я теж помітив в рекомендованих твою статтю. Те саме описали різними словами :)

Між іншим, я переклав релевантну статтю про Project references у TypeScript. Хоча ця фіча не нова, але далеко не усі про неї знають.

У версії 3.0 з’явилась одна із самих довгоочікуваних фіч TypeScript — це розумна поетапна (інкрементальна) побудова проектів. Щоб скористатись нею, потрібно використовувати опцію —build для tsc. Це фактично нова точка входу для tsc, яка поводиться більше як оркестратор збірки, ніж як простий компілятор.

для tRPC обязательно что бы бек и фронт были в одной репе?

Так, обов’язково

А якшо загорнути шарену логіку в окремий пакет?

І правда. У їхньому гітхаб пишуть, що так можна, якщо бекенд використовувати як пакет: github.com/...​rpc/trpc/discussions/1860

Я сам не пробував, тому деталей не знаю

Що заважає юзати nrwl/nx (angular + nest + typeorm) або (next + nest + prisma)?

То что типы описанные на сервере будут подтягиваться автоматически на фронте и не придётся их обьявлять там explicitly, так же мы получаем удобную абстракцию в форме react-query с заранее сгенерированными запросами под него и другой синтаксический сахар.
И prisma > typeorm, но это уже чисто имхо.

Помню раньше, лет 15 назад, ещё была шутка про то, что в будущем будут языки, которые будут компилироваться в JavaScript. И это звучало очень весело. Но теперь будущее наступило. :^)

Ну, написав ти бекенд. Може, воно навіть і робе якось. А шо з performance? Тести писати ок? Як довго білди збираються? Шо зі сторонніми лібами? Бо на тому ж таки Laravel уже давно своя екосистема — і міграції, і адмінки, і шо тільки хочеш.

Я так і не побачив з якою проблемою довелось зіткнутися і як її вирішив TS. ШОБ ШО?
Але якшо це аутсорс, який продав клієнту бекендера і фронта, а сам намагається знайти чувака, який готовий косо-криво, але буде фігачити за двох — ну, такоє...

Зразу відчувається що питає РНР-шник, в якого підгорає від того, що JavaScript/TypeScript поступово витісняє РНР із бекенда. А ще якщо порівняти середні зарплати розробників хто пише на PHP, із зарплатами розробників, хто пише на TypeScript, то виявиться що другі заробляють на $1000 більше щомісяця. Як це пояснити?

Що стосується перформенсу, то РНР може виграти хіба що у випадку великої кількості паралельних запитів, при умові що оперативна пам’ять необмежена. Але підозрюю, що в такому проекті тоді вже буде краще використати якийсь Go.

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

Зразу відчувається що питає РНР-шник, в якого підгорає

Нічого в мене не підгорає. Так склалось історично, шо я пишу на PHP і не бачу в цьому нічого поганого, мене все влаштовує. Можу ще на Go і Python писати, а на JS (vue + vuex + vite) написав клієнську частину одного стартапа, який мав би запуститись уже, але війна внесла свої корективи.

Але я уже зрозумів, шо ви не вмієте мислити абстрактно і постійно прив’язуєтесь до реалізації.
Код, думаю, ви так само пишете.

заробляють на $1000 більше щомісяця

Начали за здравіє, а кончили за упокой.

Що стосується перформенсу, то РНР

При чому тут PHP взагалі? А якби у мене в профілі був С++ вказано, шо б ти тоді казав?

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

Бібліотек для форматування дат і нормальної роботи зі строками — можливо. А шо з ORM і роботою з міграціями? Ми ж про бекенд говоримо. Бо те, шо я бачив, м’яко кажучи, дуже бідно виглядало в порівнянні шо з Doctrine, шо з SQLAlchemy.

З дурнем спорити — себе не поважати. Тому я з тобою не буду спорити, чувак.

На все ваши толковые вопросы по поводу плсюсов разработки на ТС — ответы отрицательные. Язык и фреймворки бедные, а типы — понты для приезжих.

Але то дійсно цікаво подивитися на різницю performance backend на TS і інших популярних мов програмування.

Ти шо PHP-ник чи шо? А скільки ти заробляєш?

А ще якщо порівняти середні зарплати розробників хто пише на PHP, із зарплатами розробників, хто пише на TypeScript, то виявиться що другі заробляють на $1000 більше щомісяця. Як це пояснити?

З точки зору кастомера — це недолік TypeScript.

З точки зору «кастомера» — будь-яка плата це недолік, але він таки платить більше тим, хто пише на TypeScript.

А шо з performance?

Nodejs від пошвидше лаварелу буде. Тай паралельних запитів в xxxx разів більше витримує. Як мінімум через asyncio.

Тести писати ок?

Так як і всюди. Однаково.

Шо зі сторонніми лібами?

Їх значно більше, ніж на php.

Я так і не побачив з якою проблемою довелось зіткнутися і як її вирішив TS. ШОБ ШО?

Шоб перформанс і шоб не мурдуватись зі всякими 3rd party лібами. Бідьшість всяких сервісів лають оф апі ліби для яваскрипта, пітону, яви.. а для пхп тільки якісь сторонні, і фіг зна як підтримуються

Розумію, про що ти. Сам не впевнений, що можу зробити на Node усі завдання, які би я зробив за допомогою Laravel. Не хочу, щоб стаття звучала так, ніби робота з JS 100% краще. Проте для маленьких-середніх проєктів з типовими завданнями JS справляється чудово й типізація — дуже зручна фіча. По суті, це самодокументація коду, яка ще й автоматично підсвічує помилки під час розробки. Замінив об’єкт на бекенді — на фронті тобі показує, на що це вплинуло.

Проте для маленьких-середніх проєктів з типовими завданнями JS справляється чудово

Навпаки — чим більший проект, тим більша ймовірність що у ньому потрібно робити загальну (не залежну від роутів) початкову ініціалізацію різних файлів, конфігів і т.д. А із цим значно краще справляється JS у порівнянні із PHP, бо PHP приходиться за кожним запитом робити цю роботу, тоді як JS може робити це єдиний раз під час старту веб-сервера.

А якщо ще й врахувати статичну типізацію TypeScript... щоправда я не працював із типізованою PHP... хоча дуже сумніваюсь що у PHP на стільки добре розвинуті типи як у TypeScript.

Я працював з типізованим PHP, старався перенести свій досвід з TypeScript у Laravel. Деякі речі працюють і це зручно, проте це далеко не настільки зручно як TS, так

Я працював з типізованим PHP

* PHP — вона, бо це мова (а не язик).

Те саме — це мова програмування.

про яву тільки хороше, або нічого.
ява — «вона». а пайтон — він. Ада — вона, брейнфак — він.
Я полюбив брейнфак і пишу тільки на ньому.
Я полюбив мову «брейнфак» і пишу тільки нею.

А як казати про соняшник? Він же рослина, а «рослина» — слово жіночого роду.

До речі як православно — ява чи джава?

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

Дотнет теж так вміє

Не сумніваюсь. А PHP не вміє.

В смислі? А як же reactphp, swoole і їм подібні? Он в останніх версіях ще й fiber-и підвезли на додачу.

Виглядає цікаво. Востаннє, коли цікавився темою, були проблеми то з кешуванням нормальним, то з table inheritance, то з композитними ключами, то зі складними вкладеними запитами, то ще з чимось.

у нас бек на Nest.js (на express, не fastify даже) на TS вывозит на изи, как правило ботлнеки уже в конекшене с БД происходят, но это при лоадтестах, в продакшене в пиках очень редко

Все просто, на typescript просто приємніше писати, набагато зручніше ніж на php.

Тайпскрипт и типизация это кек)

Если

Тайпскрипт и типизация это кек)

то JS это лол.

Prisma же вроде про GraphQL было? Направление проекта совсем поменялось? WTF?

Правильно сделали. Как у очередной поделки для графкуэля перспектив у проекта не было.

Prisma ніколи не була про GraphQL. Це ORM з власним DSL для опису схеми бази

Ага кончено. А „Build a GraphQL server with any database
Prisma is a performant open-source GraphQL ORM-like* layer doing the heavy lifting in your GraphQL server.” они на сайте просто так писали. web.archive.org/...​23/https://www.prisma.io

Prisma на старті була виключно GraphQL біблою.

На скільки я зрозумів, після швидкого огляду, — проект являє собою немодульний моноліт. Якщо ви хочете писати щось зовсім маленьке, це — ОК. Але для більших проектів краще знайти якийсь фреймворк, що заточений саме під модульність. Це вам дасть змогу поступово масштабуватись, і згодом, якщо виникне потреба, плавно і безболісно перерости у мікросервіси.

Зараз NestJS мабуть є найпопулярнішим NodeJS-фреймворком, написаним на TypeScript. От він — модульний, і також має CLI, завдяки якому можна будувати блоки вашого застосунку з командного рядка. Він має ще й Dependency Injection (скорочено — DI), який дає відчутну перевагу над фремворками без DI. До речі, NestJS досить часто використовують для мікросервісів.

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

Вважаю свій фреймворк Ditsmod досить перспективним. На мою думку, він значно краще спроектований за NestJS, також має модульну архітектуру, має DI, інтерсептори, routes guards, та ще й розширення (тобто плагіни, чого у NestJS поки що немає).

Мені NestJS дуже подобається. Я пробував працювати з ним, зробив міні-проєкт. Проте, наскільки я розумію, між NestJS і фронт-енд фреймворком не має автоматичного зв’язку щодо типів. Потрібно вручну писати типи для запитів до бекенду. Це не критично, я це роблю вже багато років, проте саме ця фіча мене дуже цікавить.

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

Проте, наскільки я розумію, між NestJS і фронт-енд фреймворком не має автоматичного зв’язку щодо типів.

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

Справедливо, ти правий.

Мені в tRPC ще подобається, що я навіть і не писав типи. Багато речей визначаються автоматично. По факту, типи написані тільки для моделей в Prisma. Валідація даних відбувається за допомогою zod (одночасно валідація + типізація). Тип, який повертається з ендпоїнта, теж визначається автоматично. Я ніде не писав type StoreUserResponse чи щось таке. Це трішки економить час. Принаймні я не знаю, як такого ефекту досягти в NestJS.

Із мого досвіду мені ще в NestJS подобається структуризація проєкту. Тобі точно кажуть, які частини сайту куди належать. Це полегшує роботу, якщо тобі потрібно запустити новий проєкт чи розібратися з новим. Такого не існує в t3 стеці, що шкода.

Мені в tRPC ще подобається, що я навіть і не писав типи. Багато речей визначаються автоматично. По факту, типи написані тільки для моделей в Prisma. Валідація даних відбувається за допомогою zod (одночасно валідація + типізація). Тип, який повертається з ендпоїнта, теж визначається автоматично.

А документація OpenAPI (раніше відомий як Swager) генерується по тим типам?

Скучаю по тем временам, когда на фронтенд можно было кого угодно отправить и он не облажается, потому что там было все элементарно на JavaScript + JQuery. Сейчас там вынос мозга и абсолютная Redux Saga на TypeScript-e.

Якщо взяти сучасні фреймворки, типу React, Angular, і порівняти їх із jQuery, то вони не просто так ускладнюють код проектів, а ще й дають неабиякі переваги. Що раніше писалось на jQuery? — Форми, що відправляються на Ajax, чи кнопочки, які змінюють текст після натискання, чи ще якісь дрібниці. Якщо писати такі самі дрібниці на сучасних фреймворках, то дуже навряд чи код у них буде складним.

Так, я з цим згоден. Тільки якщо туди не добавляти Redux.

Ага, дехто Redux парить навіть на Angular-проектах. Це мабуть роблять ті, хто погано уявляє собі як працює DI, а тим більше — ієрархічний DI, який якраз розподіляє один великий об’єкт, де зберігається стан застосунку, на окремі компоненти...

то вони не просто так ускладнюють код проектів, а ще й дають неабиякі переваги
дехто Redux парить навіть на Angular-проектах

Шось не сходиться.

Якшо redux — це те ж саме, шо і vuex для vue, то я просто не розумію, як можна писати великі проекти без нього. Ну, може, хіба які google docs чи шось подібне, де за кожну соту секунди швидкодії паряться.

В чому проблема підключити redux і користуватися всіма його плюшками, до яких всі звикли? Воно шо — їсти просить?

Я не фронтендер і не в темі, питання абсолютно серйозне.

Як я і написав вище, в контексті Angular немає сенсу використовувати Redux, бо у нього є сервіси + DI для управління станом. Думаю його затягують в Angular ті техліди, які добре знають Redux, бо працювали із React, наприклад, і які погано знають Angular.

Більш точне обговорення буде якщо ви наведете конкретну задачу, яку буде важко вирішити без згаданого вами Vuex.

Я думав, шо DI — це про залежності, а не про стан. З Angular не працював, можливо, там в цьому і є сенс, але поки важко усвідомити в чому перевага такого підходу.

Наведіть конкретний приклад, бо без цього ми один-одного не зрозуміємо.

Я в принципі без прив’язки до мови програмування.

Наведіть конкретний приклад
Більш точне обговорення буде якщо ви наведете конкретну задачу

Ви вмієте мислити абстрактно взагалі?

Ви вмієте мислити абстрактно взагалі?

Так.

Більш точне обговорення буде якщо ви наведете конкретну задачу

Хто вам сказав, що не можна використовувати абстракції? Чи ви не розумієте як можна конкретну задачу показувати із певним рівнем абстракції?

Тільки якщо туди не добавляти Redux.

Вряд ли эту логику, вокруг которой все у них там крутится, можно называть мудреной:

function createStore(reducer, initialState) {
    let state = initialState
    return {
        dispatch: action => { state = reducer(state, action) },
        getState: () => state,
    }
}

Для настоящего Ъ-TypeScipt Redux-a на любое, даже самое просто действие нужно написать 100 строк кода вместо трёх. Там нужен Reducer файл поправить, там нужно Action файл поправить, там нужно Saga файл поправить. Огромное количество очень плохо читабельного boilerplate кода + практика показала, что этот boilerplate умеет выдавать очень мозговыносящие ошибки, которых на стековерфлоу нет. Это как AbstractSingletonProxyFactoryBean.

Вот это вот написано на jQuery, например
www.realmofempires.com

Вы так говорите, потому-что просто не работали на фронте в то время, скорее всего.

Хоча я справді більше бекенд розробник, але дещо пописував і на jQuery, десь у 2010-2014, аж до першої версії AngularJS.

Ведь куча крутых ВебАппов написана вообще задолго до фреймворков текущих.
Взять Gmail (2004), Gmaps (2005), Gdocs (2005), StreetView (2007).

Как был ЖС так и остался, либу ЖеКвери заменили на реакт + обмазались либами. Джуну сложно освоить, но джун бы и с ЖС + ЖеКвери налажал бы. Норм разраб доки почитает и пойдет лабать)

Підписатись на коментарі