Как я написал свою соцсеть на Flutter Web: от Firebase до трёх кругов ада с Google Sign-In

[DanielKross]

Зашел на демо страницу, все работает, все хорошо(на мой взгляд дизайн надо переработать), но неудобно, что когда заходишь в "пост", исчезает колонка слева, с темами, надо нажимать "назад", чтоб ее увидеть, наверное практичнее было бы менялся бы фрейм в середине страницы, а все остальное, оставалось бы в доступности. А за фишки с авторизацией гугла, спасибо, пригодится.

[GenomeDust]

Спасибо за комментарий!

[dedm]

Сори ну меня чет забомбило нельзя так так делать
Я переписывал раз 5 так как в 1ой версии были просто маты но ии меня остановил

1. ОТСУТСТВИЕ STATE MANAGEMENT
   ────────────────────────────────────────────────────────
   Проект полностью игнорирует современные практики управления состоянием.
   Нет ни Provider, ни Riverpod, ни Bloc, ни даже простого InheritedWidget.

   Последствия:
   • Невозможно эффективно делиться состоянием между виджетами
   • Каждый виджет сам управляет своим состоянием через setState()
   • Дублирование логики проверки роли админа в MainScaffold, ProfilePage, PostDetailPage
   • Нет единого источника правды для данных пользователя
   • При изменении данных нужно вручную обновлять все зависимые виджеты

   Примеры проблем:

   • _checkUserRole() дублируется в 3+ местах

   • Данные пользователя загружаются заново в каждом виджете

   • Нет кеширования состояния аутентификации

2. ОТСУТСТВИЕ СЛОЯ АБСТРАКЦИИ ДЛЯ ДАННЫХ
   ─────────────────────────────────────────────────────────
   Прямые вызовы FirebaseFirestore.instance и FirebaseAuth.instance везде.
   Нет репозиториев, нет сервисов, нет слоя данных.

   Проблемы:
   • Невозможно заменить Firebase на другой бэкенд без переписывания всего кода
   • Нет централизованной обработки ошибок
   • Нет кеширования данных
   • Невозможно протестировать бизнес-логику без моков Firebase
   • Дублирование логики работы с коллекциями

   Примеры:

   • FirebaseFirestore.instance.collection('users').doc(uid).get() повторяется 20+ раз

   • Нет единого места для работы с постами, комментариями, пользователями

3. ОТСУТСТВИЕ МОДЕЛЕЙ ДАННЫХ
   ─────────────────────────────────────────────────────────
   Везде используется Map вместо типизированных моделей.

   Последствия:
   • Нет автодополнения в IDE
   • Ошибки типов обнаруживаются только в runtime
   • Нет валидации данных при получении из Firebase
   • Сложно понять структуру данных без чтения кода
   • Легко допустить опечатку в ключах (например, 'author_name' vs 'authorName')

   Примеры:

   • data['displayName'] ?? 'Anonymous' - что если поле называется по-другому?

   • Нет гарантии, что все поля присутствуют

4. СМЕШЕНИЕ БИЗНЕС-ЛОГИКИ И UI
   ─────────────────────────────────────────────────────────
   Вся бизнес-логика находится прямо в StatefulWidget.

   Проблемы:
   • Невозможно переиспользовать логику
   • Сложно тестировать
   • Виджеты становятся огромными (PostDetailPage - 714 строк!)
   • Нарушение принципа единственной ответственности

   Примеры:

   • toggleLike(), toggleBookmark(), _postComment() - это бизнес-логика, не UI

   • Вся логика работы с заявками (applicants) в UI-слое

5. ОТСУТСТВИЕ ОБРАБОТКИ ОШИБОК
   ─────────────────────────────────────────────────────────
   Ошибки либо игнорируются, либо показываются через print().
   где трай кетч где runZonedGuarded

   Проблемы:
   • Нет централизованной обработки ошибок
   • Пользователь видит технические сообщения об ошибках
   • Нет логирования ошибок для отладки
   • Нет retry-логики при сетевых ошибках

   Примеры:

   • print("Error: $e") - бесполезно в production

   • catch (e) { _showError('Save Error: $e') } - показывает технические детали

6. ОТСУТСТВИЕ ВАЛИДАЦИИ
   ─────────────────────────────────────────────────────────
   Минимальная валидация форм, нет проверки на стороне клиента.

   Проблемы:
   • Можно отправить пустые данные
   • Нет проверки формата email
   • Нет ограничений на длину текста
   • Нет проверки обязательных полей перед отправкой

   Примеры:

   • if (_titleController.text.isEmpty || _selectedCategories.isEmpty) - только базовая проверка

   • Нет валидации email в login_page.dart

7. ПРОБЛЕМЫ С ПРОИЗВОДИТЕЛЬНОСТЬЮ
   ─────────────────────────────────────────────────────────
   Множественные StreamBuilder'ы, нет оптимизации запросов.

   Проблемы:
   • Один и тот же документ загружается несколько раз
   • Нет пагинации для списков (загружаются все посты сразу)
   • StreamBuilder'ы создаются без ограничений
   • Нет debounce для поиска
   • Фильтрация происходит на клиенте после загрузки всех данных

   Примеры:

   • FeedPage загружает все посты сразу, затем фильтрует на клиенте

   • PostDetailPage делает два FutureBuilder для одного и того же поста

   • Нет индексов для сложных запросов

8. ОТСУТСТВИЕ ТЕСТОВ
   ─────────────────────────────────────────────────────────
   Только пустой widget_test.dart, нет unit-тестов, нет integration-тестов.
   Ладно тесты еще ок могу понять ну фаллатер аналйз же можно было настроить это базовая штука

9. ОТСУТСТВИЕ КОНСТАНТ И КОНФИГУРАЦИИ
   ─────────────────────────────────────────────────────────
   Магические числа и строки везде, нет централизованных констант.

   Проблемы:
   • Сложно изменить значения (например, максимальную ширину контента)
   • Нет единого стиля для отступов, размеров шрифтов
   • Легко допустить ошибку при копировании значений

   Примеры:

   • BoxConstraints(maxWidth: 800) повторяется в нескольких местах

   • EdgeInsets.all(24) - разные значения в разных местах

   • Нет константы для названий коллекций Firebase

10. ОТСУТСТВИЕ DEPENDENCY INJECTION
    ─────────────────────────────────────────────────────────
    Все зависимости создаются напрямую в коде.

    Проблемы:
    • Невозможно заменить реализации для тестирования
    • Тесная связанность компонентов
    • Сложно управлять жизненным циклом зависимостей

    Примеры:

    • FirebaseAuth.instance.currentUser - прямая зависимость

    • FirebaseFirestore.instance - везде напрямую

11. НЕОПТИМАЛЬНАЯ СТРУКТУРА ПРОЕКТА
    ─────────────────────────────────────────────────────────
    Все файлы в корне lib/, нет разделения на слои.

    Проблемы:
    • Сложно найти нужный код
    • Нет разделения на features/modules
    • Нет разделения на layers (data, domain, presentation)
    • Все в одном месте

    Рекомендуемая структура:
    lib/
    core/
    constants/
    errors/
    utils/
    data/
    models/
    repositories/
    services/
    domain/
    entities/
    usecases/
    presentation/
    pages/
    widgets/
    providers/

12. ПРОБЛЕМЫ С БЕЗОПАСНОСТЬЮ
    ─────────────────────────────────────────────────────────
    Отсутствие проверок прав доступа на клиенте, утечки данных.

    Проблемы:
    • Проверка роли админа только на клиенте (можно обойти)
    • Нет проверки прав перед выполнением действий
    • Потенциальные утечки данных через ошибки
    • Нет шифрования чувствительных данных

    Примеры:

    • _isAdmin проверяется только на клиенте

    • Нет валидации на сервере (Firestore Rules должны быть строгими)

13. НЕСООТВЕТСТВИЕ BEST PRACTICES FLUTTER
    ─────────────────────────────────────────────────────────
    Игнорирование рекомендаций Flutter team.

    Проблемы:
    • Нет использования const конструкторов где возможно
    • Нет оптимизации rebuild'ов
    • Неправильное использование StreamBuilder (множественные подписки)
    • Нет использования keys где необходимо
    • Неоптимальное использование ListView.builder

    Примеры:

    • Отсутствие const для статических виджетов

    • StreamBuilder без ограничений

    • Нет использования AutomaticKeepAliveClientMixin

14. ОТСУТСТВИЕ ОБРАБОТКИ СОСТОЯНИЙ ЗАГРУЗКИ
    ─────────────────────────────────────────────────────────
    Примитивная обработка состояний загрузки, нет skeleton screens.

    Проблемы:
    • Пользователь видит только CircularProgressIndicator
    • Нет обработки пустых состояний (empty states) везде
    • Нет обработки состояний ошибок
    • Нет retry механизмов
    • Почти нету if (!mounted) return;

15. ПРОБЛЕМЫ С ДОСТУПНОСТЬЮ
    ─────────────────────────────────────────────────────────
    Отсутствие поддержки accessibility.

    Проблемы:
    • Нет semantic labels
    • Нет поддержки screen readers
    • Нет поддержки больших шрифтов
    • Нет поддержки высокого контраста

16. ОТСУТСТВИЕ ОФФЛАЙН-ПОДДЕРЖКИ
    ───────────────────────────────────────────────────────────────────────────────
    Приложение не работает без интернета.

    Проблемы:
    • Нет кеширования данных
    • Нет синхронизации при восстановлении соединения
    • Нет индикации офлайн-режима
    • Пользователь теряет данные при обрыве соединения

══════════════════════════════════════════════════════════════
ИТОГОВАЯ ОЦЕНКА
══════════════════════════════════════════════════════════════

Этот проект демонстрирует классические антипаттерны разработки Flutter приложений:

1. ❌ Нет архитектуры - все в одном слое

2. ❌ Нет state management - невозможно масштабировать

3. ❌ Нет абстракций - тесная связанность с Firebase

4. ❌ Нет тестов - нет гарантий качества

5. ❌ Нет документации - сложно поддерживать

6. ❌ Проблемы с производительностью - неоптимальные запросы

7. ❌ Проблемы с безопасностью - проверки только на клиенте

8. ❌ Несоблюдение best practices - игнорирование рекомендаций

Это получился очень сырой и хаотичный код.
Такое ощущение, что архитектура и принципы ООП просто не учитывались.
С таким подходом проект действительно может «ложиться» в проде очень быстро — не потому что он безнадёжен, а потому что фундамент не продуман.
И, пожалуйста, не оправдывай это «вайб-кодингом» — тут реально видно, что проблема не в стиле, а в отсутствии структуры.
Даже нейросеть не стала бы генерировать подобный набор противоречий — это просто результат того, что ты писал на ходу, без плана и слоёв абстракции.

══════════════════════════════════════════════════════════════

[GenomeDust]

да, на самом деле так и было, что логика повлялась вместо с кодом, плана не было,

Спасибо за коммент, постараюсь применить рекомендации в свободное время!

[dedm]

Тут дело вообще не в “плане”, а в том, что ты, похоже, не понял базовую парадигму Flutter.
Это реактивный фреймворк — он не перерисовывает всю страницу, только те виджеты, которые подписаны на состояние.

Поэтому state-management (Provider / Riverpod / Bloc) — это не “совет”, а нормальная архитектура.

А вот императивный стиль “как в Python”, когда логика смешана с UI — это уже точно не про Flutter.

[dkfbm]

Сори ну меня чет забомбило нельзя так так делать

Github не смотрел, но охотно верю, что всё так и есть – мне уже в примерах кода метод присвоения роли админа глаз резанул. Про ACL автор, очевидно, не слышал. Да и читая про "круги ада" всё время вспоминалось сакральное: RTFM.

Это не говоря уж о том, что в любой соцсети фронтенд – лишь надводная часть айсберга. Без развитой админки она попросту не поплывёт, а тут даже зачатков нет, и ни о каких планах создания не упоминается.

[smessing]

Наивный думает одного приложения сети - хватит. А зачем концепт ?)... Главное уметь программировать, и начать описывать функционал :)