ND
Сугубо дело вкуса и как удобнее. Лучше один раз написать полный путь екшена нежели писать его каждый вызов на странице, или городить обёртку.
Size: a a a
2020 April 11
ND
Тут вопрос в том, что у тебя вся логика по факту во вуексе
ND
А я его использую чисто для авторизация и общие данные
ND
И тут дело вкуса
ND
Ктотон городить умные компоненты, а кто-то тупые и кидает всю логику на страницу
ND
А кто-то в вуекс
Y
Мені здається в в'юшках має бути лише html, css і анімації, без складної логіки
ND
И тут наши мнения расходятся
ND
Я считаю что на много приятнее открыть страниц и понять что она делает
ND
Нежели искать ее логику и Стейт по разным местам
Y
Я просто раз прогорів запихаючи в в'юшки запити, а коли потрібно було робити інші компоненти з подібними запитами була така мішанина
ND
Я просто раз прогорів запихаючи в в'юшки запити, а коли потрібно було робити інші компоненти з подібними запитами була така мішанина
В чем мишанина?
ND
У меня отдельный объект апи, в котором методы. Под каждый ендроинт свой экземляр
ND
Импортеул его и работаешь с его гет, апдей....
Y
Можна й так впринципі, але то таке, мені подобається все тримати в vuex
ND
Можна й так впринципі, але то таке, мені подобається все тримати в vuex
Дело вкуса)
B
Привет
xslt
xpath 1.0 как найти максимум ?
пример найти max year в
https://www.w3schools.com/xml/tryxslt.asp?xmlfile=cdcatalog&xsltfile=cdcatalog_ex2
xslt
xpath 1.0 как найти максимум ?
пример найти max year в
https://www.w3schools.com/xml/tryxslt.asp?xmlfile=cdcatalog&xsltfile=cdcatalog_ex2
B
пробовал
но не подошло
<xsl:value-of select="catalog/cd[not(preceding-sibling::year >= ./year)
and not(following-sibling::year > ./year)]/year"/>
но не подошло
2020 April 13
TS
Но блин, назвать екшен чисто fetch это как-то фигово.
Не згідний. При правильній структурі такі назви мають дуже хороше значення. Всюди фетч, і не треба пам'ятати де який. Головне, щоб контекст був. Власне при використанні мобікс-стейт-трі, в мене є моделі, які менеджать списки, от в таких моделей завжди є fetch та fetchMore. А саме яка вже це модель і задає контекст що саме цей фетч буде робити.
ND
Не згідний. При правильній структурі такі назви мають дуже хороше значення. Всюди фетч, і не треба пам'ятати де який. Головне, щоб контекст був. Власне при використанні мобікс-стейт-трі, в мене є моделі, які менеджать списки, от в таких моделей завжди є fetch та fetchMore. А саме яка вже це модель і задає контекст що саме цей фетч буде робити.
Я слишком пьян, что бы обосновано тебе ответить. Если не отвечу завтра, тегни пожалуйста