Привет, с вами Роза, Flutter Dev Friflex👋 И сегодня мы немного погрузимся в магию FutureOr!
Представьте, вы создаете некий абстрактный класс с различными методами, но точно не знаете, будет ли реализация асинхронной или синхронной. Конечно, вы можете создать два метода или изощряться с разными подходами, но действительно ли это хорошее решение?
Лучше, если вы объявите метод, как FutureOr. FutureOr<T> — это такой хитрый тип в Dart, который говорит: «Эй, результат моего метода может быть либо обычным значением типа T, либо Future<T>, если вдруг придется подождать».
Звучит пока не очень понятно? Давайте разберемся на примерах.
Предположим, мы разрабатываем сервис, который получает данные. Одна реализация будет синхронной, другая — асинхронной:
import 'dart:async';
abstract class SomeService { FutureOr<String> fetch(); }
class FirstImplService extends SomeService { @override Future<String> fetch() async { await Future.delayed(Duration(seconds: 2)); return 'Данные из Future'; } }
Aбстрактный класс SomeService объявляет метод fetch() с типом возвращаемого значения FutureOr<String>. Это значит, что fetch() может вернуть либо String, либо Future<String>.
⚙️Когда же использовать FutureOr? FutureOr — ваш спаситель, когда вам нужно абстрагироваться от того, является ли результат операции асинхронным или синхронным.
🔧Как обрабатывать FutureOr? Самый простой способ — использовать проверку типа с помощью is Future.
Да, такой вариант решения может показаться не самым элегантным. Ведь чрезмерное использование is Future может запутать логику и сделать код менее читаемым. Но в некоторых случаях, особенно при работе с абстракциями, это вполне рабочий и понятный подход.
У меня с работой так же. Иногда мне нужен await, чтобы подумать, а иногда все складывается супер. А у вас?
Коллега сделал бота @FlutterObserver_bot, который позволяет оперативно получать свежую подборку: 🟢релиз новых версий flutter и dart, с возможностью посмотреть, что нового 🟢 flutter каналы и чаты 🟢 последние статьи по flutter с medium
Отбивки по новым релизам с изменениями прилетают от бота(на скрине вчерашняя) Очень удобно🔥
Моё мнение - в команде должна быть дружелюбная, развивающая атмосфера code review коллег - это практически ежедневный процесс для каждого разработчика
Если ревью будет вгонять разработчика в стресс каждый день, ни к чему хорошему это не приведёт😁
➡️ Со старта карьеры, практически каждый день, на всех проектах, на которых я работал, построчное code review. И оно проходит в далеко не токсичной форме)
Указывается проблема и как сделать лучше, почему это лучше. Юмор тоже присутствует, смайлы. В общем достаточно дружелюбная, поучительная форма ревью
➡️ В таком темпе разработчик быстро перенимает лучшие практики и проблем в его коде становится все меньше, как и замечаний на ревью
🟢 Худшее, что можно сделать - токсичить на code review, включать чсв. Не делайте так😒