Comments 17
const functions = new Map<Function, Hash>()
const compositionsByHash = new Map<string, Composition<any, any>>()
Ай-ай-ай, утечка памяти же будет...
Кстати, зачем вам вообще свойства tail и head, если все что нужно уже лежит в list?
Устроит ли всех WeakMap или важнее указывать лимит кеша, или нужен лимит кэша на основе последних вызванных функций?
Проблема выглядит иначе, если использовать только чистые функции не ссылающиеся на свои замыкания (что потенциально опасно в любой композиции и мемоизации), а оставить только унарные или каррированные с переиспользованием уже созданных.
Tail и head — это часть другой реализации, где каждой композиции заводится пространство мемоизации. Таким образом композиции могут переиспользвать кэши друг друга. На гитхаб упрощённый вариант, который работает только со списком.
Любой обработчик события должен быть так или иначе привязан к компоненту, а для этого он обязан быть различным в каждом компоненте.
Любое применение вашего compose к обработчику событий в пересоздаваемом компоненте даст утечку памяти.
Такой обработчик нельзя использовать в композиции, особенно если он обращается не к лексическому this.
Строго говоря на все события одного типа может быть один обработчик. Это хороший повод подумать о дата флоу внутри приложения.
Я привёл пример с обработчиками событий на примере реакта.
Да, согласен, сглупил: this и правда необязателен.
Но у вашего кода все равно утечка памяти. id-то, как правило, может быть произвольным, а значит и compose(dispatch, makeAction, contsant(id)) будут накапливаться.
[func1, func2, func3].reduce( (val, func) => func(val), initialParam );
shammasov вопрос: у вас богатый опыт работы с weakMap? я в одном проекте ради удобства организовал глубокую мемоизацию за счёт вложенных weakMap-ов. Удобно, но это немного мешает спать, т.к. нет к ним у меня пока доверия. И дебажить утечки памяти сильно мешают (постоянно все пути ведут в Рим в очередной weakMap). Вы могли бы их рекомендовать в боевому применению на больших объёмах?
Не очень понял вас. Можно на примере?
const map = new WeakMap();
map.set({}, 1); // map { %obj: 1 }
gc();
map; // map {}Как это повторить используя символы?
Но зачем так делать, если можно сделать Heap Snapshot и для любого объекта увидеть всех его настоящих ретайнеров, а не вспомогательные WeakMap?
Честно говоря я окончательно потерял нить беседы. Примером выше я хотел показать не просмотр содержимого, а суть слабых ссылок. Что ты пользуешься ими и не думаешь об утечках. Не пишешь всякие фабрики селекторов и прочую муть. Просто и элегантно. Я не очень понял вас, как можно сделать самодельные WeakMap-ы без слабых ссылок, но с использованием символов. Или вы не об этом говорили?
Касательно retainer-ов — я тут совсем поплыл. Вам случаем не попадалось какого-нибудь крутого мануала по профилированию утечек? Прошлый раз когда я пытался понять куда уплывает память, я в 95%+ случаях попадал в эти чёртовы weakMap-ы на каком-нибудь 15 уровне вложенности, и ничего не мог понять. Зачем они там вообще отображаются? о_О
Я не очень понял вас, как можно сделать самодельные WeakMap-ы без слабых ссылок, но с использованием символов. Или вы не об этом говорили?
Именно об этом я и говорил.
const symbol = Symbol("...");
// map.set({}, 1);
({})[symbol] = 1;
gc();Зачем они там вообще отображаются?
Затем, что недоработка инструментария. В .NET, кстати, такая же ерунда с ConditionalWeakTable.
О композиции функций в JavaScript