Тогда картинка вставляется не как ссылка, а целиком код картинки вставляется в style

А это плохо?

Error http://localhost:8081/@/assets/logo.png 404 (Not Found)

@ убери

Честно, не знаю) По производительности не ударит?

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

logo в данном случае как пример, на самом деле это для сладера с картинками w:1920

logo в данном случае как пример, на самом деле это для сладера с картинками w:1920

Тогда картинки в папку static и подключать оттуда как обычно

Господа, может кто объяснит где я не прав и чего не понимаю. есть следующее: код - http://paste.org.ru/?ioeru6 разметка - http://paste.org.ru/?q6qdjo 3 компонента. через this.$emit вызываю событие. но толку 0.

событие должно дойти до приложения item->list->app

ну так можно по цепочке вызывать события и все

ан нет

Парни, а кто-нибудь делал breadcrumbs?

Если тебе надо передавать данные более, чем на один уровень вверх и ты не используешь вьюкс, то ты явно что-то делаешь не так

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

Если тебе это надо, то ты где-то накосячил в архитектуре

Приведи пример, где это необходимо

Я тебе напишу, когда попадется кейс

Просто, если тебе мало одного уровня общения между компонентами, то надо юзать вьюкс и не еть мозги себе и коллективу

а в скорости работы есть разница?

Потому что пропсы это в первую очередь данные, а эвенты - событие

Так что ивенты от пропсов отличаются только направлением

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

Зачем использовать Вью в стиле реакта? Не понимай

Давай спросим у Ильи Климова, посмотрим, может он новую мыслишку подкинет

Пропсы работают как ячейки в экселе с каскадным обновлением, а с ивентами так не работает, нет?

Пропсы работают как ячейки в экселе с каскадным обновлением, а с ивентами так не работает, нет?

Недавно мы взялись серьёзно за оптимизации и пришли к выводу что чем очевиднее написан код, тем легче и лучше он потом оптимизируется. И даже если писать где то больше - это того стоит, если "ленивый" способ неочевиден

Просто, если тебе мало одного уровня общения между компонентами, то надо юзать вьюкс и не еть мозги себе и коллективу

Вот то, что они не документируются - это беда. У нас то же самое. Приходится тратить кучу времени чтобы объяснить, почему так, а не иначе.

А он тебе - но работает же!

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

А ты ему крышкой рояля по пальцам

Формализуй в виде статьи

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

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

Не всегда. Есть хорошая идея? Ок, заюзаем в новом проекте. А в старом будь любезен, пиши так, как писали.