Спасибо. У вас получается писать понятный код. На слух с первого раза не воспринимаю объяснения, но после анализа кода всё встаёт на свои места. Смотрел про шаблоны проектирования из двух других источников, ваши варианты самые простые для понимания. Осталось только внедрить это в работу.
Обсерверы меня спасли. Но реализацию расширил. Под каждую функцию в классе которая меняет состояние объекта пишу dispatch(event name). И реализую функцию в наблюдаемом объекте on(eventname). Собственно тоже самое что и на видео, но можно отправлять только подписоте подписанной на конкретный event name. Мб паранойя, но кажется так вроде меньше рендера.
в register в роли observer выступает инстанс класса, а в метод unregister передаём класс, как-то некрасиво выходит, нужно переписать метод register и передавать туда класс, а пушить в actions инстанс класса
Ок. Все равно не вижу смысла в этом паттерне при создании React приложений. Ведь в действительности, если у меня меняются какие-то данные асинхронно с неизвестной переодичностью, то скорее всего использую сокеты, ловлю событие и изменяю стейт приложения (useState/useContext/Redux) и передаю эти пропы нужным компонентам, а они уже сами реагируют на изменения. Зачем такой огород пилить уже вокруг готового функционала? ПС. Вижу как на бэке можно это использовать, но на фронте, извините
Река-приложение было чисто для примера. Для того, что бы проще было проветри аналогию. Вообще, многие из рассмотренных паттернов зашиты непосредственно в сами библиотеки и фрэймворки. В чистом виде они используются, в большинстве своём, при программировании на нативном JS
@@artedza нативный JS есть смысл писать только в одном случае, если ты сам пилишь какую-то библиотеку и не хочешь иметь никаких зависимостей к другим. В реальном мире это не работает
метод не робіт autonews.unregister(new Max()); "unregister(observer) { this.actions = this.actions.filter(el => !(el instanceof observer)); }" TypeError: Right-hand side of 'instanceof' is not an object
