подскажите, почему такой огромный размер файла app.js? 2.8 mb как-то черезчур. http://dl3.joxi.net/drive/2017/05/30/0016/3113/1055785/85/eb81680164.jpg

$ npm install —save-dev webpack-bundle-analyzer

да ну?

Ага. Можно ошибиться и не узнать об этом

Так же и тег закрыть можно не верно )

О, нарыл решение, теперь ошибки нет, но и шаблон не отображается, Вот что прописал в package.json "browser": { "vue": "vue/dist/vue.common.js" }

Так же и тег закрыть можно не верно )

в современных редакторах эта ошибка практически исключена

да ну?

>Use npm run build —report to build with bundle size analytics.

Так же и тег закрыть можно не верно )

Неа. Vue орать будет

в 2.2+ точно

>Use npm run build —report to build with bundle size analytics.

ога, посмотрю

Так он и на pug орать будет, они компилятся в html

нет. Pug закроет тэг в любом случае

https://github.com/bootstrap-vue/bootstrap-vue/ Юзал кто нибудь ? Как вам ?

pug удобнее в плане того, что все более минималистично выглядит, а так, не вижу смысла его использовать, ибо тот же emmet во всех современных редакторах позволяет писать хтмл со скоростью написания разметки на pug

pug удобнее в плане того, что все более минималистично выглядит, а так, не вижу смысла его использовать, ибо тот же emmet во всех современных редакторах позволяет писать хтмл со скоростью написания разметки на pug

паг прикольно использовать со stylus, иногда кусочек иерархии можно скопировать прямо в styl

особенно если у тебя сначала идет <template lang="pug"></template>, а потом еще и скрипты со стилями тоже в хтмл виде, получается немного каша из хтмл и пага

и еще в emmet нету миксинов

да и в целом, переделать Pug разметку проще, не надо ловить закрывающие дивы оберток

подскажите, почему такой огромный размер файла app.js? 2.8 mb как-то черезчур. http://dl3.joxi.net/drive/2017/05/30/0016/3113/1055785/85/eb81680164.jpg

отличный вопрос ?

если вам вдруг нужна расстановка БЭМ классов, снова паг очень выручает от рутины

Вообще, мне нравится pug, но до опыта во vue компонентах с использованием пага я не дошел еще)

если вам вдруг нужна расстановка БЭМ классов, снова паг очень выручает от рутины

В Vue не сильно нужен бэм

да и миксины паговские там по моему тоже не особо нужны

Да, pug прикольно, но как доходит до дела (а не поиграться с минималистичностью), то лично мне проще без него

В Vue не сильно нужен бэм

есть разные мнения на этот счет

Ок)

хотя я с вами согласен

и тем не менее я вижу что бэм проскакивает то там то сям

❤️ БЭМ, но в Vue можно и без него.

Ребята, помогите советом. Раньше писал на реакте. Достаточно быстро пришел к тому, что redux нужен, чтобы не пробрасывать эвенты вверх до корневого компонета и не обрабатывать все там. Тут же как я понял мельком почитав чатик vuex особо не жалуют, считая, что в 90% случаев он не нужен. Как быть, когда на пятом уровне вложенности есть компонент AddComment, который должен принять от юзера текст коммента и после этого нужно отправить этот текст на сервер? Пробрасывать эвент до верхнего компонета, где и сделать запрос или делать запрос прямо из этого компонента (как тут выразились сделав его самостоятельной боевой единицей)?

СБЕ

+1

Ребята, помогите советом. Раньше писал на реакте. Достаточно быстро пришел к тому, что redux нужен, чтобы не пробрасывать эвенты вверх до корневого компонета и не обрабатывать все там. Тут же как я понял мельком почитав чатик vuex особо не жалуют, считая, что в 90% случаев он не нужен. Как быть, когда на пятом уровне вложенности есть компонент AddComment, который должен принять от юзера текст коммента и после этого нужно отправить этот текст на сервер? Пробрасывать эвент до верхнего компонета, где и сделать запрос или делать запрос прямо из этого компонента (как тут выразились сделав его самостоятельной боевой единицей)?

Имхо второй вариант

СБЕ?

Самостоятельна боевая единица

а понял)

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

чтоб два раза не вставать и новый добавляемый комментарий сразу отображать

можно использовать шину событий для этого, гугли vue-bus

можно использовать шину событий для этого, гугли vue-bus

Шина примерно тоже самое что и в root событие отправлять

а показать лоадер пока идет запрос на добавление? Если пробрасывать наверх. Это мне надо пробросить наверх событие, там установить props isFetching, пробросить его вниз до AddComponent, который покажет или скроет прелоадер. Геморой какой то:)

делай шину

Объясните

понял почитаю про vue-bus. Он получается прокидывается насквозь всем компонетам ?

Почему vuex не актуален

а показать лоадер пока идет запрос на добавление? Если пробрасывать наверх. Это мне надо пробросить наверх событие, там установить props isFetching, пробросить его вниз до AddComponent, который покажет или скроет прелоадер. Геморой какой то:)

А лоадер можно и не показывать. А скажем так считать отправку коммента по умолчанию оптимистичной)

ну а если все же надо?)

тогда да, надо прокидывать

потом же всё равно автоматом будет работать

спасибо реактивности :)

тяжко перестроить мозг после реакта. Спасибо

тяжко перестроить мозг после реакта. Спасибо

Перестраивайте тогда в сторону - все работает от данных) меняем как хотим, везде привязки остальное обрабатывают

еще вопрос: как по феншую код организовывать? Файл SomeComponent.vue. В нем 3 секции: <template> </template> <script> </script> <style> </style> Так?

типа как тут: https://laracasts.com/series/learn-vue-2-step-by-step/episodes/16

Можно и по src подключать

если слишком большие файлы

по src?

я обычно пишу в одном файле, не слишком много кода выходит... иногда стили из файла подключаю

Понял. Ну также 3 блока же? template, script, style? В реакте просто один объект экспортится.

киньте плиз если есть в меня чем то типа best practices, чтоб поменьше граблей собрать

Три блока, если в template много вёрстки, стараюсь разбить на компоненты. Если стили глобально можно заюзать, то в блок style не пишу такие. Ну а script бывает толстоват, но не сильно.

ага, понял, спасибо

Что скажите господа?

Что скажите господа?

Не аутентифицируй

ERROR: S client not available

киньте плиз если есть в меня чем то типа best practices, чтоб поменьше граблей собрать

Нету как таковых :) чем проще делаешь тем лучше, как по мне этой best practice хватает

Если можно опросик бы хотел небольшой. Не супер пупер большой проект. Как бы строили: 1. Vuex 2. Самостоятельные компонеты 3. Всякие общие шины

Что скажите господа?

Альтернатива?

Да я ж хз, я не юзал jwt

Вбросил чтобы послушать

годно. еще бы первую часть, но думаю она тоже гуглится

Если можно опросик бы хотел небольшой. Не супер пупер большой проект. Как бы строили: 1. Vuex 2. Самостоятельные компонеты 3. Всякие общие шины

я пока до vuex и шин не дорос, поэтому №2

Если можно опросик бы хотел небольшой. Не супер пупер большой проект. Как бы строили: 1. Vuex 2. Самостоятельные компонеты 3. Всякие общие шины

Смотря что требуется от проекта. Но в любом случае самостоятельные компоненты

Vuex нужен, когда он действительно нужен

когда например?

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

когда много разных компонентов должны оперировать одинаковыми данными, которые и удобнее вынести вынести в стор

Опять же, такое не в каждом проекте может потребоваться

когда много разных компонентов должны оперировать одинаковыми данными, которые и удобнее вынести вынести в стор

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

решил просто шину делать. ну нет time-travel ну и что.

В этом и прелесть) можно делать одно и тоже по-разному, как в конкретном случае удобнее и больше нравится

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

Эээ, а как же mapMutations?

а напомни, что он там делает? добавляет в computed штуки из стора?

а напомни, что он там делает? добавляет в computed штуки из стора?

Да, делает возможность вместо this.$store.commit('blabla', ...) писать this.blabla(...)

ну, это конечно важная фича, но у меня не так много полей, чтобы париться из-за этого ?

можно самому написать, btw

Если в компоненте живет отдельно выступающий "цирк шапито" то ладно. Но если у нас есть общее состояние приложения, даже не сосотояние а условно переменные, то произвольное изменение их создаст бардак в коде. Я уже как бы молчу о чистых функциях и впринципе и вообще

а показать лоадер пока идет запрос на добавление? Если пробрасывать наверх. Это мне надо пробросить наверх событие, там установить props isFetching, пробросить его вниз до AddComponent, который покажет или скроет прелоадер. Геморой какой то:)

Делай отправку коммента из компонента добавления коммента (AddComment) и вешай лоэдер в этом же AddComment. При получения успешного ответа от сервера, эмить событие (add-comment) с payload в виде информации коммента. В родителе слушаешь @add-comment на AddComment и пушишь новый коммент в массив предыдущих комментов, которые ты рендерил через v-for. Все автоматом перерисуется.

А лоадер можно и не показывать. А скажем так считать отправку коммента по умолчанию оптимистичной)

будет красиво, но больше морочится надо с UI, если учитывать проблемы при отправке :)

еще вопрос: как по феншую код организовывать? Файл SomeComponent.vue. В нем 3 секции: <template> </template> <script> </script> <style> </style> Так?

У меня разметка в vue файле. Примерно так: <template> <div>my template</div> </template> <script src="./MyComponent.js"></script> <style src="./assets/styles/MyComponent.scss" lang="scss"></style> У каждого компонента своя папочка.

Если можно опросик бы хотел небольшой. Не супер пупер большой проект. Как бы строили: 1. Vuex 2. Самостоятельные компонеты 3. Всякие общие шины

Щины не нужны. Vuex в зависимости от функциональности. Если нужно использовать одни данные для нескольких компонентов. Например, есть журнал платежей. И есть форма добавления платежей. Все это, естественно, в разных частях приложения. С Vuex удобно будет добавить новый платеж в журнал платежей.

будет красиво, но больше морочится надо с UI, если учитывать проблемы при отправке :)

а чего там за проблемы, в catch переиспользовать функцию удаления коммента по ID

а чего там за проблемы, в catch переиспользовать функцию удаления коммента по ID

Не, я в плане ux. Рисуешь лоэдер. Если не получилось, скрываешь. Показываешь уведомление, что "не смогла". Показываешь кнопку попробовать снова... Возни много)) С лоэдером быстрее и проще, особенно если научить лоэдер отображать ошибки ;)

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

Щины не нужны. Vuex в зависимости от функциональности. Если нужно использовать одни данные для нескольких компонентов. Например, есть журнал платежей. И есть форма добавления платежей. Все это, естественно, в разных частях приложения. С Vuex удобно будет добавить новый платеж в журнал платежей.

как-то категорично про шины. Я думаю, что есть проекты, где vuex как из пушки по воробьям

мне кажется меньше работы)