To BLoC or not to BLoC, или как iOS-разработчики во Flutter искали Router
Не так давно наша команда решила изучить Flutter как одну из трендовых и перспективных на сегодняшний день технологий. В этой статье речь пойдет прежде всего о связанных с BLoC-архитектурой граблях, на которые мы наступили, и о компромиссах, на которые пришлось пойти.
Прежде наша команда в своих проектах использовала преимущественно паттерны MVVM и VIPER. Приступив к изучению архитектурных практик во Flutter, мы обнаружили, что здесь пишут несколько иначе. Тем, кто тоже интересуется этой темой, рекомендую изучить репозиторий, где представлены различные варианты реализации одного и того же небольшого приложения «TODO-лист». Не будем рассматривать каждую архитектуру подробно, поскольку это тянет на отдельный цикл статей. Скажу лишь, что мы остановились на BLoC-архитектуре, предложенной Google, поскольку нам она показалась наиболее интересной. Подробнее про BLoC вы можете почитать в нашей предыдущей статье. Сейчас же речь пойдет о том, какие нюансы в применении этой архитектуры могут помешать взаимодействию ваших Bloc-ов с UI, если вы смотрите на него сквозь призму опыта другой архитектуры.
Первый взгляд на BLoC
Казалось бы, все звучит довольно просто. Вот UI, вот Bloc, который в этой архитектуре выступает в качестве презентера. Берем потоки, подписываемся на них и посылаем данные туда-сюда. Однако у нас, привыкших к VIPER-у, все время возникало ощущение, что чего-то здесь не хватает. Поэтому мы попытались адаптировать некоторые идеи VIPER-а к BLoC-у.
Главный вопрос, который нас занимал — кто в этой архитектуре исполняет обязанности Router-а. Раньше у нас была такая последовательность действий: нажали кнопку во View, Presenter обработал нажатие, затем либо передал запрос Interactor-у, либо попросил Router открыть новый экран. Здесь у нас в качестве Presenter-а выступает сам Bloc. То есть переход на новый экран должен осуществляться из Bloc-а? Нет, не все так просто.
Дело в том, что во Flutter вам жизненно необходима такая сущность, как BuildContext. Хотите перерисовать виджет? Нужен BuildContext. Хотите показать другой экран или диалоговое окно? Показывайте с помощью BuildContext. Хотите локализовать строку с помощью библиотеки (хотя она не единственная, но очень популярная)? Вы знаете, куда идти. И этот BuildContext доступен только на уровне UI в момент обращения к виджету.
То есть выполняете вы какой-то асинхронный запрос и вдруг обнаруживаете, что вам срочно нужно пользователю показать сообщение, скажем, о возникшей ошибке. Ошибка приходит в ваш Bloc. Вы хотите показать ииии... не показываете. Почему? Правильно. Потому что у вас контекста нет, так как вы находитесь на уровне бизнес-логики, где виджеты отсутствуют. А уровень UI, где виджеты есть, не должен знать о других модулях, на которые выполняется переход.
Мы придумали два способа для выхода из этой ситуации. Способ первый — просто отдавать в Bloc контекст из виджета. В теле метода виджета initState () мы обращались к нашему Bloc-у, вызывали у него метод setContext (context) и сохраняли соответствующую ссылку, после чего использовали ее для показа диалога или другого экрана. Просто и надежно. Способ второй — каждый раз передавать контекст виджета аргументом в метод, который может потребовать от вас работу с UI. Хотя автор второго способа все равно пришел к тому же первому решению, когда пытался наладить ту самую обработку асинхронно пришедшей ошибки.
Почему нельзя помещать BuildContext в Bloc
Сохранив BuildContext внутри Bloc-а, мы, казалось бы, добились своего. Теперь мы в любой момент в Bloc-е можем вызвать код, который осуществит переход на другой экран, покажет диалог или выполнит другое необходимое действие. Этот код может быть вынесен в отдельный класс, скажем, MyBlocRouter. И каждый раз, когда вам нужно уйти на другой экран, вы пишете MyBlocRouter.goToNextScreen (_context), и внутри этого метода уже пишете всю логику, связанную с созданием и настройкой нового экрана. Тогда это казалось более-менее приемлемым компромиссным решением (особенно в условиях мягко подкрадывающегося дедлайна по проекту). Догадываетесь, почему на самом деле решение было не очень хорошим?
Ответ прост — все та же изоляция слоев по практикам Clean Architecture. Поместив context в Bloc, вы тем самым жестко завязываете вашу бизнес-логику на конкретную UI-имплементацию, что лишает возможности повторно использовать компонент в других местах. А ведь именно это является одним из назначений Bloc-а.
Отделяем навигацию от UI и бизнес-логики
Вспомним, что BLoC — прежде всего реактивный паттерн. Вы можете организовать отдельный поток для событий. На вход этого потока поступают данные из Bloc-а (это могут быть строковые ключи, числовые константы или значения enum-ов). На выходе есть некто, кто слушает эти сообщения и в зависимости от запрошенного события вызывает ваш Router, передавая ему свой контекст. Назовем эту сущность BlocContext. Ее основное назначение — помогать Bloc-у в тех операциях, которые он не может самостоятельно выполнить без контекста. К таким операциям относятся навигация между экранами и показ диалогов.
Проиллюстрируем взаимоотношения классов следующей диаграммой: