Apply suggestions from code review

Author: dolgachio

1-js/99-js-misc/07-weakref-finalizationregistry/article.md

@@ -44,6 +44,7 @@ user = null;
 
 У JavaScript існує концепція під назвою `WeakRef`, яка працює трохи інакше в цьому випадку.
 
+
 ````smart header="Терміни: \"Сильне посилання\", \"Слабке посилання\""
 **Сильне посилання** - це посилання на об'єкт або значення, яке запобігає їх видаленню збирачем сміття. При цьому, зберігаючи об'єкт або значення в пам'яті, на які воно вказує.
 
@@ -96,7 +97,7 @@ let admin = new WeakRef(user);
 user = null;
 ```
 
-Слабкого посилання на об'єкт недостатньо, щоб зберегти його "в живих".
+Слабкого посилання на об'єкт недостатньо, щоб зберегти його "в живих". Коли лишаються тільки слабкі посилання, збирач сміття має право знищити об'єкт і використовувати цю пам'ять для чогось іншого.
 
 Однак доти, доки об'єкт фактично не знищено, слабке посилання може повернути його, навіть якщо на цей об'єкт більше немає сильних посилань.
 Тобто наш об'єкт стає своєрідним "[котом Шредінгера](https://uk.wikipedia.org/wiki/Кіт_Шредінгера)" - ми не можемо знати точно, "живий" він чи "мертвий":  
@@ -120,21 +121,19 @@ if (ref) {
 ## Варіанти використання WeakRef
 
 `WeakRef` зазвичай використовується для створення кешу або [асоціативних масивів](https://uk.wikipedia.org/wiki/Асоціативний_масив), де зберігаються великі об'єкти.
-[асоціативних масивів](https://uk.wikipedia.org/wiki/%D0%90%D1%81%D0%BE%D1%86%D1%96%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%B8%D0%B9_%D0%BC%D0%B0%D1%81%D0%B8%D0%B2), де зберігаються ресурсомісткі об'єкти.
 Це дозволяє уникнути перешкоджанню видаленню цих об'єктів збирачем сміття тільки на основі їхньої присутності в кеші або асоціативному масиві.  
 
-Один з основних прикладів – це ситуація, коли ми маємо велику кількість об'єктів бінарних зображень (наприклад, представлених у вигляді `ArrayBuffer` або `Blob`),
-і ми хочемо зв'язати ім'я або шлях з кожним зображенням. Існуючі структури даних не зовсім підходять для цих цілей:  
+Один з основних прикладів - це ситуація, коли ми маємо велику кількість об'єктів бінарних зображень (наприклад, представлених у вигляді `ArrayBuffer` або `Blob`), і ми хочемо пов'язати ім'я або шлях з кожним зображенням. Існуючі структури даних не зовсім підходять для таких цілей:
 
-- Використання `Map` для створення асоціацій між іменами та зображеннями, або навпаки, збереже об'єкти зображень у пам'яті, оскільки вони фігурують у `Map` як ключі або значення.
-- `WeakMap` також не підійде в цьому випадку: через те, що об'єкти, представлені у якості ключів `WeakMap`, використовують слабкі посилання і не захищені від видалення збирачем сміття.  
+- Використання `Map` для створення зв'язку між іменами та зображеннями, або навпаки, збереже об'єкти зображень у пам'яті, оскільки вони фігурують у `Map` як ключі або значення.
+- `WeakMap` також не підійде в цьому випадку: через те, що об'єкти, представлені у якості ключів `WeakMap`, використовують слабкі посилання і не захищені від видалення збирачем сміття.
 
-Але в цій ситуації нам потрібна структура даних, яка б використовувала слабкі посилання у своїх значеннях.  
+Тому в цій ситуації нам потрібна структура даних, яка б використовувала слабкі посилання у своїх значеннях.
 
-Для цього ми можемо використовувати колекцію `Map`, значеннями якої є екземпляри `WeakRef`, що посилаються на потрібні великі об'єкти.
-Отже, ми не зберігатимемо в пам'яті ці великі та непотрібні об'єкти довше, ніж вимагається.  
+Для цього ми можемо використати колекцію `Map`, значеннями якої будуть екземпляри `WeakRef`, що посилаються на потрібні великі об'єкти.
+Отже, ми не зберігатимемо в пам'яті ці великі та непотрібні об'єкти довше, ніж треба.  
 
-У протилежному випадку це спосіб отримати об'єкт зображення з кешу, якщо він все ще доступний.
+Ба більше це спосіб отримати об'єкт зображення з кешу, якщо він все ще доступний.
 Якщо ж він був видалений збирачем сміття, ми згенеруємо або завантажимо його знову.  
 
 Таким чином, у деяких ситуаціях використовується менше пам'яті.  
@@ -143,8 +142,9 @@ if (ref) {
 
 Нижче міститься фрагмент коду, який демонструє техніку використання `WeakRef`.  
 
-Коротко кажучи, ми використовуємо `Map` з строковими ключами та об'єктами `WeakRef` як їх значення.
-Якщо об'єкт `WeakRef` не був видалений збирачем сміття, ми беремо його з кеша. У протилежному випадку ми завантажуємо його знову та розміщуємо в кеш для можливості подальшого повторного використання:  
+Одним словом, ми використовуємо `Map` з рядками для ключів та об'єктами `WeakRef` як їх значення.
+Якщо об'єкт `WeakRef` не був видалений збирачем сміття, ми беремо його з кеша.
+У протилежному випадку ми завантажуємо його знову та розміщуємо в кеш для можливості подальшого повторного використання:  
 
 ```js
 function fetchImg() {
@@ -172,9 +172,8 @@ const getCachedImg = weakRefCache(fetchImg);
 ```
 
 Давайте детально розберемо все, що тут сталося:
-
-1. `weakRefCache` - функція вищого порядку, яка приймає іншу функцію `fetchImg` як аргумент. У цьому прикладі ми можемо знехтувати докладним описом функції `fetchImg`, оскільки це може бути абсолютно будь-яка логіка завантаження зображень.
-2. `imgCache` - кеш зображень, який зберігає кешовані результати функції `fetchImg`, у вигляді строкових ключів (ім'я зображення) та об'єктів `WeakRef` як їх значення.
+1. `weakRefCache` - це функція вищого порядку, яка приймає іншу функцію `fetchImg` як аргумент. У цьому прикладі ми можемо знехтувати докладним описом функції `fetchImg`, оскільки це може бути абсолютно будь-яка логіка завантаження зображень.
+2. `imgCache` - це кеш зображень, який зберігає кешовані результати функції `fetchImg`, з ключами рядками (ім'я зображення) та об'єктів `WeakRef` як їх значення.
 3. Повертаємо анонімну функцію, яка приймає ім'я зображення як аргумент. Даний аргумент буде використовуватися як ключ для кешованого зображення.
 4. Намагаємося отримати кешований результат з кешу, використовуючи наданий ключ (ім'я зображення).
 5. Якщо кеш містить значення за вказаним ключем, і об'єкт `WeakRef` не був видалений збирачем сміття, повертаємо кешований результат.