Join.

Чому переписав, а не залатав

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

Те, що ви бачите, — незалежна копія: оригінальний репозиторій команди не чіпав, а стара vanilla-версія лишилася у проєкті в теці legacy/, щоб їх можна було чесно порівняти.

Це те саме рішення, яке рано чи пізно доводиться ухвалювати клієнту про власну систему, тож скажу прямо. Переписувати варто тоді, коли ціна кожної наступної функції зростає; латати — коли не зростає. Тут зростала.

Що вміє

• Дошка з чотирьох колонок — треба зробити, у роботі, чекає на відгук, готово — картки перетягуються між ними.
• Завдання з категорією, пріоритетом, датою, виконавцями й підзавданнями, які позначаються по одному.
• Екран підсумків показує, що відкрито, що термінове і який дедлайн найближчий.
• Контакти згруповані за абеткою, з кольоровими аватарами.
• Миттєвий пошук по дошці, вхід в акаунт і світла та темна теми, які запамʼятовують вибір.

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

Найскладніше: перетягування, яке не стає пасткою

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

Тому перетягування побудоване на dnd-kit — і це не єдиний спосіб перемістити завдання:

• На сенсорному екрані воно починається довгим натисканням, тож звичайний свайп і далі гортає сторінку.
• Кожна картка має ще й меню «Перемістити в». Той самий результат одним дотиком або самою клавіатурою — без перетягування взагалі.

Дані, які працюють і з бекендом, і без нього

Усе сховище сховане за одним файлом — backend.js. Він віддає прості функції: завантажити все, зберегти завдання, видалити контакт, — а решта застосунку так і не дізнається, де насправді лежать дані.

Під ними — дві реалізації. Якщо в середовищі задано адресу Firebase, усе йде в Realtime Database через REST. Якщо не задано, ті самі виклики падають у localStorage, а на першому запуску застосунок сам засіває себе демо-даними, щоб дошка ніколи не зустрічала порожнечею.

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

Що сказав би клієнту до того, як він почне цим користуватися

Два обмеження — краще назвати їх одразу, ніж щоб їх виявили потім:

• Вхід тут демонстраційний, а не захист. Акаунти перевіряються в браузері: цього досить, щоб показати сценарій, і геть недосить, щоб берегти реальні дані. Усе, де є справжні користувачі, потребує автентифікації на сервері.
• На localStorage дані живуть на пристрої. Для демо це нормально, для команди — ні: двоє людей бачили б кожен свою дошку. Спільна робота — це якраз режим Firebase.

Закрити обидва нескладно — вони лишені свідомо, бо це робота для портфоліо, а не система в продакшені.