Блог

Есть ли способ обеспечить соблюдение порядка выполнения для широковещательного потока с несколькими слушателями, где порядок выполнения имеет значение?

 StreamSubscriptionlt;Tgt; listen(void onData(T event)?,  {Function? onError, void onDone()?, bool? cancelOnError});  

Абстрактное определение, похоже, не поддерживает это. Я искал, возможно, что-то вроде параметра «приоритет», чтобы указать порядок работы.

Например, прямо сейчас у меня есть пользовательский контроллер, который уведомляет своих слушателей о том, чтобы они что-то делали, когда пользователь меняется. Тем не менее, некоторым слушателям необходимо расставить приоритеты, но они должны быть в своем собственном отдельном классе. Пример кода:

 class UserController{  Stream user; }  class IndependentControllerA { //...   userController.user.listen((){  // This needs to be carried out first before everything else  }  //... }  class IndependentControllerB {  userController.user.listen((){  // This needs to be carried out before A  } }  

Что я подумал, чтобы преодолеть это, так это то, что вместо этого UserController зарегистрирует список своих собственных будущих обратных вызовов, которые можно ожидать по порядку. См. Пример:

 class UserController {  Listlt;Future Function()gt; callbacks;    void changeUser() async {  callbacks.forEach((callback) =gt; await callback());  } }  class IndependentControllerA {  //...  userController.callbacks.add(() =gt; print('Do first thing'));  //... }  class IndependentControllerB {  //...  userController.callbacks.add(() =gt; print('Do second thing'));  //... }  

Однако я чувствую, что это не очень элегантно, если есть лучший врожденный способ сделать это уже с stream. Есть ли?

Порядок, в котором уведомляются слушатели, определенно не является чем-то, что обещает Дарт. На практике, скорее всего, он будет каким-то образом упорядочен в зависимости от порядка добавления слушателей, но это не гарантия, и он может измениться в любое время. (На самом деле нет, определенно есть плохо написанный код, который зависит от заказа и сломается, если порядок изменится, но это просто означает, что для изменения должна быть веская причина, а не то, что этого не может произойти).

Я бы написал свой собственный «определитель приоритетов», если бы у меня была такая конкретная потребность. Что — то вроде того, что вы начали здесь. Знание конкретных требований, которые у вас есть, может сделать это намного проще, чем создание полностью общего решения.