‼️В спецификацию Dart готовится обновление‼️

Замечен черновик новой фичи - Generic Constructors 😩

Не прошло и пары месяцев с упоминания о предыдущем заходе на поле конструкторов с фичей Enhanced Constructors, как команда Dart, в тайне от сообщества, начала работу над черновиком еще одного конструктора... на этот раз - универсального... 🛑

По задумке разработчиков, Generic-конструкторы должны позволить объявлять конструкторы с собственными параметрами типов, которые не отражаются напрямую в типе возвращаемого объекта. Это значит, что можно задавать дополнительные зависимости между аргументами конструктора. Сейчас приходится приходится прибегать к менее безопасным способам.

Планируется 2 типа Generic-конструкторов 🫠

1️⃣Простой

На данный момент, если требуется задать связь между параметрами конструктора (например, значение и функция для его вычисления), приходится использовать универсальные типы вроде Object? и Function, что снижает статическую проверку типов:

class C {
  final int i;
  C(this.i);
  C.computed(Object? x, Function func): this(func(x)); // Unsafe!
} 

с появлением этого конструктора можно будет явно указать зависимость между параметрами, исключая необходимость runtime-проверок

class C {
  final int i;
  C(this.i);
  C.computed<X>(X x, int Function(X) func) : this(func(x));
}

void main() {
  C(42); // Обычный конструктор.
  C.computed('Hello', (s) => s.length); // Автоматическое выведение типа.
  C.computed<String>('Hello', (s) => s.length); // Явное указание типа.
}

2️⃣ Условный

С помощью этого типа Generic-конструктора можно будет объявлять конструкторы, которые корректно работают только при определенных типовых аргументах.
Сейчас приходится писать такой код

class D<X> {
  final X x;
  final int Function(X, X) _compare;
  D(this.x, this._compare);
  D.ofComparable(X x): // Unsafe!
      this(x, (dynamic x1, dynamic x2) => x1.compareTo(x2)) {
    // Check at run-time that `X extends Comparable<X>`.
    if (<X>[] is! List<Comparable<X>>) {
      throw ArgumentError("The type argument failed"
          " to satisfy `X extends Comparable<X>`.");
    }
  }
}

использование универсального конструктора сделает его более лаконичным:

class D<X> {
  final X x;
  final int Function(X, X) _compare;
  D(this.x, this._compare);
  D<X>.ofComparable<X extends Comparable<X>>(X x)
      : this(x, (x1, x2) => x1.compareTo(x2));
}

void main() {
  D.ofComparable(1); // OK, num удовлетворяет Comparable.
  D.ofComparable<num>(1); // Тоже OK.
  D.ofComparable(C(42), (c1, c2) => c1.i.compareTo(c2.i)); // OK.
  D.ofComparable(C(42)); // Ошибка компиляции – тип не соответствует.
}

p.s. Вот теперь я уже точно уверен, что в команде Dart нашелся какой-то маньяк конструкторов... иначе как объяснить такой набор: по-умолчанию, фабричный, именованный, константный, а теперь вот еще первичный, объявляющий, расширенный и универсальный?👀

👍 - больше конструкторов Богу конструкторов
👌 - сомнительно, но Окей
👎 - не вижу от него пользы

#dart_lang@madteacher_channel

Привет, с вами Роза, 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';
  }
}

class SecondImplService extends SomeService {
  @override
  String fetch() {
    return 'Простые данные';
  }
}

Aбстрактный класс SomeService объявляет метод fetch() с типом возвращаемого значения FutureOr<String>. Это значит, что fetch() может вернуть либо String, либо Future<String>.

⚙️Когда же использовать FutureOr?
FutureOr — ваш спаситель, когда вам нужно абстрагироваться от того, является ли результат операции асинхронным или синхронным.

🔧Как обрабатывать FutureOr?
Самый простой способ — использовать проверку типа с помощью is Future.

Да, такой вариант решения может показаться не самым элегантным. Ведь чрезмерное использование is Future может запутать логику и сделать код менее читаемым. Но в некоторых случаях, особенно при работе с абстракциями, это вполне рабочий и понятный подход.

У меня с работой так же. Иногда мне нужен await, чтобы подумать, а иногда все складывается супер. А у вас?

Всем привет!
У меня для вас хорошие новости по книге "Основы Flutter" 👀

Глава по локализации утверждена, а значит, в курсе "Основы Flutter" на степике обновление ^_^

Напоминаю, что уже завтра в 11 часов по Мск состоится стрим с авторским коллективом, где немного приоткроем завесу тайны над написанием книги, почему выбран такой сквозной проект, как началось сотрудничество с Surf и Mad Brains по разработке лабораторного практикума к книге и многое другое 🪨

❤️ Спасибо большое всем кто был на трансляции

🤟 Отличный онлайн собрали для субботнего утра! И отдельное спасибо всем кто задавал вопросы, вышло интересное обсуждение

Для вашего удобства сразу добавил подробные таймкоды, ведь мы обсуждали не только книгу но и кучу других вопрсов

📺 Для тех кто не мог смотреть в онлайне запись трансляции достпуна на канале

Привет, это Катя, Flutter Dev Friflex. Сегодня поговорим о фреймворке gRPC и его реализации.

Что это?
gRPC — это фреймворк для удаленного вызова процедур (RPC), разработанный Google. Он использует HTTP/2 для транспорта и Protocol Buffers (protobuf) в качестве языка описания интерфейсов и формата сериализации данных.

Настройка и использование gRPC

1️⃣ Добавляем в pubspec.yaml:

dependencies:
  grpc: ^4.1.0
  protobuf: ^3.1.0

dev_dependencies:
  protoc_plugin: ^21.1.2

2️⃣ Создаем файл .proto
Сделаем на примере создания чата. Определяем сервис в файле .proto. Например, lib/protos/chat.proto:

syntax = "proto3";

package chat;

service ChatService {
  rpc SendMessage (Message) returns (MessageResponse);
  rpc ReceiveMessages (Empty) returns (stream Message);
}

message Message {
  string text = 1;
  string sender = 2;
  int64 timestamp = 3;
}

message MessageResponse {
  bool success = 1;
  string error = 2;
}

3️⃣ Генерируем код
Запускаем команду для генерации Dart-кода:

bash
protoc --dart_out=grpc:lib/generated -Ilib/protos lib/protos/chat.proto

4️⃣ Создаем клиента

class GrpcClient {
  late ChatServiceClient client;

  /// Инициализация канала соединения
  GrpcClient() {
    final channel = ClientChannel(
      'http://localhost',
      port: 50051,
      options: const ChannelOptions(
        credentials: ChannelCredentials.insecure(),
      ),
    );
    client = ChatServiceClient(channel);
  }

  /// Отправка сообщения
  Future<MessageResponse> sendMessage(String text, String sender) async {
    final message = Message()
      ..text = text
      ..sender = sender
      ..timestamp = DateTime.now().millisecondsSinceEpoch;
    
    try {
      return await client.sendMessage(message);
    } catch (e) {
      print('Error sending message: $e');
      return MessageResponse()..success = false..error = e.toString();
    }
  }
  
  /// Получение сообщений
  Stream<Message> receiveMessages() {
    return client.receiveMessages(Empty());
  }
}

5️⃣ Используем клиента в приложении

На что следует обратить внимание:
🔸gRPC клиент:
➡️инициализируется один раз при создании состояния
➡️обеспечивает двустороннюю коммуникацию
➡️управляет подпиской на поток сообщений

🔸Потоковая передача:
➡️receiveMessages() возвращает Stream<Message>
➡️listen() подписывается на новые сообщения

🔸Управление ресурсами:
➡️gRPC соединение должно закрываться
➡️Отмена подписок происходит автоматически при dispose()

Продолжение — в комментариях📌

Привет, с вами Роза, Flutter Dev Friflex!

Когда только начинаешь разрабатывать на Flutter, многие возможности языка остаются незамеченными. А с опытом начинаешь глубже разбираться в деталях и повышать свою экспертность. С модификаторами классов у меня было так же: изначально в моем арсенале был лишь abstract... и все, наверное. А со временем я узнала и про sealed, и про base. Делюсь этим и с вами!

Зачем нужны модификаторы?

Модификаторы в Dart помогают управлять наследованием и доступностью классов. Они задают ограничения, предотвращают нежелательное расширение или, наоборот, определяют четкие правила для будущих реализаций.

Основные модификаторы:

🔸abstract
Если вам не нужна реализация всех методов, а вы хотите создать класс-шаблон, используйте abstract.
🔴Запрещает создавать экземпляры этого класса напрямую (new AbstractClass() не сработает).
🔴Часто используется как базовый класс, определяющий интерфейс и частичное поведение для наследников.

🔸base
Разрешает наследование (extends) и реализацию (implements), но только в пределах текущего пакета.
🔴За пределами пакета base-класс нельзя реализовать (implements).
🔴Полезно, если нужно предотвратить реализацию, но оставить возможность наследования.

🔸interface
Принуждает использовать класс только через implements, запрещая наследование (extends).

Полезно, если хотите создать чистый контракт, без возможности переиспользовать реализацию.

🔸final
Запрещает любое наследование (extends) или реализацию (implements) класса за пределами текущей библиотеки. 

Гарантирует, что класс — конечная точка в иерархии. Его нельзя расширить или изменить поведение через подклассы вне вашего контроля.

🔸mixin
Позволяет переиспользовать код без наследования.
🔴Класс с mixin можно добавлять к другим классам через with.
🔴Миксины не могут иметь конструкторов и не могут быть инстанцированы напрямую.

🔸sealed
Позволяет создавать закрытый набор подтипов.
🔴Все подклассы должны быть в той же библиотеке, что и sealed-класс.
🔴Полезно для switch, так как компилятор проверяет, что все случаи учтены (exhaustiveness).
🔴Отлично подходит для описания состояний (Loading, Success, Error), событий и других строго определенных иерархий.

Как использовать модификаторы?
Добавьте перед классом нужное ключевое слово. Например:

sealed class GameState {
  // ...
}

🔖Важно! Модификаторы можно комбинировать (abstract base class), создавая тонкие правила для классов. Подробнее — в таблице в комментариях.

📎 Официальная документация по модификаторам

А какие модификаторы используете чаще всего? Делитесь в комментариях! 👀

🚨Обновление курса "Основы Flutter (в разработке)" 🥳

Мы наконец-то закончили последний раздел второй главы - "Скроллируемые виджеты" и он из книги перекочевала на степик 🫠

Последняя неделя выдалась для команды очень продуктивно и о том, что же мы такого наворотили - постепенно будем постепенно делиться с вами в этом канале 😎