Споживання пам'яті Redux [закрито]

Рамка Redux надає перевагу незмінній парадигмі стан / чиста функція, яка сприяє створенню нового стану з попереднього стану з точки зору поточної дії. Застосування цієї парадигми є непереборним.

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

Хтось насправді порівнював споживання пам’яті програми Redux з традиційною архітектурою Flux? Якщо так, чи могли б вони поділитися своїми висновками?

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

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

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

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