Description:
В ході даної роботи було проведено дослідження на задану тему та
покроково виконано завдання. У першому розділі проаналізовано предметну
область та проведено огляд найбільш популярних парадигм програмування:
імперативну та декларативну. Було проведено порівняння функціональної
парадигми з ООП з установленням спільних та різних властивостей.
Озброївшись інкапсуляцією, успадкуванням та поліморфізмом, ООП
дарувало надію на спрощення процесу створення нових програм. Спільнота
розробників ПЗ надовго визнала методологію ООП істиною в останній
інстанції, і з появою Java ця практика лише закріпилася. Проте недоліки
методу з часом ставали дедалі очевиднішими. Жорсткі ієрархії об'єктів та
відсутність чітких характеристик класів помітно затримували еволюцію
ООП. Поступово невизначеність поширилася на всі без винятку складові
елементи
програмування,
отже,
не
обходиться
без
небажаної
взаємосумісності і непередбачуваних побічних ефектів.
Функціональна парадигма програмування - це набір концепцій, правил
та абстракцій, що визначають стиль функціонального програмування.
Відповідно до них, функціональний підхід передбачає розбиття коду на
функції та прагне до використання лише чистих функцій. Тобто цей стиль
спрямований на більш зручний поділ частин програм. Це спрощує розуміння
коду для людей, які його не писали. Чистота функції, коли її виклик просто
повертає результат, а не пише і не посилає емейли на пошту, дуже допомагає
в цьому. Чітко окреслені контракти та невеликі стейтлес модулі -
найпростіші та зручніші в роботі з ними. Функціональний підхід лише
розвиває цю ідею до логічної точки — всі функції мають бути чистими, і не
залежати від будь-якого стану.
Виявлено, що дисципліни ФП та ООП не є взаємовиключними. Можна
писати об'єктно-орієнтовані функціональні програми, і навпаки, принципи та126
патерни ООП можуть використовуватись у функціональних програмах, якщо
прийняти дисципліну «вказівників на функції». Не обов'язково робити весь
сайт або додаток на ФП. У місцях з логікою можуть бути деякі комбіновані
розрахунки, де ООП незручне. Доведено, що процес веб-розробки нині
полягає в декомпозиції задачі на складові частини, створенні компонентів
для вирішення цих складових частин та зворотній збірці в єдиному додатку. І
щоб встигнути в стислі терміни надавати споживачам продукцію з майже
необмеженими можливостями, треба робити це досить швидко. Набагато
простіше впоратися з таким завданням, коли програми що розробляються
можна умовно розділити на кілька чистих функцій, перевірити які не складає
труднощів. У таких алгоритмах немає побічних ефектів та абстрактних
формулювань, розрахованих на результати у глобальному масштабі.
У другому розділі проаналізовано розвиток та становлення мови
JavaScript з огляду функціонального підходу. Наведено особливості
сучасного використання функціональної парадигми та оглянуто механізми і
можливості зміни програмної парадигми при інкапсуляції функціонального
підходу у JavaScript. Було доведено, що JS – мультипарадигмова, тобто
універсальна мова програмування, що дозволяє використовувати кілька
парадигм та програмувати у різних стилях.
До списку речей, які притаманні деяким функціональним мовам, і яких
умовно немає в JavaScript, частіше за все відносять чистоту та незмінність. У
функціональних мовах іммутабельність зазвичай дана за замовчанням.
Більшість ФП-мов використовують спеціальні структури даних, наприклад,
префіксне дерево, з можливістю спільного використання даних. Тобто старий
об'єкт і новий об'єкт зберігають посилання на ті самі дані, якщо вони не
змінювалися.
Зазвичай зміна глобальних значень безпосередньо впливає на поточний
стан програми, тоді як операції введення/виводу змінюють щось за межами
програми. Але у веб-розробці все обертається довкола DOM. Це не тільки127
доступи та зміна глобальних змінних, але ще й операції вводу/виводу.
Виведено, що фронтенд можна сприймати як один суцільний побічний ефект
і у екосистемі JavaScript код пишуть саме для побічних ефектів. Тому замість
того, щоб повністю їх позбутися, потрібно зменшити їх кількість, ізолювати
ті, що залишилися, в одному місці, а більшість функцій зробити чистими.
Чисті функції – одна з найкорисніших і найзастосовніших методик ФП.
В третьому розділі було проведено огляд використання функціональної
парадигми у роботі з бібліотекою React. Було порівняно функціональні
компоненти React та компоненти, які базуються на класах з огляду
практичного використання. Розібрано плюси та мінуси використання
функціонального підходу при роботі за бібліотекою. Використання хуків
дозволяє виділити логіку, яка керує побічним ефектом. Раніше цю логіку
доводилося розбивати на різні методи життєвого циклу у компоненті. І
оскільки
з'явилися
хуки
мінімізації
та
React.memo,
функціональні
компоненти відтепер піддаються мемоізації, тобто компонент не буде
перетворено або оновлено, якщо його пропси не змінилися. Також з'явився
хук useMemo, який можна використовувати для того, щоб обчислювати якісь
важкі значення, або інстанцувати якісь службові класи лише один раз.
За кілька останніх років React перетворився на чудовий швидкий
клієнтський JS фреймворк. І хоча React це бібліотека, сучасна екосистема та
велика кількість розширень та бібліотек дозволяють сприймати його саме як
фреймворк. React, Redux та Immutable.js разом запропонували розробникам
практичне вирішення питання поєднання функціонального програмування та
JavaScript – розробку чистих редюсерів без побічних ефектів. Це дозволило
змінювати звичний стан продукту для створення великомасштабних
функціональних програм в рамках синтаксису ES6. Остання версія React
надала спрощений синтаксис для чистих компонентів, інтеграція яких не
викликає побічних ефектів. Популярність такого підходу зумовила поширене
розповсюдження функціонального програмування.128
У
четвертому
розділі
роботи
було
оглянуто
використання
функціональної парадигми у роботі з сучасним фреймворком, та розібрано
плюси і мінуси статичної генерації сторінок, рендерінгу на клієнтській та
серверній сторонах. Велика частина уваги була приділена опису клієнтського
та серверного підходів до генерації шаблонів додатків. Проаналізувавши
переваги та недоліки, було зроблено висновок, що для створення якісного
сучасного додатку, потрібно поєднати плюси кожного з підходів та
позбавитись мінусів та знайдено рішення, яке надає таких можливостей -
Next.js.
Основна перевага Next.js – вбудована підтримка SSR для підвищення
продуктивності та SEO. Рендерінг на стороні сервера працює шляхом зміни
потоку запитів React, так що всі компоненти, крім клієнта, відправляють
свою інформацію на сервер. Next.js також дозволяє редагувати тег <head>
сайту, чого неможливо зробити в React. Тег <head> є основною частиною
метаданих веб-сторінки та сприяє підвищенню SEO-рейтингу сайту.
Використання SSR також надає перевагу у SEO, що допомагає сайту займати
більш високі позиції на сторінках результатів пошукових систем. SSR
підвищує рейтинг веб-сайтів для SEO, тому що вони завантажуються
швидше та більше контенту сайту можна сканувати за допомогою трекерів
SEO.
Наразі навколо Next.js сформувалося велике та активне ком'юніті, а сам
фреймворк активно підтримується та розвивається розробниками. Всі
оновлення публікуються в блозі і детально описані в документації, поряд із
повноцінним інтерактивним туторіалом. Останні оновлення мають адаптацію
React 18, нові файлові конвенції, паралельні запити даних та багато іншого.
Next.js активно використовують та підтримують великі компанії на кшталт
Google, а Vercel пропонує зручну інфраструктуру для деплою додатків. Отже
можна з упевненістю сказати, що Next.js буде і далі популярним у
найближчому майбутньому.129
Доведено, що функціональний підхід загалом та хуки зокрема надають
досить великі можливості. Потрібно добре розуміти, як вони працюють,
особливо те, як вони мемоізують значення. Адже з великими можливостями
приходить відповідальність. Якщо неправильно щось замемоізувати, то
програма зберігатиме неактуальні значення, або навпаки — ререндер
відбуватиметься надто часто. Щоб не зіштовхнутися з ситуацією, коли якесь
значення замкнулося всередині чи у нижніх рівнях ієрархії, треба чітко
розуміти, що таке замикання, як вони працюють, як функції обробляють
вільні змінні тощо. Без цього знання буде по-справжньому складно
налагодити якусь проблему.
Написання «функціонального» коду дає можливість поглянути на
проблему з іншого боку, де розробка рішення може бути більш ефективною. І
це просто збільшує кількість засобів висловити ідеї програміста. Відповідно,
функціональне програмування може змінити стиль написання коду на краще.
Якщо існуюча кодова база вже не дає необхідного рівня управління
складністю бізнес-області, код засмічено непотрібними залишками, а
імплементація нового функціоналу призводить до рефакторингу та втрати
часу, перехід на функціональне програмування може бути рішенням. А в
областях, пов'язаних з великою кількістю обчислень або перетворень даних,
паралельним
чи
асинхронним
програмування надає значних переваг.
пр