Парни, кто-нибудь юзал http://monterail.github.io/vue-multiselect ?

Юзал

Юзал

У тебя стили подгркзились при использовании компонента?

Или там надо руками их добавлять?

Или там надо руками их добавлять?

Ох, падажи, щас посмотрю

Или там надо руками их добавлять?

Нет, не посмотрю. Пройдись по импорту в node_modules и посмотри че там экспортируется

Или там надо руками их добавлять?

И ещё. Раньше надо было ставить версию 'next'. Об этом на гитхабе написано. Как сейчас - не знаю, не обновлял

Всем привет, есть приложение на django rest framework и vueJS, такой вопрос, как организовать сео? ssr для vue нет, думаю по юзер-агенту определять роботов и отдавать нужную страничку уже отрендеренную, какие могут быть еще способы? Переводить на nuxt последный способ, тк проект большой уже

А страниц много и динамические?

Webpack prerender plugin. Prerender.io

много но это только странички постов: author/post-permlink

и страничка автора: /author, это все

что значит ssr нет?

Есть vue-router, все рендерится только на клиенте

Ну.. так самым оптимальным вариантом запилить ssr, и уже рулить как и что отдавать. Роботам или вообще первую страничку по урлу

Когда у нас стал вопрос seo, мы проанализировали nuxt и пререндер. И то и другое глючная шняга. В ssr тонкое место только генерация контента в строку. Но благо Эван отвечает молнеиносно. Всё управление у тебя в руках

Нужен самый быстрый варивант) Мне кажется если сейчас начать переводить все на nuxt то может много подводных камней появиться. "запилить ssr" ты имеешь в виду то что я описал? Отдельный ответ с html для поисковиков и роботов

Я имею в виду https://ssr.vuejs.org/

То что будет потдерживаться из коробки и релизиться вместе с пакетом.

@xanf_ua Я с flow не знаком от слова совсем, так что призываю магистра :) Неоднократно была озвучена мысль о сложности типизации при использовании Vue. Почему тогда в исходниках сплошные /*@flow*/ стоят?

Потому что vue типизирован внутри себя

Но наружу он никакие типы не экспортирует

Более того сам синтаксис объектов vue усложняет типизауию

думаешь, это было специально задумано автором(-ами)? Просто, если типизация - это панацея (подобные мысли звучат в разных местах), логично было бы во фреймворке, набирающем популярность и код которого типизирован, максимально способствовать внедрению типизации.

Нет

Да и сам флоу был внедрен не сразу в v Ue

Я изучал историю вопроса

коммиты разгребал? )

Агась

это сурово, если так

кстати, мнение по поводу видео: лучше продолжительность не менее 7-10 минут и не более получаса. Если получается длинное по одной теме, то лучше разделить по отдельным ключевым мыслям, а если не получается разделить, чтобы не терять цепь рассуждений, то лучше длинное видео, чем куча коротких :) Под длинным видео можно меточки/содержание сделать: на такой минуте об этом, на этакой - о том.

https://github.com/vuejs/vue/pull/5887 вот такое видел, но хз насколько эти изменения релевантны

Это для тс

Парни, кто тут в верстке хороший опыт имеет, у меня чисто идеологический вопрос.

Парни, кто тут в верстке хороший опыт имеет, у меня чисто идеологический вопрос.

Давай

Я на том же опыте бутстрапа привык делать какой-то набор компонентов для интерфейса, с какими-то общими классами типа .btn .btn-primary .btn-bg ну и описывание взаимодействия этих компонентов, типа как будут вести себя .btn внутри блока .input-group. А потом уже кастомизировать стили и поведение этих компонентов в зависимости от макетов. Ну например, надо мне немного изменить вид стандартной, для моего ui кита, кнопки в окошке логина, то я в стилях так и пиши .login-form .btn {width: 100%}. Просто сейчас делаю свой хобби проект, и мне помогает начинающий верстак, и он там все по бэму делает. и мне кажется что это все слишком многословное и описывает каждый чих в интерфейсе, хотя по факту интерфейс это куча повторяющихся компонентов с одинаковыми стилями на основные события типа ховера и т.д.

и вот вопрос, то ли у меня, в силу того что много работал со всякими бутстрапами , не правильное понимание процесса верстки, то ли верстак бэм использует как-то не так, толи бэм вообще не нужен.

Сложно сказать

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

и надо сделать элемент переключалку(типа табы)

почему бы не использовать для этого уже готовые классы для кнопок, типа .button .big и на активную довешивать класс .active

зачем делать

Для того чтобы это были независимые элементы интерфейса

Чтоб их стили не влияет друг на друга

Для того чтобы это были независимые элементы интерфейса

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

так это основные элементы

Если это глобально так, то неверно

сделай блок .some-tabs и в нем перелпредели нужные стили для .btn

Если же сейчас просто так они выглядят то сверстаро верно

Почитайте какую задачу бэм решает

Он отвязывает стили компонентов от их положения в доме

Чтоб их можно было свободно тасовать потом.

>БЭМ (Блок, Элемент, Модификатор) — компонентный подход к веб-разработке. В его основе лежит принцип разделения интерфейса на независимые блоки. Он позволяет легко и быстро разрабатывать интерфейсы любой сложности и повторно использовать существующий код, избегая «Copy-Paste».

Крайне облегчает изменение вёрстку потом - изменение расположения компонентов (в терминах бэмйа блоков) на странице гарантированно йге ломает верстку

Он отвязывает стили компонентов от их положения в доме

так а как это влияет на то что в приведенном мной примере не использовать .input-group, .btn и прочее

ну т.е input-group_2 это не повторно используемый код

В том что нельзя стилизовать по правилам бэма "кнопку внутри логин контейнера"

.login .btn

Потому что потом окажется что блок логин переместился ещё куда-то, а там есть свои стили на кнопках и т. д..

как по мне - бэм слишком занудный и мелочный bootstrap-like вариант мне больше симпатизирует да, бэм решает вышеописанный вопрос, но вынуждает писать кучу лишнего, имхо но так, как верстаю я, лучше не видеть никому

или тот же input-group__link_primary. Получается что для кнопки внутри группы будет input-group__btn_primary, для обычного линка будет link_primary, для обычной кнопки будет btn_primary? хотя по факту все эти элементы должны выглядеть одинаково

Да,лишнее приходится. Бэм оправдан только когда команда работает

или тот же input-group__link_primary. Получается что для кнопки внутри группы будет input-group__btn_primary, для обычного линка будет link_primary, для обычной кнопки будет btn_primary? хотя по факту все эти элементы должны выглядеть одинаково

Блоки обязаны быть независимы

ERROR: S client not available

Чтоб их стили никак не взаимодействовали друг с другом

.login .btn

так а если писать с >

Блоки обязаны быть независимы

короче получается что будет удобен (возможно), когда у тебя все будет меняться все время?

или дополнительный .btn-login

так а если писать с >

ну это ситуативно

я у себя кастомным кнопкам просто новые классы добавляю

типа .btn-bet, .btn-retry итд

+ юзаю scoped-стили, поэтому блоки у меня все равно независимыми выходят

Ещё раз - бэм оправдан когда допустим сайт пилят разные люди и нужно гарантировать что любое изменение не поломает вёрстку к хренам

в том же router-link приходится все время явно указывать активный класс. Это конечно я придираюсь, но все же

Другими словами что стили не привязаны к вёрстке

та мы поняли

но пока я не в команде, никто меня не заставит верстать по бэму)0)0)))

тогда я не понимаю как добиться повторно использовать существующий код, избегая «Copy-Paste». ?

если все блоки независимы

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

но пока я не в команде, никто меня не заставит верстать по бэму)0)0)))

а почему? Это же удобно

мне это неудобно, выше написал, почему

ну вот мне не удобно

Хорошо, давайте посмотрим другие варианты

да ну зачем другие, вот конкретный пример из практики =)

Не не, я про другие методологии. Задачу оставим

Мне кажется, вам тогда понравится oocss

https://www.smashingmagazine.com/2011/12/an-introduction-to-object-oriented-css-oocss/

http://oocss.org/

Пример тут, https://github.com/AleshaOleg/holy-grail-markup/tree/master/oocss

Еще есть совсем упоротая фигня, как atomic

https://acss.io/

Очень возможно, что вам зайдет. Да, люди будут вас проклинать за это, когда будут заходить на проект

Но количество стилей, при применении atomic значительно меньше

Особенно это будет плюсом на больших проектах. Пример тут: https://github.com/AleshaOleg/holy-grail-markup/tree/master/atomic Извините, что пишу по одному сообщению

Но атомик лучше не брать, это дичь полная. Больше для ознакомления. А вот oocss вполне нормально, если не нравится бэм