Developing decentralized chat with Next.js [ukr]

Так, всім привіт. Мене представили. Зразу переходимо до найважливішого. І мене дуже часто запитують, чи блокчейн – це важко, чи потрібно знати якісь суперспецифічні мови, наприклад, солідіті, чи може треба поглиблюватися в Rust. І взагалі, можливо, потрібно знати якусь темну магію для того, щоб побудувати щось з блокчейном. Але я завжди відповідаю, і бачу, що інші розробники також відповідають, що не обов'язково. Я побудував чат за 90 хвилин, за годину, використовуючи чистий JavaScript. І після цього все стає простіше. Сьогодні я хочу пояснити і показати, що для будівництва та роботи з блокчейном, для створення децентралізованих рішень, не обов'язково знати які-небудь дуже специфічні мови або матеріали. Достатньо мати JavaScript і трошки того, про що ми зараз поговоримо. Почнемо.

Перше, що потрібно знати – це блокчейн-бази. Без них нікуди. Це схоже на те, як ми вивчаємо front-end із найпростіших речей, таких як HTTP. Тут так само. Сьогодні ми швидко пройдемо їх і перейдемо до загальної концепції будівництва децентралізованого чату. Почнемо з того, що таке блокчейн взагалі. Коротко кажучи, це децентралізована розподілена база даних, яка зберігає свої дані у цепочці блоків. Для того, щоб додати нові дані у цю цепочку, потрібно пройти певне голосування, досягти консенсусу з великою кількістю учасників мережі. Зокрема, 51% учасників мережі повинні підтвердити, що ці дані коректні і можуть бути додані до блокчейну.

Ці кроки добре демонструють процес. Допустимо, Еліс хоче відправити Бобу певну кількість токенів або виконати певну транзакцію. Ця транзакція включається у блок, який розсилається всім учасникам мережі. Вони підтверджують транзакцію, і після цього вона додається до цепочки. Інші учасники мережі можуть переглядати цю транзакцію, яка передається від одного учасника до іншого. Внутрішній вигляд блоку приблизно виглядає так: номер блоку, хеш конкретного блоку, посилання на його батька. Ми можемо пройти по всій цій цепочці, і таким чином вивчати, що відбувається.

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

Також є частина, відома як архів, яка зберігає повний ланцюг блоків, дозволяючи інтегруватися. Не всі блокчейни мають архіви, але в більшості, таких як Ethereum, вони існують. Іншою важливою частиною є RPC (Remote Procedure Call), яке ми можемо бачити в звичайному веб-2 світі бекендів. Це просто сервіс, який об'єднує комунікацію між клієнтом, валідаторами та архівами, дозволяючи відправляти та отримувати дані з блокчейна.

І він зазвичай максимально оптимізований, легкий і зберігає лише останні 200-300 блоків блокчейну, а не весь стейт, який накопичився протягом 5-10 років функціонування мережі. Тобто вони досить легкі. Перший спосіб комунікації - використовуючи типові, всім відомі протоколи, такі як HTTP і TCP, огорнуті вебсокетами, зазвичай, для комунікації з RPC-нодами. Якщо дивитися, найпростіший спосіб - це викликати curl, простий запит, в якому будується наш JSON-RPC з певним методом, і це повертає нам якийсь результат. Але з часом з'являється питання, коли нам потрібні параметризовані стейти, якщо ми витягуємо які-небудь параметризовані дані, і нам потрібно працювати з параметрами. Параметри в блокчейні часто хешуються, оскільки блокчейн використовує багато криптографії та хешувань для ефективного та надійного зберігання цих даних.

Для найшвидшого виконання IPI блокчейну підтримує лише вже готові захешовані дані у формі, в якій він може звернутися до своєї бази і дати вам результат. Постає питання, як це комунікувати та конвертувати дані на фронтенді. Звісно, жоден фронтендер не хоче глибоко розбиратися в тому, як працюють хешування самого блокчейна. Тому було створено вже багато готових SDK, які роблять цю роботу за вас. Перша робота, яку SDK може виконати за вас, - це обгорнути сам запит, подібно тому, як ми робимо curl або Axios з нашими звичайними HTTP-запитами. Наприклад, бібліотека Polkadot API робить це для нашого блокчейна. Ми підключаємося, чекаємо на провайдера, ініціалізацію, і потім відправляємо запити.

Тут ми також маємо хешувати дані самостійно. Потім ми переходимо до більш високорівновідних бібліотек, таких як Web3.js - найпопулярніша бібліотека в світі Ethereum, якщо хтось чув про неї. Це другий за популярністю блокчейн. Тут все набагато простіше. У нас є чіткі методи, які ми звикли бачити в JavaScript, в скриптах, наприклад, getBalance, де передаємо адресу та отримуємо результат. До речі, цікавий аспект - блокчейн не працює з числами з рухомою комою, як це роблять банківські системи. Тому що рухома кома допускає похибку, що є неприпустимим при роботі з монетами, токенами чи банківськими операціями. З часом блокчейн еволюціонує, і ми доходимо до того, що з'являються високорівновідні бібліотеки, які дають нам можливість не думати про те, як це працює під капотом, а просто використовувати блокчейн, подібно до Twitter API чи Google API, де ми завантажуємо бібліотеку, вказуємо вхідні дані, і отримуємо необхідні дані з блокчейну.

Цей API ми використаємо сьогодні для отримання постів в блокчейні, тобто наших повідомлень у чаті. Наступна частина того, що ми робимо з блокчейном, - це ключі. Кожен блокчейн працює на асиметричному шифруванні, де ми маємо ключ-пару з публічним та приватним ключем. За допомогою цієї пари ми відправляємо транзакції в блокчейн, комунікуємо з ним, отримуємо дані і т.д. Тут трошки потрібно розібратися в тому, за що саме відповідає кожен ключ. Публічний ключ - це наш ідентифікатор в мережі, схожий на користувач-айді чи користувацьке ім'я в звичайних бекендах. Його можна безпечно передавати комусь, це фактично як номер вашої банківської карти, припустимо, без всіх інших частинок. З його допомогою можна валідувати підпис, який генерується за допомогою нашого приватного ключа, який, в свою чергу, зберігається тільки у вас, і ніхто крім вас не повинен знати його. Якщо хтось дізнається про нього, можна вважати, що він знає всі дані вашого банківського рахунку, банківської картки та інше.

І за допомогою приватного ключа ви підписуєте транзакцію, створюєте цей криптографічний proof of identity, і блокчейн, чи будь-який інший сервіс, може, за допомогою знаючи ваш публічний ключ, перевірити, що це дійсно ви поставили цей підпис. І тут є невеличка схема. Найчастіше фронтенди комунікують з блокчейном і, використовуючи публічний ключ, private key двома способами. Перший – це за допомогою гаманця, це може бути метамаск в вашому браузерній екстенсії, це може бути умовно леджер, флешка якась, яка підключається до вашого пристрою.

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

Друга частина – коли фронтенд знає ваш ключ, ви повинні повністю довіряти своєму фронтенду, оскільки ключ зберігається в local storage, local db, може бути зашифрований чи не зашифрований, це вже інше питання. Але суть в тому, що фронтенд без вашого відома може вас не запитувати і підписувати дії від вашого імені, оскільки він знає ваш приватний ключ і може взаємодіяти з мережею майже без вашого відома. Однак, якщо ви довіряєте і цей додаток не є якоюсь підставою, він буде запитувати ваші дії і взаємодіяти з вами, щоб пояснити, що відбувається з вашим ключем.

І коротко, як можна описати блокчейн зараз? Це не біткоін, в якому є тільки одна функція трансфера і навіть можливість перегляду конкретного блоку, а лише просування по всьому ланцюжку і зберігання його в якійсь пам'яті. Зараз це Ethereum, Polkadot чи будь-який інший популярний блокчейн, який часто зустрічається у топ-10. Можна порівняти його з конструктором Lego, але він має комісію. Ця комісія - основна особливість блокчейну, яка робить його відмінним від публічних API, які існують. В тому розумінні, що ви можете безперешкодно взаємодіяти з блокчейном, надсилати в нього будь-які дані, і ніхто не може цього заборонити, він абсолютно публічний, ви можете зібрати свій конструктор Lego та побудувати свій власний додаток. Часто в блокчейнах вже є готові модулі, наприклад, той, який ми розглядаємо сьогодні, в якому вже є готові модулі для будь-яких соціальних мереж. Тут є пости, коментарі, підписки, імена користувачів, профілі, реакції. Але для того, щоб записати щось в блокчейн, вам потрібно заплатити комісію, витратити частину свого токену, який повинен бути на вашому балансі, у вашому гаманці.

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

І перше, про що я хочу поговорити - це типи рендерів. В React та Next.js їх є чотири. Перший - це те, що ми вже добре знаємо, а саме client-side render. Будь-яка односторінкова аплікація, побудована за допомогою Create React App, використовує цей тип рендеру, де JavaScript-бандл повністю ініціалізується на frontend, завантажує всі дані на frontend та рендерить для кожного користувача. І це працює, але люди звертаються до Next.js в першу чергу, коли хочуть щось більше. Наприклад, потрібна швидша віддача контенту на сторінці чи SEO-оптимізація, щоб пошуковики краще відображали контент вашого сервісу.

Тоді приходить на допомогу SSR (Server-Side Rendering), який був популярний задовго до client-side rendering. Будь-яка сторінка, наприклад, у 2090-х, працювала через Server-Side Render, де якийсь PHP чи Java генерували HTML і відправляли його на frontend. Основна ідея тут в тому, що якщо це динамічні дані, які ви отримуєте з бази даних чи з блокчейну, то для кожного користувача ми витягуємо конкретний набір даних. Тобто під кожного користувача ми витягуємо конкретний масив даних, який може повторюватися, якщо ви відкриваєте одну і ту саму сторінку. Однак він підгружується для кожного окремого користувача.

Це відкриває можливість для кешування, але з кешуванням завжди пов'язані питання, коли його потрібно оновлювати, і потрібно активно керувати цим процесом. Тому Next.js трошки вдосконалив цей підхід, додавши так званий incremental static regeneration (інкрементальна статична регенерація). Коли у вас є статичний сайт, як, наприклад, лендінг-пейдж, який повністю побудований за допомогою тільди чи Webflow і має вже готові дані, які підгружені з блокчейну, вони підгружаються один раз. Проте що 2, 3, 5, 10 секунд після цього, вони оновлюють ці дані і зберігають готові статичні файли на бекенді. Кожен користувач отримує готові статичні дані, це зменшує кількість запитань до блокчейну, оскільки дані вже готові, і блокчейн самостійно їх перевіряє.

Це основний фактор, за який я особисто ціную Next.js, оскільки він дозволяє дуже легко реалізувати цю концепцію. Ми розглянемо це докладніше під час розробки зразків коду. Другий важливий аспект - це добре визначена структура. Як і в багатьох високорівневих фреймворках, Next.js накладає свої власні правила і структуру, і якщо ви їх дотримуєтеся, ви отримуєте всі його переваги і бонуси. Перший з них - це динамічний роутінг. Вам не потрібно вручну вказувати роути, вони виникають на основі структури вашого проекту в папці 'Pages'. Якщо у вас, наприклад, API слеш 'Create User', то саме за таким роутом ви зможете звертатися. Якщо є 'Space ID' - це статичний роут, і ви також можете побудувати статичний роут для нього

І тут також важлива особливість - це Main Wrapper для всього аплікаційного коду, який обгортає кожну частину коду, що є однаковою для всіх сторінок вашого додатка. Це може бути конфігурація теми, провайдер Redux чи підключення скриптів, а також хедер. Цей 'Main Wrapper' рендериться один раз при відкритті сторінки і не перезавантажується при переході між сторінками, що зменшує кількість необхідних запитань до сервера.

Ще однією корисною можливістю є оптимізація зображень. Недавно в Next.js була додана вбудована підтримка оптимізації зображень. Це вирішує проблеми, такі як великий розмір файлу, адже картинка важить 2 мегабайти, і я хочу використовувати її як аватар, але мені потрібно її зменшити. Також вирішується проблема лейаута, коли картинка підгружається, але я не хочу її завантажувати, поки користувач не докрутився до неї. Всі ці проблеми обробляються компонентою 'Image' від Next.js, яка взаємодіє із своїм власним бекендом і робить всю цю роботу за нас. Ми просто використовуємо її там, де це потрібно - вставляємо картинки, які нам необхідні.

І ще одна останній кусок, аналогічний до App.js, основний враппер, лейаути, які дозволяють використовувати частини коду, придатні для багатьох сторінок, але не обов'язкові на кожній сторінці. Наприклад, хедер і футер. Футер може бути на домашній сторінці, а хедер може з'явитися лише на двох сторінках. Якщо ви переходите від домашньої сторінки до сторінки зі списком ланцюгів, хедер не буде рендеритися знову; він залишиться таким, яким він був на першій сторінці. Це дає нам перевагу в оптимізації швидкості рендеру. Ось основні речі, які я хотів розповісти щодо фронтенд-частини.

І, ще є ще один аспект, через який я люблю App.js для невеликих проектів, MVP та інших швидких і неважких справ - це опір. Фактично це свого роду внутрішній бекенд в нашому Next.js додатку. Він обмежений, але більшість завдань, які вам можуть знадобитися, він вирішує. Потрібен сервер Apollo для GraphQL? Без проблем. Потрібен обмежувач швидкості (rate limiter) для API? Добре. Можливо, вам треба працювати з куками, корсами? Все це теж працює досить легко. Я ще навіть не згадую про базу даних, блокчейн і подібні речі. Все це досить просто. Але якщо вам потрібно щось трошки складніше, додати середні шари, якісь додаткові обробники подій і таке інше, то вже буде трошки складніше. І ви можете побудувати свій власний сервер для Next.js. Але, особисто якщо я розумію, що мені потрібно щось складніше, я беру Next.js і будую власний чистий сервер, який я вже просто підключаю до фронтенд-частини Next.js, і все гаразд. Тепер переходимо до розробки. У нас сьогодні стек: я взяв SSR для обробки запитів, які ми будемо отримувати з блокчейну; TypeScript, бо без нього мені... Оскільки робота з блокчейном насправді трошки важка, оскільки він часто змінюється. Це реально постійно оновлюється. Додаються нові бібліотеки, типи і конвертери. І без TypeScript важко тримати крок із цим, особисто для мене.

Для стилізації я використовую Tailwind, щоб не думати занадто багато про CSS, який, як мені розповіли, мені не дуже подобається. Ну і Subsource SDK - це SDK для високорівневої комунікації з нашим блокчейном. Повний репозиторій з кодом можна побачити на цьому скріншоті, або перейти за іменем користувача olehmelsubid, що перенаправить вас на мій GitHub. Там, серед закріплених повідомлень, ви знайдете репозиторій Decentralized Chat. Ви можете його відкрити, форкнути і використовувати, враховуючи, що є інструкції, які дозволяють вам спробувати це самостійно у майбутньому.

І зараз починаємо. На самому початку, зауважте, що ми не будемо вести лайфкодинг, ми просто проглянемо основний код, який невеликий. Я вже видалив усю частину, що стосується React, і зараз ми зосередимося на частині взаємодії з блокчейном. Перше, що нам потрібно зробити в чаті, - це підключитися до нашого блокчейну. У нас є функція create, і буде init, можливо, в іншій бібліотеці, чи просто в конструктор буде передаватися параметр. Але в загальному це передача трьох стрічок, які під капотом отримують з'єднання.

Тут ми також бачимо ще одну річ, яку зветься IPFS. Зазначте, що вона не є частиною блокчейну, це окрема файлова система, також децентралізована, що ґрунтується на хешах. Кожен контент має унікальний хеш, який зберігається в кількох вузлах, подібно до технології BitTorrent. IPFS часто використовується блокчейнами для зберігання великих об'ємів даних, таких як зображення чи відео. У порівнянні із завантаженням цих даних безпосередньо в блокчейн, використання IPFS коштує гораздо менше. IPFS може використовуватися для авторизованого доступу, і для цього ми часто використовуємо звичайний токен, такий як Basic, Bearer або JWT, з відповідними заголовками, які широко використовуються для типових бекенд сервісів. Ми здійснюємо підключення, отримуємо API, можемо додати якусь кешування, якщо потрібно, і далі постає питання, як ми отримаємо наш блокчейн, як ми отримаємо наші дані.

Підключаємося до блокчейну за допомогою GetSocial API, в якому ми витягуємо Substrate API. Тут це низькорівневий API, який, як я показував раніше, FinePost - це вже врапнута система зверху. Але для того, щоб отримати, наприклад, ID-шники, нам потрібно використовувати трошки більш низькорівневу частину бібліотеки. Ми підписуємося за допомогою Channel ID, передаємо колбек для нашої підписки, отримуємо ID-шники, і тут у нас виникають певні труднощі через типи даних в блокчейнах. Наприклад, якщо це ID-шники, то зазвичай це U64, але може бути і I32, або щось інше. В JavaScript це досить важко розуміти, і хоча бібліотеки часто надають конвертацію типів, ми іноді повинні явно вказати очікуваний тип.

Ми також можемо додати валідацію, щоб перевірити, чи типи співпадають. Це схоже на роботу з звичайним API, де ми отримуємо JSON і повинні перевірити типи рядків. Також можна використовувати TrueToPermit, яке по суті є масивом стрінгів, і тут можна було б додати валідацію, але ми цього не робимо. Мутація відбувається в нашій бібліотеці SVR, але ми не будемо розглядати це тут. Якщо комусь це буде цікаво, я можу поділитися кодом в Дискорді. Ми робимо звичайну підписку в UseEffect з колбеком і функцією мутації, яку ми слухаємо, щоб отримати нові ID через цей канал. Наш масив оновлюється, і ми його знову записуємо в наш кеш. Звісно, не забуваємо про Unsubscribe. Наступна частина - логінізація. На початку ми обираємо між логінізацією через гаманець або через зберігання даних в базі даних.

Якщо це гаманець, то ми використовуємо бібліотеку екстеншена, таку як MetaMask чи Polkadot Extension Dapp, яка надає доступ до всіх екстеншенів, які підтримують цей стандарт. Ми ініціалізуємо WebTreeEnable, перевіряємо, чи вони не пусті, і тоді намагаємося отримати з гаманця екземпляр для підпису транзакцій. Інша опція - генерація власного облікового запису, для якого ми використовуємо криптографічні бібліотеки для побудови ключової пари. Головна історія полягає в тому, що ми генеруємо мнемоніку, текстове представлення приватного ключа, щоб полегшити його запам'ятовування.

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

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

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

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

Наприклад, коли ви відправляєте повідомлення в мовному чаті в Telegram, ми часто передаємо повідомлення не одним довгим текстом, але поділяємо його на 10-15 менших повідомлень. Особисто мені не подобається, коли спілкування ведеться таким чином, тому я прошу вас утримуватися від цього стилю, але інколи він використовується. У блокчейні кожна така транзакція - це новий нанс, і вам потрібно створювати чергу на стороні клієнта, яка самостійно інкрементує ці нанси. Це через те, що блокчейн має час блоку, і якщо ви відправляєте 10 повідомлень за 2 секунди, а блокчейн формує блок кожні 6 або 30 секунд (залежно від блокчейну, наприклад, у Ethereum), то ваш нанс оновиться тільки після завершення цього блоку, коли блокчейн вже буде в курсі. Вам потрібно самостійно зберігати це на клієнті. У нашому випадку бібліотека вміє автоматично вирішувати це на своїй стороні.

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

Ми також отримуємо дані для транзакції, як ми це робили з енергією. Ми генеруємо поста, вивчаємо RAM, переглядаємо документацію. У нашому випадку, це Space ID, Extension, Content. Блокчейни мають добру документацію, без якої вони вважаються мертвими. У нас також є сторінка, як IPFS, де контент зберігається, а отриманий ID IPFS передається в якості хеша в нашу транзакцію. З цього моменту транзакція вважається виконаною.

Не забувайте, що користувач повинен мати фі. Її потрібно генерувати чи спонсорувати. Ми відправили все, але наш чат грузиться повільно. Це може бути пов'язано з підгрузкою, тому що вона залежить від клієнта. Давайте оптимізувати його. Ми обрані за те, що любимо NGS, оскільки вони дозволяють оптимізувати SSR-рендерінг. У нас є функція, яка підгружає дані, ми передаємо їх у бекендові пропси функції. На фронтенді ми використовуємо API для отримання цих пропсів. Це наш сервер-сайд пропси, які ми завантажуємо для кожного клієнта. Це наші статичні пропси з валідацією кожні 2 секунди. Різниця між ними майже ніяка, але DexJS дозволяє дуже швидко використовувати той спосіб рендерінгу, який вам потрібен для даної сторінки. Якщо потрібен динамічний рендерінг, це теж не проблема.

Якщо вам потрібно швидко відобразити сторінку без проблем, особливо, якщо це статична сторінка, DexJS - це відмінний вибір. За допомогою DexJS ви можете вибирати тип для кожної сторінки, уникаючи необхідності реалізації чотирьох різних варіантів для SPI-додатку. Таким чином, при роботі з різними сценаріями DexJS стає великим допоміжним інструментом. Щодо передачі даних, різні бібліотеки вимагають різних підходів. Наприклад, при використанні Redux або SVR, деякі бібліотеки вимагатимуть серіалізації даних для передачі їх на бекенд і з бекенду на фронтенд, а потім розпаковки для ефективного взаємодії з ними. Це зазвичай визначено в документації.

При використанні SVR у нашому випадку, ми отримуємо дані з блокчейну, створюємо об'єкт за допомогою функції з бібліотеки, яка збирає об'єкт за складним ключем, і передаємо це фолдбеком. Потім цей фолдбек передається в наш конфіг. Здається, що це все, і весь код доступний на моєму GitHub. Я також доступний в Telegram для обговорення, або ви можете знайти мене на GitHub. Чекаю на ваші питання!