DK
@bingo347 давай писать односложно, без “мда”, так диалог не ведется
ну потому что это не ответ
в том числе и immer - это не ответ, ибо он никакого отношения к svelte/store не имеет
Size: a a a
2020 April 30
DK
я понял, удачи в поисках
A
причем тут это вообще?
Может всёж лучше задачу в репл схематично изобразить? Много вопросов возникает к выбранному способу ... зачем ключи отдельно, зачем коллекции... и тп...
ДБ
Может всёж лучше задачу в репл схематично изобразить? Много вопросов возникает к выбранному способу ... зачем ключи отдельно, зачем коллекции... и тп...
ок ща накидаю
A
Вот отсюда почитать про АТОМАРНЫЕ сторы может пригодится https://t.me/sveltejs/59643
ДБ
Может всёж лучше задачу в репл схематично изобразить? Много вопросов возникает к выбранному способу ... зачем ключи отдельно, зачем коллекции... и тп...
https://ru.svelte.dev/repl/55110e194d6f41a396c394640e8ef6d1?version=3.21.0
вот что то такое нужно, только управляться часть будет не кнопками, а внешними событиями (например с websocket)
Интересует собственно то что в ItemsStore
вот что то такое нужно, только управляться часть будет не кнопками, а внешними событиями (например с websocket)
Интересует собственно то что в ItemsStore
ДБ
если быть точным, то updateItem вызывается с вебсокета
A
ребят, а когда компонент удаляется, то с него удаляются все обработчики?
AS
https://ru.svelte.dev/repl/55110e194d6f41a396c394640e8ef6d1?version=3.21.0
вот что то такое нужно, только управляться часть будет не кнопками, а внешними событиями (например с websocket)
Интересует собственно то что в ItemsStore
вот что то такое нужно, только управляться часть будет не кнопками, а внешними событиями (например с websocket)
Интересует собственно то что в ItemsStore
Во первых то, что в dirived в корне неверно. На каждое изменение стора идентификаторов, у тебя создаются подписки(а отписок никто не делает).
AS
Вот я накидал тут как я это вижу, вроде бы не потерял функционал и немного структрировал: https://ru.svelte.dev/repl/9e1179f28e5b4632a8471cdce3f7fd40?version=3.21.0
DN
в любом случае надо создавать уникальную функцию обработки на каждый компонент
В принципе уникальную функцию на каждый компонент не всегда нужно создавать, наверное в этом есть смысл только если нужно создать замыкание для каждого генерируемого методом forEch значения при перебирании в шаблоне. В остальных случаях лучше делегировать обработку события, чтобы не генерировать множества слушателей событий.
ДБ
Во первых то, что в dirived в корне неверно. На каждое изменение стора идентификаторов, у тебя создаются подписки(а отписок никто не делает).
разве компонент Item не сделает отписок?
подписки то делает только он
подписки то делает только он
ДБ
Вот я накидал тут как я это вижу, вроде бы не потерял функционал и немного структрировал: https://ru.svelte.dev/repl/9e1179f28e5b4632a8471cdce3f7fd40?version=3.21.0
потерялся таки, теперь придется залезть внутрь стора и перебрать массив, когда придет обновление для конкретного id
у меня итемов в массиве тысячи и обновления точечные довольно часто с сервера прилетают
у меня итемов в массиве тысячи и обновления точечные довольно часто с сервера прилетают
ДБ
Вот я накидал тут как я это вижу, вроде бы не потерял функционал и немного структрировал: https://ru.svelte.dev/repl/9e1179f28e5b4632a8471cdce3f7fd40?version=3.21.0
если бы не стоял вопрос точечных быстрых обновлений, я бы просто сделал 1 стору с массивом, в котором сразу лежат объекты
AS
разве компонент Item не сделает отписок?
подписки то делает только он
подписки то делает только он
export const items = derived(itemsID, ids => (
ids.map(id => ({
subscribe: itemsMap[id].subscribe
}))
));
вот тут будет subscribe по любому изменению itemsID и не будет никаких отписок.
ДБ
export const items = derived(itemsID, ids => (
ids.map(id => ({
subscribe: itemsMap[id].subscribe
}))
));
вот тут будет subscribe по любому изменению itemsID и не будет никаких отписок.
почему он тут будет? я тут просто из Writable делаю Readable
DN
Denys Novakov
В принципе уникальную функцию на каждый компонент не всегда нужно создавать, наверное в этом есть смысл только если нужно создать замыкание для каждого генерируемого методом forEch значения при перебирании в шаблоне. В остальных случаях лучше делегировать обработку события, чтобы не генерировать множества слушателей событий.
Хотя для событий компонентов не получится сделать делегирования. Разве что если добавить название события в каждый компонент-родитель на пути передачи события (например on:message), то получится что-то на подобии всплытия.
AS
почему он тут будет? я тут просто из Writable делаю Readable
а да - глаз уже мыльный