Join

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

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

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

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

Що вміє

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Натисніть Guest log in — потрапите одразу на дошку, без реєстрації.