сервиса - один отвечает за отрисовку Ui, во втором определенная логика
далее компоненты слушают сервисы - кидают им евенты и прочее
но есть пару моментов, когда из одного сервиса нужно перекинуть что-то в другой сервис - и наоборот
и при импорте обоих в друг друга - получаю Circular dependency
переносить один сервис в вид стора не вариант - там много слушателей в компонентах - которые что-то отрисовывают при евенте в других компонентах
пилить 3-й сервис? где будут сливаться два сервиса и будут общаться посредством 3-го сервиса?
или можно использовать родительский компонент модуля в качестве буфера между сервисами?
Что еще можно сделать или что из этого оптимальнее - можете подсказать?
Попробуйте через фабрику и агрегацию. Но, как по мне, лучше что-то прхитектурно поменять
да, ща сижу пересматриваю - к чему нужен 2й сервис и как можно перевести его в обычный класс
Имею ввиду фабрику на провайдер. Один токен инжектит через deeps два сервиса и агрегирует, а второй токен также ...
фабрику на провайдер - покопаюсь в эту сторону) спасибо
Вот такие варианты ещё. private payrollService:PayrollService; constructor(/*private payrollService:PayrollService*/ injector:Injector) { setTimeout(() => this.payrollService = injector.get(PayrollService)); } Но выглядит костыльно. А лучше архитектурно что-то поменять, мне так кажется
да, архитектурно 😅😅 лично для меня все, что содержит setTimeout - сразу костыль))
Для эвентов можно сделать отдельный глобальный сервис
глобальный сервис 🧐🧐 надо подумать - но задача такова, что нужно сделать как бы автономный модуль - который из внешнего окружения знает только об одном api сервисе и все
можно сделать зависимости от абстракции в каждом из сервисов и отдельно один сервис который прокидывается как эти две абстракции
Ну Event service может иметь только dispatch() и dispatched$, в то время как события могут быть описаны в виде классов внутри фичи. Тогда никакая логика не будет выходить за пределы твоего модуля
не до конца понял если честно как бы 3й сервис который содержит ссылки на два остальных сервиса?
это хорошая идея))) не додумался при 1м совете с глобальным сервисом ща попробую сделать так, спасибо)
Эвент может содержать свой пэйлоад определенный в конструкторе: this.eventService.dispatch(new AuthUserLoggedIn(user));
тут по-моему надежнее будет в кач-ве 1го аргумента еще передавать константу как имя эвента this.eventService.dispatch('authEvent', new AuthUserLoggedIn(user));
Зачем если ты уже описал эвент в виде класс AuthUserLoggedIn? Это как события роутера - слушать ты будешь из dispatched$ фильтруя по event instanceof AuthUserLoggedIn
Имя можно добавить в класс в виде readonly параметра в классе, для логирования например
параноик)) instanceof не очень нравится было пару случаев, когда в схожих классах instanceof выдавал совсем не ожидаемый рез-т
Может тогда уже на полиморфизме что-то замутить?
Так работают некоторые стейт менеджеры и все у них нормально. Можешь посмотреть ngxs как там сделано
уровень моего недоверия к js/ts 😅😅
не, я тебя понял на том же нативном андроиде библиотека EventBus работает по этому же принципу но там все таки котлин)
акак андефайнед может быть строкой?
были случаи когда бэк на ноде отправлял и такое)
Ну так это уже не js виноват)
но бэк же тоже на js) его писал не я если что
Может.... если гдето задано преобразование в строку
На любом языке можно такого напилить)
Я ток один случай знаю, когда андеф является строкой.
а нафиг андеф в строку гнать?
тут просто проект был написан разными фрилансерами - без постоянного ПМ - работало где-то -+30 людей - каждый писал свою часть - получал деньги и сваливал я почти что переписал 80% проекта - свел в какую-то определенную структуру/архитектуру (нейминг/вложенность/зависимости и т.д.) ща осталась самая последняя и самая сложная часть - которая постоянно ломается - и хрен поймешь там кто и зачем делал поэтому тут такие коды попадаются - глаза на лоб лезут на бэке та же хрень - больше 10 как я знаю фрилансов писали - и каждый в своем стиле тут даже ща нет единой модели респонсов 🤦♂️
нууу такое
это ожидаемо - результат оператора
а это неявное приведение
делаем проверку на тип и исключаем подобное
так вопрос то был поднят не "как обойти", а "как такое получается"
Такое лучше не игнорить и к бэку идти с проблемами такими)
Такое вообще нельзя игнорить))) очень грубая ошибка
не, к бэку сразу шел и требовал исправить...но вместе с этим и увеличивалось кол-во сценариев в isExist - на всякий пожарный на будущее
Рано или поздно может выстрелить, как уже выше упоминали
Обсуждают сегодня