@agontarev ты случаем на хабре не светишься?

практически нет

Предпочитаю ориентироваться по солнцу^W IDE

А без иде хтмл писать это вообще конец

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

Я говорю про написание вложенных тегов, скорее

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

И будет десять закрывающих тегов, соответственно

Развели холивары в чатике про vue!!!!! Alarm 🚨

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

Ну если это не проблема, то зачем же его придумали и почему используют?

Ну если это не проблема, то зачем же его придумали и почему используют?

его придумали как шаблонизатор, а не как инструмент для НЕНАПИСАНИЯ закрывающих тегов

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

Но его почему-то все равно используют

И даже в доках преподносят возможность его использования как хорошую штуку

Почему же так?

во вью много чего можно сделать, но это не значит, что это правильно

Ну мы тут сейчас начали уже о вкусовщине

Мне нравится indentaion based, тебе нет

Но это не означает что оно правильное или неправильное

А по поводу этого кастомного лоадера - вот мне все же в angular-подобных шаблонах единственное что не нравится, так это что управляющие инструкции запрятаны в атрибуты, что никак не согласуется с моим чувством прекрасного

Вот такое вот все же сложнее распарсить глазами, нежели привычный иф

if divideOperations .divider

Выглядит куда более секси

как передать параметры в компонент и их там обработать, если в компоненте много тегов, а не один. ошибка вот такая Component template should contain exactly one root element. If you are using v-if on multiple elements, use v-else-if to chain them instead.

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

Ну понятно что самыми первыми, иначе можно сразу ногами бить

как передать параметры в компонент и их там обработать, если в компоненте много тегов, а не один. ошибка вот такая Component template should contain exactly one root element. If you are using v-if on multiple elements, use v-else-if to chain them instead.

Код покажи хоть примерно

как передать параметры в компонент и их там обработать, если в компоненте много тегов, а не один. ошибка вот такая Component template should contain exactly one root element. If you are using v-if on multiple elements, use v-else-if to chain them instead.

все именно так, как сказал компилятор - в темплейте должен быть лишь один элемент. выход - оберните ваш контент в див..

или во что-то другое

один "корневой" элемент, имеется в виду

Да, вот все же фрагментов не хватает

если вот такой код к примеру <template> <input type="text"> <textarea name="" id="" cols="30" rows="10"></textarea> </template> Как из родителя передать в него нужные мне параметры?

Сергей, этот код не заработает, пока вы весь этот контент не оберните в один элемент, див, шмив, что угодно)

то есть вот так надо ? <template> <div> <input type="text"> <textarea name="" id="" cols="30" rows="10"></textarea> </div> </template>

именно

а дальше все как в документации про Props

блин, точно) забываю что это обязательно(

дальше понятно уже)

спасибо)

Вот такое вот все же сложнее распарсить глазами, нежели привычный иф

ты пытаешься на маленьком примере показать преимущества, я с тем же успехом могу прям в компоненте писать fetch('/api/something'), и это будет намного лучше читаться, чем если бы я вынес отдельно и как нибудь инжектил зависимость, но в долгосрочной перспективе это уже не преимущество

Какое отношение DI имеет к "if как атрибут" против "if как внешняя управляющая инструкция"?

Это не имеет никакого отношения к долгосрочной перспективе, это чисто тактический элемент, который упрощает читабельность в конкретном месте

https://www.npmjs.com/package/slugify

подскажите как его в вью подключить? вроде сделал импорт, но всё равно не видет

Что говорит?

slugify is not defined"

Покажи код

Без {}

Агась

И надо в <script>

А не за его пределами

Прямо перед export default засунь import slugify from 'slugify'

Прямо перед export default засунь import slugify from 'slugify'

Туплю(

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

Можно ли как-то обновить значение input не через v-model?

Можно ли как-то обновить значение input не через v-model?

value атрибут, в смысле?

<input :value="someDataField"/>, например

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

В json его преобразуй и дальше работаешь как с обычным объектом

В json его преобразуй и дальше работаешь как с обычным объектом

спасибо)

Это не имеет никакого отношения к долгосрочной перспективе, это чисто тактический элемент, который упрощает читабельность в конкретном месте

ладно, давай так, мне нравится СИ подобный синтаксис, скобки {}, точка с запятой в конце строки и т.п.. И предположим я начал писать на питоне и воспользовался каким нибудь транспайлером, который бы позволял мне писать в СИ синтаксисе, что ты думаешь, это нормально?

На тебя все посмотрят как на знатного извращенца)

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

На тебя все посмотрят как на знатного извращенца)

а почему, мне так удобно, мне удобнее читать СИ синтаксис

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

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

Ну тогда это нормально

Потому что определение слова "норма" - это то, как делает большинство

Ну или хотя бы значимая часть

а правильно как будет?

И если значимая часть пользуется такой штукой, то это норма

А правильно будет как в дзене питона сказано

The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one— and preferably only one —obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea.

проще тогда джаву взять

ну так вот, в html тоже свои правила есть, свой синтаксис

Или javascript XD

А дзена хтмл нет

А читабельность-то все равно считается

А читабельность хтмла ниже чем читабельность пага

ну т.е. получается, что писать на питоне в СИ синтаксисе это говно, но чем больше будет таких как я, то это станет не говном, получается так?

И писабельность хтмла ниже писабельности пага

Ну да