У меня какое-то событие Samevent.
Например, у моего события есть два слушателя;
$ result = event (новый Samevent ());
Я должен проверить результат;
1 ящик
FirstListener возвращает ложь; SecondListener возвращает ложь;
dd ($ result) = [];
2 кейс
FirstListener возвращает ложь; SecondListener возвращает истину;
dd ($ result) = [];
3 корпус
FirstListener возвращает истину;
SecondListener возвращает ложь;
dd ($ result) = [true];
4 корпус
FirstListener возвращает истину; SecondListener возвращает истину;
dd ($ result) = [истина, истина];
Почему это происходит ?? Как я могу это исправить
Эти слушатели не помещаются в очередь
@Davit Что вы думаете о вышеупомянутом вопросе? У вас есть четкие идеи? Если у вас есть, пожалуйста, поделитесь со мной. Спасибо.
@Dev Нет, у меня не было никаких новых мыслей по этому поводу






Если вам нужно получить результат от функции, вы не должны использовать систему событий для запуска этой функции.
Вы должны провести рефакторинг вашего кода одним из двух способов:
1) Прекратите использовать событие и используйте что-то вроде задания / взаимодействия без очереди.
$interaction = new Interaction;
$result = $interaction->handle($vars);
dd($result);
2) Передайте все необходимые переменные в событие, чтобы ваш слушатель мог выполнять любую обработку после события внутри самого слушателя.
Я должен использовать прослушиватель событий.
Причина, по которой все здесь говорят, что это неправильное использование событий и слушателей, заключается в том, что вся их цель - запускать асинхронно. Когда вы запускаете слушателя, нельзя гарантировать, что содержимое этого слушателя завершит выполнение до того, как то, что вызвало его, перейдет. По этой причине они не готовы предлагать возврат.
Некоторые дополнительные сведения о том, почему вы считаете, что желаемая логика должна исходить от Слушателя, были бы полезны, возможно, мы сможем подсказать вам лучший образец. А пока я бы сказал, что у вас есть несколько вариантов. В порядке предпочтения:
handle() вашего слушателя в новый класс обслуживания. Класс, который, по вашему мнению, в настоящее время нуждается в доступе к этому прослушивателю, и сам прослушиватель могут затем ссылаться на этот класс службы независимо друг от друга.handle() напрямую, чтобы получить желаемый ответ.config(['app.queue_driver' => 'sync']), чтобы слушатели запускались синхронно. (Обязательно измените его обратно в следующей строке после запуска прослушивателя, который должен быть синхронным, иначе это может иметь непредвиденные последствия для остальной части вашего приложения.) Затем измените свой прослушиватель, чтобы все handle() сохранялись в свойство, доступное с помощью нового метода Getter. Однако этот вариант не рекомендуется. Это может можно сделать, но он настолько небрежный, что я не решаюсь даже предлагать его. Но я не новичок в том, чтобы заставлять свой код делать странные вещи ради юнит-тестов, поэтому я не собираюсь предполагать, что знаю ваши обстоятельства.
События и слушатели работают не так. Таких результатов от слушателей не получить. В реальных примерах огромное количество событий запускается в отдельной очереди после завершения жизненного цикла запроса.