Comments 12
Хорошая статья пр RxJS, согласен со всем кроме:
Всё это делает Observable простым, удобным, но мощным решением для реактивности.
Именно реактивность как концепция сложная для классического программирования основанного на толкании данных императивно. А реализация реактивности в RxJS вообще требует постоянного заглядывания в документацию. Удобно, мощно, сложно.
Отсюда всякие сигналы появились.
В статье под Observable понимается не паттерн, а сама библиотека kr-observable. Найти подходящее название, да еще и чтобы его не было в npm оказалось так же сложно, как и саму библиотеку писать )).
Хорошая статья
Спасибо
Проведем еще один небольшой, синтетический тест, сравнив Vue, MobX и Observable - библиотеки с наиболее схожим API. Суть проверки проста: создаем наблюдаемый объект, изменяем одно свойство и считываем оба значения. Результат печатаем в консоль, чтобы JIT не хулиганил
Это делается всё же так:
Я вижу тут утечку памяти по 373 байта на итерацию.
Разве JIT не будет игнорировать создание объектов если поймет что на деле они не используются? Вроде как печать в консоль с открытыми дев-тулзами дает больше гарантии, что он этого не сделает.
Кстати, переход по ссылке открывает пустую страницу
Предложу вариант Observable с примером использования:
export class Observable {
#callbacks = new Set();
notify() {
for (const fn of this.#callbacks) fn();
}
subscribe(callback) {
this.#callbacks.add(callback);
return () => this.#callbacks.delete(callback); // unsubscribe
}
}А также вариант классического счетчика (не Реакт):
const ClickCounter = ({count = 0}) => (
<button click_e_update={() => count++}>
Clicked {() => count} times
</button>
);В таких простых компонентах с event handler-ами, достаточно обычных переменных для состояния вместо использования реактивных менеджеров состояния.
Реактивная система вещь несколько сложнее чем реализация паттерна Observable на JS.
Зачем сложнее когда можно проще?
Например чтобы не обновлять не нужные места, просто разделить данные на несколько Observable.
Зачем сложнее когда можно проще?
Вы подменяете понятия и уходите в чрезмерную крайность, игнорирую реальные сценарии использования и реальные проекты.
Например чтобы не обновлять не нужные места, просто разделить данные на несколько Observable.
Не нужно. Ненужные места и так не обновятся. MobX и kr-observable с этим и так справляются Нет ничего удобнее MobX и его максимально близкий аналогов с точки зрения написания кода. Ибо getters/setters (возможность автоматической подписки/отписки и т.п.) это эталон для стейт менеджмента.
Observable – не только удобный state-manager