Привет, ребята, я так давно написал что-нибудь о Flutter. После написания двух статей о шаблоне BLoC я проводил время, занимаясь анализом использования этого шаблона сообществом, и, отвечая на некоторые вопросы о реализации шаблона BLoC, увидел, что среди людей существует много путаницы. Поэтому я составил список «практических правил», которым можно следовать для правильной реализации шаблона BLoC, который поможет разработчику избежать распространенных ошибок при его реализации. . Итак, сегодня я представляю вам список 8 золотых точек, которые необходимо соблюдать при работе с BLoC.
Предпосылки
Я ожидаю, что аудитория должна знать, что такое шаблон BLoC, или создала приложение, использующее этот шаблон (по крайней мере, CTRL + C и CTRL + V). Если вы впервые слышите слово «BLoC», то следующие три статьи будут идеальным местом для начала понимания этого шаблона:
- Создайте архитектуру своего проекта Flutter, используя шаблон BLoC ЧАСТЬ 1 и ЧАСТЬ 2.
- Когда Firebase соответствует шаблону BLoC
История тех, кто столкнулся с BLoC
Я знаю, что знаю, что это сложный шаблон для понимания и реализации. Я видел много сообщений от разработчиков, спрашивающих: «Какой ресурс лучше всего подходит для изучения шаблона BLoC?». После просмотра всех различных сообщений и комментариев я чувствую, что следующие моменты являются общими препятствиями, через которые проходил каждый человек. при понимании этого шаблона.
- Реактивное мышление.
- Пытаюсь понять, сколько файлов BLoC нужно создать.
- Боюсь, масштабируется это или нет.
- Не знаю, когда потоки будут удалены.
- Что такое полная форма BLoC? (Это компонент бизнес-логики 😅)
- Многое другое….
Но сегодня я перечислю некоторые из наиболее важных моментов, которые помогут вам уверенно и эффективно реализовать шаблон BLoC. Без промедления давайте рассмотрим эти удивительные моменты.
Каждый экран имеет свой BLoC
Это самый важный момент, о котором нужно помнить. Каждый раз, когда вы создаете новый экран, например экран входа в систему, экран регистрации, экран профиля и т. Д., Который включает в себя работу с данными, вы должны создать для него новый BLoC. Не используйте глобальный BLoC для всех экранов в вашем приложении. Вы, должно быть, думаете, что если у меня есть общий BLoC, я могу легко использовать данные между двумя экранами. Это нехорошо, потому что ваш репозиторий должен нести ответственность за предоставление этих общих данных в BLoC. BLoC просто возьмет эти данные и предоставит на ваш экран таким образом, чтобы их можно было отобразить пользователю.
Каждый BLoC должен иметь dispose() метод
Это довольно просто. Каждый создаваемый вами BLoC должен иметь dispose() метод. Это место, где вы выполняете очистку или закрываете все созданные вами потоки. Ниже показан простой пример метода dispose().
Не используйте StatelessWidget с BLoC
Когда вы хотите создать экран, который будет передавать данные в BLoC или получать данные из BLoC, всегда используйте StatefulWidget. Самым большим преимуществом использования StatefulWidget перед StatelessWidget являются методы жизненного цикла, доступные в StatefulWidget. Позже мы поговорим о двух наиболее важных методах переопределения при работе с шаблоном BLoC. StatelessWidgets хороши для создания небольшой статической части экрана, например, для показа изображения или жестко закодированного текста. Если вы хотите увидеть реализацию шаблона BLoC в StatelessWidget, ознакомьтесь с PART1 и PART2, я показал, почему я перешел с StatelessWidget на StatefulWidget.
Отменить didChangeDependencies() для инициализации BLoC
Это наиболее важный метод для переопределения в StatefulWidget, если вам нужно context в начале для инициализации объекта BLoC. Вы можете думать об этом как о методе инициализации (предпочтительнее только для инициализации BLoC). Вы можете возразить, что у нас даже есть initState(), так зачем использовать didChangeDependencies(). В документе четко указано, что вызывать BuildContext.inheritFromWidgetOfExactType из метода didChangeDependencies() безопасно. Ниже показан простой пример использования этого метода:
Переопределить метод dispose () для удаления BLoC
Так же, как есть метод инициализации, нам был предоставлен метод, с помощью которого мы можем удалить соединения, которые мы создали в BLoC. Метод dispose() - идеальное место для вызова метода BLoC dispose(), связанного с этим конкретным экраном. Этот метод всегда вызывается, когда вы покидаете экран (технически, когда StatefulWidget удаляется). Ниже приведен небольшой пример этого метода:
Используйте RxDart только при работе со сложной логикой
Если вы раньше работали с шаблоном BLoC, значит, вы слышали о библиотеке RxDart. Это библиотека реактивного функционального программирования для Google Dart. Эта библиотека - всего лишь оболочка Stream API, предоставляемого Dart. Я бы посоветовал вам использовать эту библиотеку только тогда, когда вы имеете дело со сложной логикой, такой как объединение нескольких сетевых запросов. Но для простых реализаций используйте Stream API, предоставляемый языком Dart, поскольку он достаточно зрелый. Ниже я добавил BLoC, который использует Stream API, а не RxDart библиотеку, потому что операции довольно просты, и мне не нужна была дополнительная библиотека, чтобы делать то же самое:
Используйте PublishSubject вместо BehaviorSubject
Этот момент более специфичен для тех, кто использует библиотеку RxDart в своем проекте Flutter. BehaviorSubject - это специальный StreamController, который захватывает последний элемент, который был добавлен в контроллер, и передает его как первый элемент любому новому слушателю. Даже если вы вызовете close() или drain() на BehaviorSubject, он все равно будет удерживать последний элемент и передавать его при подписке. Это может стать кошмаром для разработчика, если он не знает об этой функции. В то время как PublishSubject не сохраняет последний элемент и лучше всего подходит для большинства случаев. Посмотрите этот проект, чтобы увидеть функцию BehaviorSubject в действии. Запустите приложение и перейдите к экрану Добавить цель, введите данные в форму и вернитесь назад. Теперь снова, если вы посетите экран Добавить цель, вы найдете форму, предварительно заполненную данными, которые вы ввели ранее. Если вы такой же ленивый человек, как я, то посмотрите видео, которое я прикрепил ниже:
Правильное использование поставщиков BLoC
Прежде чем я скажу что-либо по этому поводу, проверьте приведенный ниже фрагмент кода (строки 9 и 10).
Вы можете ясно видеть, что несколько поставщиков BLoC вложены друг в друга. Теперь вы должны быть обеспокоены тем, что если вы продолжите добавлять больше BLoC в ту же цепочку, это будет кошмар, и вы придете к выводу, что шаблон BLoC не может масштабироваться. Но позвольте мне сказать вам, что может быть особый случай (BLoC, содержащий только конфигурации пользовательского интерфейса, которые требуются для всего приложения), когда вам нужно получить доступ к нескольким BLoC в любом месте дерева виджетов, поэтому для таких случаев вышеупомянутое вложение совершенно нормально. Но я бы порекомендовал вам избегать такого вложения в большинстве случаев и предоставлять BLoC там, где это действительно необходимо. Так, например, когда вы переходите на новый экран, вы можете использовать поставщика BLoC следующим образом:
Таким образом, MovieDetailBlocProvider предоставит BLoC экрану MovieDetail, а не всему дереву виджетов. Вы можете видеть, что я сохранил MovieDetailScreen в новом final variable, чтобы избежать повторения MovieDetailScreen каждый раз, когда клавиатура открывается или закрывается в MovieDetailScreen.
Это не конец
Итак, мы подошли к концу этой статьи. Но это еще не конец этой темы. Я буду продолжать добавлять новые пункты к этому постоянно растущему списку оптимизации шаблона BLoC по мере изучения лучших способов масштабирования и реализации шаблона. Я надеюсь, что эти моменты обязательно помогут вам лучше реализовать шаблон BLoC. Продолжайте учиться и продолжайте кодировать. :) Если вам понравилась статья, то проявите свою любовь, нажав 50 хлопков в ладоши 😄 👏 👏.
В случае сомнений свяжитесь со мной в LinkedIn или подпишитесь на меня в Twitter. Я постараюсь решить все ваши вопросы.
