по поводу моего утверждения о семантике компонентов в Vue я таки правильно понял что в основном стейт компонента должен через value передаваться и мутироваться родителем посредством input события?

Да.

напомните, плиз, в глобальном компоненте как получить текст между тегами? <my-comp>как_это_прочитать_в_компоненте?<my-comp>

в таком случае компонент календаря должен читать выбранные дни и отображаемый месяц (год + месяц) из value а не двух отдельных пропов?

А, да это как тебе удобно. Хотя, если ты передаешь объект даты в компонент, то в нем будет и месяц и год :)

да это понятно, вопрос лишь в разделении выбора дней и самой даты.. value = {date: ..., selectedDays: [...]}

просто тут проблема производительности возникает я думаю... если добавляется выбранный день, то выстреливает input, который провоцирует передачу нового состояния в value, которая заставляет календарь перерисовываться

т.е. мы рисуем календарь заново, хотя тот не изменился вовсе, изменились лишь выбранные дни, т.е. тратим лишний CPU time

Если изменился стейт, то и изменилось вью

Но на самом деле, если данные те же - вью не будет перерисовывать элемент (тут надо уточнять)

Привет! Подскажите, плиз, как можно кастомизировать во vue-chartjs, легенды ? Может есть у кого ссылка на пример ?

Но на самом деле, если данные те же - вью не будет перерисовывать элемент (тут надо уточнять)

дело не во Vue render'е, а в вычислениях самого компонента, у него на value watch указан, который перевычисляет календарь при изменении отображаемой даты

$slots?

что вы подразумеваете под "перевычисляет календарь"? данные изменяются с календаря, на кой ему перерисовываться

не совсем.. изменился лишь список выбранных дней, сам по себе календарь остался на том же месяце, а значит нам не нужно заново вычислять его, что собственно и произойдёт..

насколько я помню (касается не именно легенд, а в общем), это все настраивается в options, а параметры смотреть в доке chartjs

Отслеживать внутри что изменились только выбранные дни и вызывать другой метод api календарика по программному "довыбору" выбранных дней

можно и не копировать стейт

проброшенное значение из родителя

но если например не пробросить никакой v-model или :value то поле всё равно же будет работать, а значит там своя копия стейта компонента

Мне кажется, ты занимаешься преждевременной оптимизацией.

делать локальные копии уже в минус оптимизации

нет там копии, не рекомендуется изменять параметры НЕ через события

да я и не собирался мутировать propсы, это мне понятно.. я скорее о другом... о том что по сути вижу 2 варианта: 1. хранить состояние в родных переменных самого компонента и перезаписывать их watcher'ами на value 2. читать всё только из value, но тогда полностью зависить от родителя, если родитель не мутирует value то компонент мёртв, не работает

ну вот не спеши, подумой... Зачем тебе в календарике стей? Календарик должен: - Показать то, что ему сказали. - Рассказать, если с ним взаимодействовали

я бы сделал стейт, а эмитил по какому-нибудь просотму контракту.

Какой стейт?

анимации, выделения, какие-то временные хери, пролистывания

анимации, выделения, какие-то временные хери, пролистывания

А, ну это UI логика и внутрениие переживания календарика. Они к данным отношения не имеют

это в отдельные пропсы можно засунуть и не парится, дефолтные значения добавить и всё такое в духе

ага. так что стейн нужен. Но его дублирование, -- чуть ли не страшнейшая из зол

ага. так что стейн нужен. Но его дублирование, -- чуть ли не страшнейшая из зол

думаю да, всё читать из value свойства, ибо в природе не нужен компонент, который работает сам по себе ни с кем не коммуницируя, в природе обычно всегда получают инструкции "сверху" (от родителя)

:) Я не говорил, что, допустим, реактивная data не нужна. Стейт для бизнес данных и стейт для UI - это разные вещи. Я говорил о первом.

а ещё от расширений браузера, стейт-хранилищ и Бог знает чего ещё

значит, мы об одном и том же немного разными словами. Это збс.

а ещё от расширений браузера, стейт-хранилищ и Бог знает чего ещё

у компонента же единственный источник правды это его родитель?

неплохо не быть категоричным и понимать, что приложуху может запросто убить какая-нибудь херня снаружи. Ну это так, ремарка

аа, ты про изолюцию...

А в контексте приложения может быть глобальный стейт, например, вьюекса

А в контексте приложения может быть глобальный стейт, например, вьюекса

хранить в vuex данные, которые нужны родителю календарика, который является его child-ом?

Ооо, фаны редаксов ещё и не то могут!

насколько я знаю компоненты обычно делятся на тупые и умные... календарь в таком случае - тупой, что сказали то и делает, а его родитель, например компонент страницы - умный и читает данные самостоятельно из Vuex'а

насколько я знаю компоненты обычно делятся на тупые и умные... календарь в таком случае - тупой, что сказали то и делает, а его родитель, например компонент страницы - умный и читает данные самостоятельно из Vuex'а

Норм практика. Их по-разнмоу называют, но суть примерно такая, да. Удобно.

да уж, программирование как моделирование мира.. стадом тупых элементов управляет парочка умных))

только щас это понял? лол

да уж, программирование как моделирование мира.. стадом тупых элементов управляет парочка умных))

в более-менее больших проектах норм и не парочкой обойтись. И над ними ещё 5 слоёв можно. Главное, правильно разделять и продумывать контракты. Изолированность наше всё.

однако с SSR всё будет плохо... умные компоненты они обычно асинхронны что в принципе не работает с SSR, поэтому для поддержки SSR умными компонентами должны быть сами страницы, а их не много.. issue по этому поводу писал (https://github.com/vuejs/vue/issues/6456) но это далеко не в приоритете