Это вопрос к тому, кому какие кэши нужны и в каких случаях.
Используйте WeakMap.
Вообще, что бы не было подобных очевидных вопросов, надо предложить несколько базовых стратегий и возможность подставить другое middleware для кэша. Пусть этот вопрос будет за скоупом npm пакета.
Почему обязан? Обработчик что-то берёт из замыкания? Он обращается к this? Значит он тесно связан с внутренней логикой компонента. Это не функциональный подход.
Такой обработчик нельзя использовать в композиции, особенно если он обращается не к лексическому this.
Строго говоря на все события одного типа может быть один обработчик. Это хороший повод подумать о дата флоу внутри приложения.
Я привёл пример с обработчиками событий на примере реакта.
Этот вопрос задаю в конце статьи.
Устроит ли всех WeakMap или важнее указывать лимит кеша, или нужен лимит кэша на основе последних вызванных функций?
Проблема выглядит иначе, если использовать только чистые функции не ссылающиеся на свои замыкания (что потенциально опасно в любой композиции и мемоизации), а оставить только унарные или каррированные с переиспользованием уже созданных.
Tail и head — это часть другой реализации, где каждой композиции заводится пространство мемоизации. Таким образом композиции могут переиспользвать кэши друг друга. На гитхаб упрощённый вариант, который работает только со списком.
Каналы — это способ накапливать события, чтобы потом их все обработать. Например по очереди.
Хороший юзкейс — накапливать запросы с оптимистичным апдейтом.
Или сообщения для отправки в сокет, на случай дисконнекта.
takeLatest — пропустит все предыдущие сообщения.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
А как же эквивалентность, переиспользуемость и мемоизация всего это добра?
Используйте WeakMap.
Вообще, что бы не было подобных очевидных вопросов, надо предложить несколько базовых стратегий и возможность подставить другое middleware для кэша. Пусть этот вопрос будет за скоупом npm пакета.
Такой обработчик нельзя использовать в композиции, особенно если он обращается не к лексическому this.
Строго говоря на все события одного типа может быть один обработчик. Это хороший повод подумать о дата флоу внутри приложения.
Я привёл пример с обработчиками событий на примере реакта.
Устроит ли всех WeakMap или важнее указывать лимит кеша, или нужен лимит кэша на основе последних вызванных функций?
Проблема выглядит иначе, если использовать только чистые функции не ссылающиеся на свои замыкания (что потенциально опасно в любой композиции и мемоизации), а оставить только унарные или каррированные с переиспользованием уже созданных.
Tail и head — это часть другой реализации, где каждой композиции заводится пространство мемоизации. Таким образом композиции могут переиспользвать кэши друг друга. На гитхаб упрощённый вариант, который работает только со списком.
Хороший юзкейс — накапливать запросы с оптимистичным апдейтом.
Или сообщения для отправки в сокет, на случай дисконнекта.
takeLatest — пропустит все предыдущие сообщения.