Перейти до вмісту

Впровадила deep‑merge на основі каталогу для збережених JSON‑налаштувань, запобігши збоям через відсутні ключі в міру розвитку схеми.

збережені налаштування переживають зміну схеми

Ситуація. Платформа зберігає налаштування в JSON — параметри сповіщень тощо — як значення, які зберіг користувач, накладені поверх набору значень за замовчуванням. Початкове злиття працювало лише на одному рівні. Проблема спливає згодом: варто додати новий ключ до значень за замовчуванням, і в рядках, збережених до його появи, цього ключа просто немає. Далі якийсь клієнтський код читає це поле, отримує undefined і падає — і саме в тих користувачів, які з платформою найдовше.

Завдання. Схему налаштувань треба було розвивати безпечно, щоб новий параметр ніколи нічого не ламав тим, хто зареєструвався ще до його появи.

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

Результат. Налаштування тепер можна розширювати без страху. Новий параметр уже не загрожує падінням клієнта через undefined‑поле, а фронтенду більше не потрібні захисні перевірки, розкидані по всіх місцях, де він читає налаштування. Крім того, решта платформи отримала надійний спосіб розширювати будь‑який збережений JSON‑blob — не одне виправлення, а цілий патерн.

Одна частина довшого переліку — і він увесь на цьому сайті.

Кожен запис написано однаково: ситуація, завдання, що ми зробили і що змінилося.

Переглянути весь перелік