Comments 29
Советую Вам почитать документацию, и исправить заголовок с Vue для самых маленьких на Vue от самых маленьких. Мне ваши косяки просто лень перечислять....
Минус за комментарий, не несущий смысловой нагрузки. Лучшее, что вы могли бы сделать — перечислить хотя бы пару (если вам так лень) конкретных ошибок, либо просто не писать ничего. Вы можете быть супергуру в vue, но мне что-то сомнительно: специалисты дают обратную связь по делу, а не надувают щёки, пиарясь за чужой счёт.
Ну, хотя бы стоило попробовать composition API :)
Дак а смысл? Изменился синтаксис и теперь группировать код в компоненте можно по смыслу, а не типам как в Options API (data, computed, watch, ...). Если изначально компоненты не нагружать лишними обязанностями, а выносить все в сервисы и модели, то и сами компоненты будут не «тяжелыми» и бизнес-логика и сервисы могут быть переиспользованы. Вообщем Composition API на первый взгляд попытка Vue бороться с говнокодерами и быть похожемы на React и не более. Но возможно я не прав)
Ну, хотя бы стоило попробовать composition API :)Так как еще не вышло, то рановато рекомендовать использовать в реальных проектах)
Если изначально компоненты не нагружать лишними обязанностями, а выносить все в сервисы и модели, то и сами компоненты будут не «тяжелыми»Думаю, что запаритесь выносить. Состояние и методы жизненного цикла вряд ли получится легко вынести. К тому же каждый будет это по разному делать, что плохо.
Composition API на первый взгляд попытка Vue бороться с говнокодерами и быть похожемы на React и не более.думаю, что так и есть. И как результат стремления сделать аналогичную фичу, унаследуется часть проблем хуков. Получилось, что у компонента по прежнему 2 обязанности — он является контейнером для дополнительной логики и сам содержит логику. Из-за возможности писать логику в самом компоненте, получаем компоненты с захардкоденной логикой, которую не убрать или не расширить. В случае сторонних компонентов, это та еще головная боль.
Я с vue почти не знаком, поэтому возможно некоторое из перечисленного ниже к нему не применимо. Ну и статью я поверхностно посмотрел, так что прошу прощения, если что-то уже указано в статье.
1. Сколько не пишу, а группировка файлов by features в разы удобнее, чем по типам сущности (стор, компонент, api).
2. Пробовал один общий стор и несколько. Несколько оказалось удобнее.
3. Когда сторов несколько (у вас не та ситуация), не вижу особой надобности создавать еще и модели. Максимум описание типа объекта задавать, чтобы использовать правильный тип при передачи в функции.
4. Передача и вызов Api в сторе?
А если api вызов обновляет несколько сторов или разные участки общего стора?
Если по каким-то причинам вместо «async await» нужно будет что-нибудь другое?
Вместо такого подхода:
вызвать метод стора, стор вызовет api, стор обновит свое состояние.
я такой предпочитаю:
вызвать api метод, api метод вызывает метод обновления стора.
5. blog.js у вас на верном пути к god object. Увеличьте количество полей в его state до нескольких десятков и представьте, насколько он увеличится, если ко всему этому написать геттеры, мутации, сеттеры.
1. Сколько не пишу, а группировка файлов by features в разы удобнее, чем по типам сущности (стор, компонент, api).
Для меня если честно загадка почему) Поиск файлов плюс/минус один и тот же, структурно выглядят плюс/минус также.
3. Когда сторов несколько (у вас не та ситуация), не вижу особой надобности создавать еще и модели. Максимум описание типа объекта задавать, чтобы использовать правильный тип при передачи в функции.
В данном проекте модели излишки с точки зрения бизнес-логики, но для типизирования я думаю их в любом случае лучше заводить (каких бы размеров не был проект), тогда компоненты становятся более «понятными».
4. Передача и вызов Api в сторе?… я такой предпочитаю:
вызвать api метод, api метод вызывает метод обновления стора.
А не превращается это в кашу? Ну то есть компоненты могут обращаться и к store (как минимум для чтения) и к API, а по факту действий ровно столько же, только инициирует их API, а не store. Мне кажется лучше компоненты отделять от API, ну по крайней мере не могу представить кейс когда обращение только к store усложнит приложение.
5. blog.js у вас на верном пути к god object. Увеличьте количество полей в его state до нескольких десятков и представьте, насколько он увеличится, если ко всему этому написать геттеры, мутации, сеттеры.
Да, согласен, лучше раскидать по файлам: getters, mutations, actions, store
Будет в проекте 100 страниц-компонентов в папке pages, 100 файлов в папке api, 100 файлов в папке store. 3 файла в этих разных папках нужны для работы с одной страницей. Получается, для работы с одной страницей нужно периодически прокручивать списки из сотни файлов и искать там нужный файл.1. Сколько не пишу, а группировка файлов by features в разы удобнее, чем по типам сущности (стор, компонент, api).Для меня если честно загадка почему) Поиск файлов плюс/минус один и тот же, структурно выглядят плюс/минус также.
Хм, возможно используемый вами вариант и вправду будет лучше. Как минимум, зависимостей будет меньше и структура попроще. Надо попробовать в будущем.4. Передача и вызов Api в сторе?… я такой предпочитаю:А не превращается это в кашу? Ну то есть компоненты могут обращаться и к store (как минимум для чтения) и к API, а по факту действий ровно столько же, только инициирует их API, а не store. Мне кажется лучше компоненты отделять от API, ну по крайней мере не могу представить кейс когда обращение только к store усложнит приложение.
вызвать api метод, api метод вызывает метод обновления стора.
5. Да, согласен, лучше раскидать по файлам: getters, mutations, actions, storeЭто особо не изменит ситуацию.
state, getters, mutations, actions для articles лучше вынести в файл articlesStore или articlesModule. И по аналогии поступить с comments, categories и остальным.
Думаю, что запаритесь выносить. Состояние и методы жизненного цикла вряд ли получится легко вынести. К тому же каждый будет это по разному делать, что плохо.
Немного не про это речь. Все что относиться к компоненту, должно находиться в компоненте. Выносить нужно то, что относиться к бизнел-логике, либо работе с данными (ту же самую обработку данных после получения из store, лучше сразу вынести в отдельный геттер (если это используется еще где-то, или если обработка занимает значительный кусок кода, если нет то computed), также выносить вспомогательные функции в сервисы/хелперы, которые занимаются общими вещами (тот же самый Display из статьи, или допустим формирование дерева меню лучше вынести из компонента (даже несмотря на то что используется это только в единственном компоненте). Вообщем в идеале в компоненте должна остаться только логика компонента, обращение к store и хелперам
Вообщем в идеале в компоненте должна остаться только логика компонента, обращение к store и хелперамИ 100% рано или поздно возникнет ситуация, когда эта же логика или ее часть понадобится в другом компоненте. Вот чтобы эту логику не писать повторно, придумывают разные штуки вроде composition API.
Есть наследование компонентов и слоты для таких ситуаций. Ну и в целом никто не мешает кусок функционала вынести в класс-helper и обращаться из компонента уже к нему.
Ну и раз уж зашел разговор, а как composition API, то спасет от этого?
Ну и раз уж зашел разговор, а как composition API, то спасет от этого?
У наследования и слотов свои проблемы.
github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md#multiple-logic-topics
Этот пример получше выглядит, чем выглядел бы с использованием наследования или слотов.
github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md#multiple-logic-topics
Этот пример получше выглядит, чем выглядел бы с использованием наследования или слотов.
Ну и в целом никто не мешает кусок функционала вынести в класс-helper и обращаться из компонента уже к нему.До того момента, пока не приходится использовать чужие компоненты, где этого не сделали. composition API правда от таких случаев тоже не поможет. Он только предоставляет стандарт для возможности выносить дублируемую логику.
Этот пример получше выглядит, чем выглядел бы с использованием наследования или слотов.
Дак а там и вообще не про наследование))) Ну, а по поводу лучше/хуже — визуально разница только в местонахождении логики, никаких профитов не вижу (по факту это группировка by features и не by types, тоже самое что и с файлами).
Да, пример не про наследование. Другого примера для vue не нашел.
Насчет наследования и композиции лень что-то искать. Просто скину ссылку на свою статью. Почитайте там пункт «Сложные иерархии классов юнитов, предметов и прочего»:
habr.com/ru/post/255561
Там про композицию в играх, но суть та же.
Насчет наследования и композиции лень что-то искать. Просто скину ссылку на свою статью. Почитайте там пункт «Сложные иерархии классов юнитов, предметов и прочего»:
habr.com/ru/post/255561
Там про композицию в играх, но суть та же.
В третьей версии попробуем))
Как будут обстоять дела с индексацией поисковиками нашего блога? Стоит ли его создавать, если никто не сможет его найти?
Немного не про это статья) Тут суть была в том, чтобы показать как структурно должно все выглядеть, а чтобы описать все «тонкости» SEO это нужно как минимум парочку статей, да и не полностью это от фронта зависит.
А какой толк от статьи, если её нельзя применить. SPA применимо только для аля Личных кабинетов.
Кто-то прочитает ведь и сделает блог, а потом будет ломать голову, почему его не читают.
Можно делать так vuejs.org/v2/guide/ssr.html
Эээ, почему ее нельзя применить? Да скорее всего промахнулся с названием статьи, ведь суть статьи не в создании блога, а в создании ПРАВИЛЬНОЙ структуры SPA на примере блога.
Никто почему-то не задаётся вопросом «а нужно ли делать простенький блог на SPA-архитектуре». Да и вам всё равно, судя по ответу на вопрос о том, найдут ли такой блог поисковики. Ещё можно написать статью «складываем 2+2 на TypeScript», подумайте об этом.
Видимо я очень сильно промахнулся с названием, либо вы просто дальше заголовка не читали) В статье описана оптимальная структура SPA (на примере блога), также описан пример работы с роутером и с vuex, как именно должны они взаимодействовать с компонентами. И все эти рекомендации можно смело применять и к большому приватному корп порталу (не нуждающего в великом и ужасном SEO) и к мать его простенькому блогу на примере которого были рассмотрены эти рекомендации!
P.S. «знатоки» и в задачке «2+2» могут говна наплодить ;-)
P.S. «знатоки» и в задачке «2+2» могут говна наплодить ;-)
Большое спасибо за статью. Очень познавательно видеть лучшие практики в таком примере.
Спасибо за статью. Не знаю почему все докопались до SSR, это просто пример.
PS: Если хотите использовать этот пример в своих целях(сео там и прочее), то лучше смотреть в сторону Nuxt.js, который вам предоставит SSR, стор и мидлвары из коробки без плясок с бубном.
PS: Если хотите использовать этот пример в своих целях(сео там и прочее), то лучше смотреть в сторону Nuxt.js, который вам предоставит SSR, стор и мидлвары из коробки без плясок с бубном.
Когда речь идет «ДЛЯ МАЛЕНЬКИХ» почему бы сразу не взять правильный пример, многие тут правы про СЕО, я как МАЛЕНЬКИЙ взял бы и сделал по вашему гайду блог, а потом бы ломал голову в поисках ответа, вернулся бы к документации, или узнал бы про Nuxt. Почему бы сделал по вашему гайду, да потому-что МАЛЕНЬКИЙ я в(о) Vue!
Технология домостроения для Маленьких, небольшой 25-этажный каркасный дом. Теоретически и практически можно построить такой дом, но последствия печальны!
P.S. Спасибо за старания, за статью. Статья становится более полезной, после прочтения комментариев.
Технология домостроения для Маленьких, небольшой 25-этажный каркасный дом. Теоретически и практически можно построить такой дом, но последствия печальны!
P.S. Спасибо за старания, за статью. Статья становится более полезной, после прочтения комментариев.
Sign up to leave a comment.
Vue для самых маленьких a.k.a небольшой блог по всем канонам