КС
может это будет дешевле в итоге
Size: a a a
2020 September 14
КС
интересно, будет ли пачка компонентов через each, отображающая объекты массива реагировать вся на изменение одного из объектов в иммутабельном режиме, или вообще никаких шестеренок крутится не будет кроме того одного изменившегося объекта
КС
мне чем понравился вариант с айдишками тогда твой первый, что заниматься иммутабельностью с массивом айдишек (о как) - гораздо проще, чем с массивом объектов :)
AS
Пока в игре не 10К карт мне кажется вообще разницы никакой
КС
ну я не про игру, а в принципе про стейт менеджмент :)
КС
какое принятое решение потом не укусит за что-нибудь, когда станет образно говоря 10К карт
КС
и не придётся всё перепиливать, потому что принял неправильное решение
AS
В любом варианте each будет бегать по массиву при инвалидации. Если уж пришлось рендерить 10К карт, то там уже придется искать какие-то неожиданые решения для оптимизаций. Например не делать так:
что уже конечно перечеркивает весь стейтдривен
{#each... as card}
<div class:flipped={card.flipped}/>
{/each}
а уже что-то вроде:{#each ... as card}
<div on:click={e=>{e.target.toggleClass('flipped'); changingstate()}}
{/each}что уже конечно перечеркивает весь стейтдривен
AS
Это кстати пример, почему солид в тесте фреймворков сильно опередил свелте на тесте где выделяется по клику 1 из 10К строк
КС
В любом варианте each будет бегать по массиву при инвалидации. Если уж пришлось рендерить 10К карт, то там уже придется искать какие-то неожиданые решения для оптимизаций. Например не делать так:
что уже конечно перечеркивает весь стейтдривен
{#each... as card}
<div class:flipped={card.flipped}/>
{/each}
а уже что-то вроде:{#each ... as card}
<div on:click={e=>{e.target.toggleClass('flipped'); changingstate()}}
{/each}что уже конечно перечеркивает весь стейтдривен
в этом плане мне нравится Set для айдишек и
очень быстро
у меня там до 14000 строк (не все видимы) и ему норм
клик мгновенно отрабатывает и меняет стейт
class={selectedIds.has(item.id)}очень быстро
у меня там до 14000 строк (не все видимы) и ему норм
клик мгновенно отрабатывает и меняет стейт
AS
так они в любом случае быстро будет - в том же фреймворктесте частота процессора искуственно уменьшается в 16 раз чтобы хоть как-то разницу отловить
AS
возможно на каком-то утюге или микроволновке будет не столь быстро
КС
возможно на каком-то утюге или микроволновке будет не столь быстро
ну лишь бы на снапдраконе 625 завозило :)
2020 September 15
КС
по сути объекты так же быстры как Set'ы, медленнее были бы только массивы, где нужно на каждый объект ещё и массив пролупать?
КС
each всё равно проедется по массиву объектов чтобы выставить класс после изменения и пофигу, проверит он наличие айдишки в сете, или поле в объекте
КС
другое дело, что если с иммутабельностью, то он не будет проверять поля, а только ссылку объекта
AS
на тормоза скорее скажется отрисовка DOMа и на памяти тоже. А то что он там по массиву бегает капля в море
КС
на тормоза скорее скажется отрисовка DOMа и на памяти тоже. А то что он там по массиву бегает капля в море
да уж :) дом тот ещё тормоз, тут тоже убедился
но радует что в отличие от вдомовских фреймворков, количество объектов в массиве и соответственно нод в доме не так ужасно влияет на производительность
типа не нужно куда большую структуру сравнивать, только некоторые поля применяемые в шаблоне
это к слову об отображаемых допустим 1000 строках и клику на какую-нибудь галочку
но радует что в отличие от вдомовских фреймворков, количество объектов в массиве и соответственно нод в доме не так ужасно влияет на производительность
типа не нужно куда большую структуру сравнивать, только некоторые поля применяемые в шаблоне
это к слову об отображаемых допустим 1000 строках и клику на какую-нибудь галочку
AS
ну еще главное что они не перерендриваются в основном - только изменившиеся части
КС
короче можно юзать safe_not_equal и не парить мозг ?