ну это ж я сюдя постил :)
ну вот
и почему ты тогда считаешь, что это плохо?)
Завтра
Mixam19
дружище, заюзай ответы на сообщение, а то не понятно кому отвечаешь
окей, просто был в потоке )
Roman
получение данных - не её ответственность
я понимаю твой аргумент, но почему бы не позволить компоненту самому брать данные разгрузит этим самым компонент View'шки?
ведь иначе вся логика получения данных в родительском элементе и на каждый компонент = boilerplate
Mixam19
я понимаю твой аргумент, но почему бы не позволить компоненту самому брать данные разгрузит этим самым компонент View'шки?
ведь иначе вся логика получения данных в родительском элементе и на каждый компонент = boilerplate
позволить компоненте самой брать данные - это жёстко связать её со способом получения данных. в таком случае у тебя а) Две причины для изменения компоненты. б) Нет возможности зареюзать компоненту с другим источником данных. в) Нельзя протестировать функционал компоненты в отрыве от эндпоинта сервера
Mixam19
последнее особо важно, ИМХО
Завтра
А вот vue-apicase, кстати, разгружает компоненты 😊
Завтра
только надо до стабильного релиза докатить
Mixam19
я понимаю твой аргумент, но почему бы не позволить компоненту самому брать данные разгрузит этим самым компонент View'шки?
ведь иначе вся логика получения данных в родительском элементе и на каждый компонент = boilerplate
чтобы разгрузить родительский компонент - в помощь как раз vuex
Mixam19
но как по мне идеально таки реактовое разделение
Stanislav
ну вот
и почему ты тогда считаешь, что это плохо?)
Не, это более менее норм, ибо тут все крутится в одном родительском умном компоненте, который оперирует глупыми детьми и их данными для них
Mixam19
на контейнеры, которые знают про внешний мир
Mixam19
и глупые компоненты, который жрут пропсы и не кашляют
Denis
Канечно
Завтра
Антипаттерн короче
а ты аутист, который не понял, чем рассуждение @test_user19 отличается от твоего, но решил покрякать типа согласен
Roman
позволить компоненте самой брать данные - это жёстко связать её со способом получения данных. в таком случае у тебя а) Две причины для изменения компоненты. б) Нет возможности зареюзать компоненту с другим источником данных. в) Нельзя протестировать функционал компоненты в отрыве от эндпоинта сервера
данные мы получаем через API адаптер, который можно превратить в Mock для тестирования, так-что с тестированием проблем нет.
в данном случае компоненты специализированны под сайт, поэтому ничего плохого в их "не-reusability" не вижу.
Завтра
Самое норм - скармливать компоненту сервис
Пусть сам берет данные, пусть в нем они хранятся, но при этом он сможет получать данные откуда угодно
Завтра
данные мы получаем через API адаптер, который можно превратить в Mock для тестирования, так-что с тестированием проблем нет.
в данном случае компоненты специализированны под сайт, поэтому ничего плохого в их "не-reusability" не вижу.
чекни сообщение выше, вполне можно простым действием сделать реюзабельность
Denis
Roman
можно пойди на шаг дальше и разбить на 2 компоненты логику:
1. data fetching component (application specific - smart component)
2. data rendering component (dumb, reusable view component)
<product-grid productCategory="shoes" sort="price">
<product-grid-view data="..."/>
</product-grid>
ProductGridView это у нас dumb component, он не знает ничего кроме как нарисовать grid. А вот ProductGrid это application-specific компонента, которая знает откуда брать данные, что существуют категории продуктов, что можно сортировать по определённых критериям. Smart component передаёт данные для рендеринга уже dumb компоненте
Stanislav
ну да
Хотя как по мне, loading-preview все равно дофига на себя берет.
И запросы делает, и данные от этих запросов отдает и прелоэдер рисует.
Сложноватый поток данных.
Я у себя делаю все запросы/работу с данными в родителе, а дети только рисуют.
т.е. <loading-preview> у меня получает pending true/false.
Да, кода в родительском компоненте чуть больше, но зато данные только спускаются в дети, а не приходят из них.
Завтра
У вас есть стимул помочь добить apicase stable :)
Denis
Roman
Хотя как по мне, loading-preview все равно дофига на себя берет.
И запросы делает, и данные от этих запросов отдает и прелоэдер рисует.
Сложноватый поток данных.
Я у себя делаю все запросы/работу с данными в родителе, а дети только рисуют.
т.е. <loading-preview> у меня получает pending true/false.
Да, кода в родительском компоненте чуть больше, но зато данные только спускаются в дети, а не приходят из них.
ну это типичное деление на Smart и Dumb components. Но вопрос тут вот в чём:
в данном случае Smart компонентами являются только те, которые указаны как View компонент в Router'е. Но почему внутри страницы не могут так-же находиться умные компоненты?
Завтра
Он по сути полностью решает вот эту проблему
Сервисы вынесены наверх и встраиваются в компонент со всей нужной инфой и методами
Denis
Denis
???
Denis
Слыхал за Оккама?
Stanislav
ну это типичное деление на Smart и Dumb components. Но вопрос тут вот в чём:
в данном случае Smart компонентами являются только те, которые указаны как View компонент в Router'е. Но почему внутри страницы не могут так-же находиться умные компоненты?
Вот да, мне самому интерсно. Это же тогда через всю страницу данные спускать? 🤔 Где-то должно быть решение
Stanislav
И я надеюсь это не Vuex
Denis
Вот да, мне самому интерсно. Это же тогда через всю страницу данные спускать? 🤔 Где-то должно быть решение
Как край ты можешь this.$root - но это не оч красиво
Stanislav
Как край ты можешь this.$root - но это не оч красиво
Вот именно, что это не очень красиво)
Завтра
Как компромиссный вариант, если не хотите делать по-нормальному, хотя бы упростите эти костыли
Сделайте компонент-стейт, дайте ему имя, и миксин для всех компонентов, чтобы дочерние компоненты на любой вложенности могли из него брать данные
Писать влом, но метод в миксине будет выглядеть типа так
this.$parent.name !== 'stateComponent' ? getFromState(this.$parent.$parent) : this.$parent[propertyName]
Roman
Два последних одинаково - "НАХЕРА"
чтоб не загружать компоненты страниц излишней логикой:
в случае если у нас на странице 1 product-grid:
View {
d1 = fetchData(...);
ProductGrid.data = d1;
}
в случае если у нас на странице 10 product-grid'ов:
View {
d1 = fetchData(...);
d2 = fetchData(...);
d3 = fetchData(...);
d4 = fetchData(...);
d5 = fetchData(...);
d6 = fetchData(...);
d7 = fetchData(...);
d8 = fetchData(...);
d9 = fetchData(...);
d10 = fetchData(...);
d5.filter(...)
d8.sort(...)
d10.replace(...)
ProductGrid.data = d1;
ProductGrid.data = d2;
ProductGrid.data = d3;
ProductGrid.data = d4;
ProductGrid.data = d5;
ProductGrid.data = d6;
ProductGrid.data = d7;
ProductGrid.data = d8;
ProductGrid.data = d9;
ProductGrid.data = d10;
}
Т.е. очевидно слишком много стейта в родительском умном компоненте.. почему бы просто не переместить их (логку и стейт) в несколько умных под-компонентов?
View {
ProductGrid.load('shoes');
ProductGrid.load('shirts');
ProductGrid.load(...);
ProductGrid.load(...);
ProductGrid.load(...);
ProductGrid.load(...);
ProductGrid.load(...);
ProductGrid.load(...);
ProductGrid.load(...);
ProductGrid.load(...);
}
в таком случае мы значительно снизили сложность родительского компонента и даже можно сказать превратили его в тупого, что хорошо
Завтра
но он юзает fetch, который в ноде есть, посему +-должно работать
Завтра
ну в данный момент не сср обсуждается
Павел
<div id="app">
<svg>
<rect height="50" width="50" :x=x></rect>
</svg>
<button @click="play">play</button>
<button @click="pause">pause</button>
</div>
window.App = new Vue({
el: '#app',
data: {
x:0
},
methods: {
play: function () {
console.log('play');
setInterval(() => {
this.x++;
},100);
},
pause: function () {
console.log('pause');
clearInterval(this.play);
},
}
})
Возможно ли вообще добраться до setInterval чтоб остановить его?
https://jsfiddle.net/belanchuk/k1a4hj73/
Rinat Valiullov
#whois
Beginner frontend developer
Just want to learn vue
Hello!!!
Rinat Valiullov
Здраствуйте вообщем всем
Stanislav
Даровки
Завтра
@Romshark поэтому передаешь ProductGrid.load('shoes') в пропсе
Завтра
и этот компонент сам все делает
Roman
Ты упрощаешь или усложняешь?
упрощаю, я перемащаю весь boilerplate в умный компонент и делаю родительский компонент тупым. А ты предлагаешь делать родительский компонент супер-умным а всё что ниже - тупым.
Roman
в 10 раз по факту меньше кода
Rinat Valiullov
Это только для прошаренных группа или новичкам можно тоже?
Stanislav
Это только для прошаренных группа или новичкам можно тоже?
Заходи, садись, а дальше сам решишь
Завтра
@fredddie заранее советую избегать @piterden , если новичок
Rinat Valiullov
Оки, спс, щас вольюсь в тему
Rinat Valiullov
Все понял😂
Denis
https://jsfiddle.net/belanchuk/k1a4hj73/
Завтра
Роомаа, @Romshark
Завтра
Через недельку выкачу новый apicase, поможешь подводные камни с ssr разобарть?
Anonymous
Завтра
заодно твой вопрос решится более изящным способом
Roman
Через недельку выкачу новый apicase, поможешь подводные камни с ssr разобарть?
чем смогу как говорится
Завтра
ну я просто never used ssr
Завтра
посему не знаю, что там может пойти не так
Roman
ну я просто never used ssr
а вот мне он сейчас позарез нужен, ибо E-Commerce без поддержки SEO и Social Media это плохая шутка))
Denis
@fredddie заранее советую избегать @piterden , если новичок
Вот это ты зачем сказал? Давай я буду такую хуйню нести. Ты же взвоешь через день. Веди себя прилично