в PostList v-for="post in posts" v-bind="post"

Зачем передавать пост целиком, если он во vuex?

Я же выше написал! Можно передать айдишник, можно айтем, можно пропсы айтема

ок, item тогда

Зачем передавать пост целиком, если он во vuex?

Незачем всем подряд ломиться во vuex, мешанина из потоков данных

А по факту это всё равно передача по ссылке

А по факту это всё равно передача по ссылке

Почему тогда в дочерних компонентах нельзя менять пропсы если это ссылки?

Зачем передавать пост целиком, если он во vuex?

Компонент занимается рендерингом поста. ЛОгично, что его параметр - это пост. А передать пост или его id - это одинаковый объём. эЭто не "целый" пост, а просто ссылка на него

Незачем всем подряд ломиться во vuex, мешанина из потоков данных

Как без vuex сделать хоть какое нибудь серьезное приложение?

Как без vuex сделать хоть какое нибудь серьезное приложение?

Прокидывать везде кучу пропсов и событий / шину

Евенты поднимать через тысячу компонентов?

Почему тогда в дочерних компонентах нельзя менять пропсы если это ссылки?

Ну теоретически можно, просто это нарушает концепции

Евенты поднимать через тысячу компонентов?

или шину

Ну, сделать такую архитектуру, при которой уровней будет не тысяча

или шину

И какой профит

И какой профит

а кто сказал, что это профит)

Короче понятно единого подхода я так понял здесь нет

Кто как смотрю херачии

Вообще-то есть и тебе его уже описали )

А скажите почему считается плохим тоном в дочернем компоненте пропсы менять?

Вообще-то есть и тебе его уже описали )

Ты про шину?

props down, events up

props down, events up

Ну это геморойно.. vuex как раз и используется для избавления от этого гемороя и централизованного управления стейтом

Евенты поднимать через тысячу компонентов?

опиши пример, где будет даже вложенность в 10

Ну это геморойно.. vuex как раз и используется для избавления от этого гемороя и централизованного управления стейтом

нет

опиши пример, где будет даже вложенность в 10

Вложенности не будет, но если компонент сложный евентов может быть десятки

Ты видимо про туду говоришь..

Вложенности не будет, но если компонент сложный евентов может быть десятки

значит у тебя компонент жирный и его нужно подробить

Если эвентов десятки - пришла пора декомпозиции

Где нужно пару евентов пробросить

Ты видимо про туду говоришь..

а ты, видимо, пишешь 2к строк кода в 1 компонент

Ты про шину?

Есть есть компонент, и его задача, его ответственность - это рендеринг поста, то он получает на вход пост. Получать на вход id - это не экономия памяти + он должен знать что-то лишнее, даже если они итак все работают с хранилищем. SOLID не отменялось

Есть есть компонент, и его задача, его ответственность - это рендеринг поста, то он получает на вход пост. Получать на вход id - это не экономия памяти + он должен знать что-то лишнее, даже если они итак все работают с хранилищем. SOLID не отменялось

Это простой компонент, который работает без vuex

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

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

То есть vuex по твоему нахер не нужен или что

То есть vuex по твоему нахер не нужен или что

А где я такое написал?

Да и во vuex никто не отменял модули и плагины

Но vuex никак не отменяет правила создания компонентов по принципу минимальной ответственность и слабой связности

А где я такое написал?

Потому что vuex предполагает как раз что стейт будет меняться из компонентов на прямую

Потому что vuex предполагает как раз что стейт будет меняться из компонентов на прямую

Пусть меняется

А ты говоришь, что пост должен отвечать только за рендеринг типа..

То есть пост не может изменить свой рейтинг?

Solid это вообще не про js если что

А ты говоришь, что пост должен отвечать только за рендеринг типа..

Я говорю о том, что нелогично передавать в компонент рендеринга поста ID поста в массиве постов, даже, если он имеет доступ к этому массиву во vuex

Oh no

Я пропустил 4к

Я пропустил 4к

Я могу ливнуть и зайти заново

Го

Я говорю о том, что нелогично передавать в компонент рендеринга поста ID поста в массиве постов, даже, если он имеет доступ к этому массиву во vuex

https://github.com/vuejs/vue-hackernews-2.0/blob/master/src/components/Comment.vue

То есть пост не может изменить свой рейтинг?

Какой из структур проще управлять?

Ну вот смотри, почему тут к примеру передается id

ребят, есть задача интегрировать DataTables в приложение Vue, есть смысл заморачиваться и писать под это директиву или лучше стоит поискать готовые решения для Vue?

Ну здесь 1 уровень всего

А теперь представь, что у 2 компонента есть рейтинг и он тоже евентов бросает

А теперь представь, что у 2 компонента есть рейтинг и он тоже евентов бросает

Не предлагается всё взаиможействие на эвенты оставлять

Если уровней 5 , не значит что надо с 5 поднимать на 1, а 1 уже с vuex общается

Не предлагается всё взаиможействие на эвенты оставлять

Так а чем плох 2 вариант?

Ну вот смотри, почему тут к примеру передается id

Честно говоря - хз, Но я бы не сказал, что этот код идеален. Пропсы, например, не описаны. (да, знаю, что оф пример)

Так а чем плох 2 вариант?

Если передавать по id, то компонент рендеринга постов больше не умеет рендерить посты вне массива, например, превью нового поста или ещё что-либо

Если передавать по id, то компонент рендеринга постов больше не умеет рендерить посты вне массива, например, превью нового поста или ещё что-либо

Ну да

Данные методы равносильны? method: async function() { try { let response = await getSomeData() commit(response) } catch(e) { throw new Error(e) } } method: function() { return getSomeData().then((response) => { commit(respone) }).catch((error) => { throw new Error(error) }) }

Данные методы равносильны? method: async function() { try { let response = await getSomeData() commit(response) } catch(e) { throw new Error(e) } } method: function() { return getSomeData().then((response) => { commit(respone) }).catch((error) => { throw new Error(error) }) }

на первый взгляд - да

но не совсем

ERROR: S client not available

на первый взгляд - да

getSomeData() это промис если что

getSomeData() это промис если что

это понятно

Что возвращает второй метод?

https://github.com/drehimself/todo-vue/blob/master/src/components/TodoItem.vue

Еще вот такой подход нашел

Что возвращает второй метод?

Undefined по идеи

Что возвращает второй метод?

по сути там и там промис? просвятите пожалуйста в чем тонкость отличия

throw new Error(e) Если е итак уже Error, то зачем делать new Error(e: error)?

throw new Error(e) Если е итак уже Error, то зачем делать new Error(e: error)?

Согласен, это не обязательно, набросал чисто ради примера, без нормальной обработки ошибки

А почему вопрос возник? Есть какая-то проблема?

Или чисто по синтаксису и пониманию?

Я пропустил 4к

не пропусти снова ?

Или чисто по синтаксису и пониманию?

По пониманию, если будет 2 таких метода в vuex, как они сeбя будут вести в компоненте, например при created() { this.method() }

Одинаково или есть отличия

Одинаково

Приветствую! Есть вендорный пакет, в компоненте которого я хотел бы сделать изменения. Как правильно это сделать? Можно ли как то его импортировать в новый компонент и там сделать нужные изменения? Или с помощью миксинов это делается? Спасибо!

Одинаково

Спасибо

Приветствую! Есть вендорный пакет, в компоненте которого я хотел бы сделать изменения. Как правильно это сделать? Можно ли как то его импортировать в новый компонент и там сделать нужные изменения? Или с помощью миксинов это делается? Спасибо!

можно обернуть его в компонент, но смотря какие изменения

можно обернуть его в компонент, но смотря какие изменения

мне нужно изменить html внутри компонента. там захардкодены вывод чекбоксов, которые мне нужно изменить (стили, классы, обертки)

не знаю как правильно поступить в этой ситуации

мне нужно изменить html внутри компонента. там захардкодены вывод чекбоксов, которые мне нужно изменить (стили, классы, обертки)

стили еще можешь перебить, но верстку снаружи не изменишь

можно верстку с нуля написать, если это подойдет

не пропусти снова ?

Я на страже)

Давайте, кто следующий станет 4000-й?

мне нужно изменить html внутри компонента. там захардкодены вывод чекбоксов, которые мне нужно изменить (стили, классы, обертки)

Возможно, просить автора в следующий раз делать такое на основе renderless компонентов...

ok, спасибо

Ребят, если использовать константы для мутаций (mutation-types) то как вызвать мутацию в компоненте? Вот в доках есть пример: // mutation-types.js export const SOME_MUTATION = 'SOME_MUTATION'; // store.js import Vuex from 'vuex' import { SOME_MUTATION } from './mutation-types' const store = new Vuex.Store({ state: { ... }, mutations: { // "вычисляемые имена" из ES2015 позволяют использовать // константу в качестве имени функции [SOME_MUTATION] (state) { // здесь будет изменяться состояние } } }) а в компонентах я обычно вызывал мутации через mapMutations(module, ['mutation']) если я буду использовать константы то мне понадобится еще импортировать ее из нужного модуля стора? import { SOME_MUTATION } from '@/store/modules/some-module/mutation-types' mapMutations(module, [SOME_MUTATION]) это нормально? больше пока в голову ничего не приходит по лучше

Ребят, если использовать константы для мутаций (mutation-types) то как вызвать мутацию в компоненте? Вот в доках есть пример: // mutation-types.js export const SOME_MUTATION = 'SOME_MUTATION'; // store.js import Vuex from 'vuex' import { SOME_MUTATION } from './mutation-types' const store = new Vuex.Store({ state: { ... }, mutations: { // "вычисляемые имена" из ES2015 позволяют использовать // константу в качестве имени функции [SOME_MUTATION] (state) { // здесь будет изменяться состояние } } }) а в компонентах я обычно вызывал мутации через mapMutations(module, ['mutation']) если я буду использовать константы то мне понадобится еще импортировать ее из нужного модуля стора? import { SOME_MUTATION } from '@/store/modules/some-module/mutation-types' mapMutations(module, [SOME_MUTATION]) это нормально? больше пока в голову ничего не приходит по лучше

это нормально)

это нормально)

а по другому не делают?) как мне показалось - это не удобно