PM
который в свою очередь говорит свелту что надо триггерить ТОЛЬКО если ссылка изменилась
Если immutable: falseSize: a a a
2020 December 02
AI
я же четко написал
Да, сорян, проглядел, но вопрос был именно про принудительно подсказать о том что переменная изменилась. Как я понимаю это в режиме immutable:true нереализуемо, так?
PM
Да, сорян, проглядел, но вопрос был именно про принудительно подсказать о том что переменная изменилась. Как я понимаю это в режиме immutable:true нереализуемо, так?
принудительно при мутации это some = some, но очевидно же если ты мутируешь объекты, то immutable: true тебе не нужен. получается ты пытаешься соврать свелту, типа “я использую только иммутабильность”, а сам за его спиной наяриваешь мутации и при этом хочешь, чтобы все работало 🙃
AI
принудительно при мутации это some = some, но очевидно же если ты мутируешь объекты, то immutable: true тебе не нужен. получается ты пытаешься соврать свелту, типа “я использую только иммутабильность”, а сам за его спиной наяриваешь мутации и при этом хочешь, чтобы все работало 🙃
Агаг 😛 Я хочу в виде исключений мутировать что-то, а в остальном дать ему полное управление, не хотелось на весь компонент вешать опцию immutable:false.
AI
Спасибо тебе что помог разобраться, хорошего дня 😉
DK
принудительно при мутации это some = some, но очевидно же если ты мутируешь объекты, то immutable: true тебе не нужен. получается ты пытаешься соврать свелту, типа “я использую только иммутабильность”, а сам за его спиной наяриваешь мутации и при этом хочешь, чтобы все работало 🙃
По статистике 99% разработчиков наяривают мутации и только 5% из них открыто признаются в этом XD
PM
Агаг 😛 Я хочу в виде исключений мутировать что-то, а в остальном дать ему полное управление, не хотелось на весь компонент вешать опцию immutable:false.
она висит по умолчанию) обычно с таких случаях мутируют внутрянку объекта, а потом один раз создают новую ссылку:
obj.foo = 1;
obj.bar.baz = 2;
…
obj = { …obj };
PM
можно сказать что это принудительный триггеринг при immutable: true
AI
По статистике 99% разработчиков наяривают мутации и только 5% из них открыто признаются в этом XD
Ты так говоришь как будто мутации это плохо. Спредить на любое чихание — вот это действительно плохо.
PM
По статистике 99% разработчиков наяривают мутации и только 5% из них открыто признаются в этом XD
DK
Ты так говоришь как будто мутации это плохо. Спредить на любое чихание — вот это действительно плохо.
Я люблю мутации, я из тех 5% :)
AI
она висит по умолчанию) обычно с таких случаях мутируют внутрянку объекта, а потом один раз создают новую ссылку:
obj.foo = 1;
obj.bar.baz = 2;
…
obj = { …obj };
Я прост не запаривался до того момента пока не словил лишние реактивные вычисления на сквозном bind (через компоненты), вчера вопрос задавал, включил для всего проекта immutable:true, в итоге всего несколько мест проблемных нашлось, в остальном всё иммутабельно оказалось 🙂
AI
Я люблю мутации, я из тех 5% :)
Обнимемся? 🙂
DK
Обнимемся? 🙂
:)
PM
я тоже раньше не любил иммутабильность, однако есть разница писать мутации в какой-нить Ractive, где есть спец методы и концепция keypath и фреймворк всегда знает что мы мутируем, без прокси и defineProperties (аля Vue):
this.push(‘foo.bar.baz’, item);
PM
keypath были супер удобной штукой, но когда пришла тема с типизацией стало понятно, что такие вещи нереально типизировать.
PM
поэтому все перешли обратно к работе с js объектами напрямую, а js не дает никаких средств понять что изменилось в мутированном объекте
PM
спасает только копирование ссылок для вложенных объектов
DK
А чем плохо весь рутовый объект заново передать? Скорость?
UR
если речь про свелт сторы, тогда прям его и юзайте:
import { user } from ‘./store.js’;
…
{#each $user as item}
{/each}Благодарю за подсказку!
не обновляется :(
Делал по этому примеру https://svelte.dev/tutorial/auto-subscriptions
не обновляется :(
Делал по этому примеру https://svelte.dev/tutorial/auto-subscriptions
