Имеет ли такое соглашение для названий компонентов и классов во vue.js право на жизнь?

Question

[Александр]

Очередной раз размышляя на тему структуры своего проекта и изучая style guide vue.js я пришёл к своему варианту нейминга компонентов и стилей в них. Основным вопросом для меня была проблема с тем как называть вложенные компоненты. Раньше я использовал такие имена: Component.vue, ComponentNestedElement.vue и т. д. Но что это нам даёт? Как нам понять структуру вложенности компонента по его имени? Как понять, что ComponentNestedElement.vue вложен в компонент Component.vue, а не в ComponentNested.vue, который в свою очередь вложен в Component.vue? Данное соглашение для имён компонентов используют кажется вообще все, но ведь оно явно приводит к путанице.
Так же я использовал для имен классов БЭМ, который в свою очередь тоже имеет те же проблемы.

Итого я пришёл к такому соглашению для имён компонентов: ComponentName-NestedComponentName
И вот такому соглашению для имён классов: ComponentName-NestedComponentName__elementName-nestedElementName--modifierName

Почему что-то подобное не используют все?

Comments

[Vitaliy]

выглядит ужасно

[Александр]

Виталий Столяров, ну в целом добавление большего количества правил к данным соглашениям действительно вызывает на первый взгляд отторжение. Но я точно могу сказать, что после того как я переименовал свои компоненты по такой системе мне стало в разы проще ориентироваться среди них.

Для сравнения, часть компонентов в моём проекте в обычном виде и те же компоненты с новым неймингом:




Ведь явно во втором случае намного нагляднее и информативнее

[Maxim Colesnic]

А представьте что вам надо использовать Lobby-Market-List-Item.vue в другом месте. К примеру в Libby-Popular-Market-Items-List.vue

[Александр]

Maxim Colesnic, в таком случае это явный признак того что нужно вынести этот компонент из views в common

[Александр]

Maxim Colesnic, собственно это вообще как относится к предмету вопроса?

[Алексей Николаев]

Александр, а мне кажется, вы не попробовали поместить фмльтра в скоуп Filters, навигацию - в Navigation и так далее. Сразу станет еще информативнее и нагляднее, чем на втором пике, и читаться будет легче.

[Александр]

Алексей Николаев, можно пример?

[Сергей delphinpro]

Фигня.
Официальные рекомендации Vue по именованию компонентов вполне себе подходящие.
ИМХО.

[Александр]

Сергей delphinpro, чем они лучше? Ну объективно. Думаю спорить о том, что в моём варианте больше информативности не будете.

[Сергей delphinpro]

Александр, В вашем варианте излишняя информативность.

[Александр]

Сергей delphinpro, почему излишняя? Мне вот она помогает.

[Сергей delphinpro]

Александр, Компонент - это независимый элемент в идеале. Блок в БЭМе тоже независимый. Ваш стиль именования жестко привязывает одни сущности к другим.
А если у вас будет тройная вложенность? Будете городить компоненты Com1-Com2-Com3? Ну бред же...
или вы будете писать только два — Com2-Com3? Тогда вы сами себе будете противоречить, нарушая собственную систему.

[Сергей delphinpro]

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

src/
  components/
    ComMenu/
      ComMenuItem.vue
    ComMenu.vue

Или даже так

src/
  components/
    ComMenu/
      ComMenuItem.vue
      index.vue /* компонент ComMenu*/

import './ComMenu';
import './ComMenuItem';

[Александр]

Сергей delphinpro, и 5-рная вложенность, если надо. Собственно вложенность в style guide упоминается и считается нормой. Вложенность в данном случае - деление большого компонента на несколько маленьких ради избежания лапше кода.

[Сергей delphinpro]

Александр, Ну если вас устраивает, то норм. Лично я бы не хотел столкнутся с таким кодом =))

[Александр]

Сергей delphinpro, index.vue (index.js) - вообще зло. Обожаю когда сверху куча кладок с одинаковым названием index.js, кстати в style guide это упоминается. Удивительно что вы мне советуете такую плохую практику.

[Сергей delphinpro]

Александр, Моя IDE пишет на вкладках ComMenu/index.vue =)
Но в целом я тоже стараюсь избегать подобного.

[Александр]

Сергей delphinpro, ну это если папка всего одна, а если структура более глубокая, то там будет Menu/index.js и List/index.js и хрен пойми к чему они относятся.

[Vitaliy]

Александр, может и проще ориентироваться, но глаза в будущем это будет мозолить все больше и больше, как и BEM. То же самое, что в каждом новом предложении вставлять ключевые слова из предыдущего

[Александр]

Виталий Столяров, ну допустим, меня это не смущает, останемся при своём мнение.

[Vitaliy]

Александр, какой смысл создания вопроса?

> Имеет ли такое соглашение для названий компонентов и классов во vue.js право на жизнь?
> останемся при своём мнение.

[Александр]

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

[Vitaliy]

Александр, достаточная аргументация для вас не является аргументацией. О чем в сами еще можно говорить? Или вы еще скажете, что BEM это мегаудобное решение, и его нужно накладывать на другие элементы приложения?

[Александр]

Виталий Столяров, я достаточной аргументации не увидел. Всё что было перечислено очень посредственно соотносится с реалиями моих проектов.
Мы тут спорим о BEM? Суть вопроса вообще в другом была.

[Александр]

Виталий Столяров, а если уж и говорить о BEM, то посмотрите комментарии под ответом Aetae

[Vitaliy]

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

[Александр]

Виталий Столяров, вопрос был в разнице между классическим BEM со структурой компонентов, рекомендуемой во vue style guide и моим вариантом, а не в том стоит ли вообще использовать BEM

Answer 1

[Алексей Николаев]

Извращение какое-то. В этом нет никакой нужды. БЭМ, с которого вы, определенно, сделали кальку, прекрасно применяется к иерархии директорий, что позволяет понять, что куда вложено, по импорту. Тот же БЭМ, кстати, пропагандирует самодостаточность компонентов с минимальными зависимостями между оными. Исключения - когда какой-то элемент действительно предназначен для конкретного домена, там можно и нужно указать принадлежность. HeaderMenu, TableCell и так далее.

Тем более, вложенность. Сегодня она у вас такая, а завтра - этакая. Я давно остановился на domain-driven структуре и не жалею, на мой взгляд, она идеальна. Просто декларативно распределяем компоненты по зонам их ответственности, по доменам. HeaderMenu в Header и так далее.

Comments

[Александр]

А если в приложение 5 разных хедеров? И у каждого своё меню именно для этого хедера.

[zorca]

Александр, Разлличие между этими Хедерами будет в Меню? Зачем лепить 5 хедеров в таком случае? ))) Можно конечно делать 5 хедеров и по пять меню в каждом, итого 25 компонент. БЭМ просто рыдает над вами. )))

[Александр]

zorca, чего? Нет не обязательно только в меню. И компонентов будет не 25, а 10.

[Александр]

zorca, это вполне реальный пример. У меня есть приложение с 5 разными layout'ами, у каждого layout'а свой специфичный хедер со своим специфичным для этого хедера меню. Какой смысл мне делать эти меню некими глобальными переиспользуемыми компонентами если на 99.999% они никогда больше нигде не понадобятся кроме как в этих хедерах? А информативности в данном случае в название на несколько порядков больше. И это ведь не значит, что я не использую не вложенные компоненты. У меня целая куда глобальных компонентов с коротким названием. Но в том то и дело, что иногда компонент располагает к тому, чтобы его переиспользовать, а иногда это очень конкретная часть конкретного интерфейса и намного логичнее вынести её во вложенный компонент другого компонента. Причём никто никогда не мешает использовать его где-то ещё или вынести в общие компоненты при необходимости.

[zorca]

Александр, затем, что принципы DRY и SOLID - это основные принципы программирования. И код нужно писать не для себя и для клиента, а для коллег, которым потом эти писаки изучать.

[Александр]

zorca, и как мне называть эти меню и хедеры? Header1, Header2..., Menu1, Menu2....?

[zorca]

Александр, использовать один компонент на все хедеры и один на все меню, меняя только их конфиг в имплементации. Зачем плодить одинаковые сущности с одной и той же разметкой?

[Александр]

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

[Алексей Николаев]

Александр, лежать будут в Header \ Layouts. У хедера будет один корневой компонент, Header, с пропсом type (ну или можете динамически через component брать нужный хедер, неважно). Меню будут лежать в Menus. Комбинировать меню и лэйауты можете через фабрику, HeaderFactory. MenuFactory, или, как я уже написал, через корневой компонент, где динамически в зависимости от переданных Props будете определять нужное меню \ лэйаут. Чисто, красиво, красота.

[Александр]

Алексей Николаев, супер, а если каждое меню обладает уникальными особенностями и требует связи с Header, причём в особенном порядке? Я ведь пример привёл ещё совсем простой. Есть огромная куча примеров когда есть какой-то уникальный компонент, с уникальными элементами и если его реализовать с помощью одного компонента, то будет лапша на 1000+ строчек. В итоге ты по сути берёшь один большой компонент с тесно связанной логикой и делишь его на 10 мелких, которые по отдельности просто никакого смысла не имеют.
Не хочу ни в коем случае принижать ваш опыт, но есть ощущение, что вы занимаетесь исключительно админ панелями, где абсолютно всё модульное и ничего сложного и связанного нет, а если и есть то на уровне бизнес логики и выносится куда-то за пределы компонентов в принципе. А у меня вот например сейчас проект, где конечно есть куча базовых общих компонентов, различных кнопок инпутов и пр. ерунды, но помимо них есть очень большие уникальные части, которые делятся на тесносвязанные компоненты, которые в свою очередь с вероятностью 99.9999% нигде и никогда не будут переиспользоваться по отдельности и тратить время на то чтобы сделать их независимыми и универсальными нет никакого смысла, это лишь усложняет логику и навигацию по проекту, а что самое главное отнимает огромное количество ценного времени.

[Алексей Николаев]

Александр, ну и что? такие приватные компоненты с тесной связью можно не экспортировать в index.js, а разместить в подпапках "главного" компонента. При этом я все же ратую за то, чтобы у каждого "уникального" хедера и меню был общий предок, и вообще, следует стремиться к унификации таких вещей. В чем конкретно различия и уникальность? Кроме того, суть независимости и самостоятельности не сколько в том, чтобы компонент мог сам по себе работать, а в том, чтобы он не зависел от конкретных реализаций внутри, чтобы его можно было просто скопировать, вставить в другой проект и он бы там заработал.

Вот например, приватные уникальные компоненты можно размещать так.

.
Header
- index.js
- Layouts
- - SuperHeader.js
- - Menus
- - - SuperMenu.js
- - - DuperMenu.js
- - DuperHeader.js
- - Menus
- - - PuperMenu.js

[Александр]

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

[Алексей Николаев]

Александр, так если этот селектор будет в компоненте, который комбинирует в себе конкретный набор компонент, то нет никакой проблемы. Например, на странице логина (Pages/Login) имеется DuperHeader и PuperMenu, и в рамках компонента страницы мы можем управлять всеми дочерними компонентами и их взаимосвязью. Иными словами, все управление выглядит "сверху вниз", от некоего управляющего компонента к спектру дочерних.

А вот если вы в PuperHeader сделаете селектор, который будет ожидать чего-то от DuperMenu (то есть, если управление размазывается по горизонтали), то это уже не очень хорошо (хотя и допустимо, если DuperMenu приватный компонент). Здесь я бы сделал компонент-обертку (DuperTopBar, например), внутри которого будут вместе PuperHeader и DuperMenu, и необходимые стили для работы этих двух компонентов вместе.

Кроме того, не совсем ясна конкретная задача. Возможно, ее можно решить и без создания такого селектора, а просто немного переделав саму архитектуру компонентов. У меня на работе бывали подобные случаи, правда, там проблема была не в селекторе, а в передаче событий между компонентами.

Answer 2

[Aetae]

Просто не храните компоненты кучей в одной папке. Никто вам не запрещает создавать подпапки...

Comments

[Александр]

Это к чему вообще? У нас всё равно глобальное пространство имён компонентов и классов.

[Aetae]

Александр, вот и глобально компоненты тоже регистрировать не надо. Импортируйте компоненты там, где они нужны.

[Александр]

Aetae, это всё круто, но классы мы не импортируем, классы живут в глобальном пространстве имён до тех пор пока мы не начинаем использовать какие-нибудь css модули, с которыми ещё куда других проблем.
Что с классами?

[Aetae]

Никаких проблем с модулями нет, всё встроено в Vue и очень просто в использовании. Если не нравится module - используйте scope.
Классы для отдельного компонента должны жить только в этом компоненте, никакого глобала.

[Александр]

Aetae, как это вообще с BEM сочитается? Модули создают дополнительную специфичность и их стили сложно переопределять.

[Александр]

Не говоря уж то что это не соответствует vue.js style guide и во вкладках таким образом могут появляться компоненты с одинаковым названием, что вызывает путаницу и сложности ориентации в проекте.

[Aetae]

БЭМ используется в рамках компонента. Как и положено по БЭМ - компонент должен быть самодостаточным и независимым.
Что именно из стандартных опций Vue вы считаете не сточитается с Vue style guide?

P.S. Про вкладки - используйте нормальную IDE.)

[Александр]

Aetae, я vscode использую. Там пишется директория, но только её предпоследний уровень как правило и то только если есть файлы с одинаковым названием. Какую мне ещё IDE использовать?

[Александр]

Aetae, если БЭМ использовать только в рамках компонента, то зачем тогда в нём использовать название блока?

[Aetae]

1. Ну так этого достаточно.
2. Чтобы задавать стили корневому элементу?

[Александр]

Aetae, да, но какой смысл его называть как-то. Можно тогда использовать всегда например root.
Вы мне ерунду рассказываете. БЭМ создан именно для того чтобы все классы жили в одном пространстве имён. И там даже есть специальное правило о то что для одного селектора всегда используется один класс для сохранения минимальной специфичности. А вы мне поверх этого предлагаете css модули пихать, которые ломают всю суть БЭМ.

[Aetae]

Александр

Можно тогда использовать всегда например root.

Именно.
Но не нужно.

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

Именно.
БЭМ была создана до Vue и до Web-components, тогда не было возможности инкапсулировать стили в компоненты, были только глобальные стили. Сейчас такая возможность есть, и куда логичнее ею пользоваться, слегка адаптировав систему(причём ни в чём не противореча ей) и сильно облегчая себе жизнь, чем отказываться из-за фанатичного догматизма.
Компонент сам по себе задаёт новое пространство имён.

[Александр]

Aetae, ок, как мне переопределять стили компонента, использующего css модули?

[Aetae]

Вы не должны переопределять стили компонента нигде, кроме самого компонента.
Компонент - закрытый чёрный ящик. Чтобы изменить его поведение - вы передаёте в него соответствующие пропсы.
Вы можете использовать глобальные(или присваиваемые корневому элементу) переменные или классы-модификаторы определяющие "тему", и учитывать эти модификаторы внутри компонента. Но не более того.

[Александр]

Aetae, стоп. Вот тут я явно что-то недопонимаю. Вот есть у меня компонент Input.vue с какой-то стандартной длиной. И мне нужно где-то сделать его не такой длины, а другой конкретной длины. Что я должен сделать?

[Aetae]

Вообще, компоненты должны быть адаптивны по-хорошему.
Но если нужен конкретно-длинный input, то:
если длина завит только от width корневого элемента то собственно назначаете класс с нужным width компоненту при подключении;
если длинна вычисляется более сложным образом - в props передаётся нужное значение и внутри компонента происходят нужные вычисления.

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

[Александр]

Aetae, передавать длину в пропсы - это то ещё извращение. Особенно если длина зависит от медиа запросов.

[Александр]

Aetae, тут разве что подходит передавать css переменные, но всё равно под вопросом остаётся специфичность класса. Вот ты назначил класс какому-то компоненту и передал туда какие-то значения через css переменные например. Каким образом этот класс переопределит класс самого компонента? Они будут иметь одинаковую специфичность и всё будет зависеть от порядка css в конченом css файле и полагаться на это явно не стоит.

[Aetae]

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

Действительно, простого решения специфичности из коробки сейчас нет. Хотя loader'ы и extractor'ы стараются соблюдать логический порядок декларации, но увы напрямую не гарантируют.
Если таки надо что-то гарантировано переписывать на компоненте - остаётся лишь повышать специфичность.

Простой воркэраунд для ситуации, когда вы уверенны что на корневом элементе висит жестко прописанное правило, которое требуется переписать - это использовать #app (или иной id который у вас использован для контейнера vue):

<template>
  <my-comp class="my-class"/>
</template>
<style scoped>
  #app .my-class {
    width: 100%;
  }
</style>

Это не большая плата за всё то удобство, что приносят инкапсулированные стили.

[Александр]

Aetae, максимально адаптивные компоненты - это фантастика, во всяком случае без Container Query, которых мы явно не скоро дождёмся.

Answer 3

[Vitaliy]

Названия компонентов отвечают только за то, чем они являются/какую роль выполняют. Зачем перекладывать на них описание структуры, с которой хорошо справляются директории?

Композиция компонентов как раз и ложится на иерархическую структуру директорий.
Если компонент B используется только в компоненте A, тогда В и должен быть вложен в директорию, в которой находится A. Если компонент C используется и в A, и в B, тогда его можно вынести на соответствующий уровень в shared директорию

Например

/src
  /components
    /Header
      index.vue
    / Main
      /Sidebar
        index.vue
      /shared
      index.vue

Comments

[Александр]

Потому что я сам раньше использовал кучу папок и глубокую вложенную структуру, а потом решил перечитать style guide vue.js (потому как я это делал уже больше 3 лет назад последний раз) и увидел рекомендацию того что следует иметь плоскую структуру и отображать вложенность в название компонентов. Благодаря сортировки по алфавиту компоненты с близким названием группируются в одном месте и навигация по проекту становится значительно легче. Я это попробовал на своём проекте и мне понравилось. А потом я начал развивать эту идею и это вылилось в данный вопрос.

[Александр]

Вот вот. Почти что такую структуру и использовал до недавних пор. Почитайте style guide vue.js

[Vitaliy]

Александр, плоская структура плохо масштабируется. Как можно поддерживать это, когда в проекте сотни компонентов?

UPD: дополнил ответ

[Vitaliy]

Александр, читал. О каком именно пункте идет речь? Что-то я не припоминаю, чтобы там были рекомендации о том, что +100500 компонентов нужно закидывать в одну директорию

[Александр]

Виталий Столяров, в моём проекте больше сотни компонентов и пока что всё довольно неплохо выглядит и работает.

[Александр]

Виталий Столяров, https://ru.vuejs.org/v2/style-guide/index.html#%D0...

[Александр]

Виталий Столяров, обрати внимание на секцию "Подробное объяснение"

[Александр]

Виталий Столяров, я делю компоненты ровно на 3 папки: common, layouts и views

[Vitaliy]

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

[Vitaliy]

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

[Александр]

Виталий Столяров, это рекомендация для всех проектов на vue.js и больших в том числе. Если речь пойдёт о тысячах компонентов, то конечно можно их разделить на несколько папок, но не более. 50-100 компонентов в папке это вполне нормально. Точно не надо делать отдельную папку под каждый уровень вложенности. У меня около 120 компонентов в моём проекте и потенциально я рассчитываю на 250-300 компонентов и такое кол-во компонентов вполне хорошо укладывается в 3 папки. Больше не нужно. Попробуйте сами так сделать. Я объективно стал меньше времени тратить на то чтобы найти и открыть нужный компонент, при чём значительно.
А про то что вы говорите про тесную связанность. Я и не говорил, что везде должна быть тесная связанность. Я всеми руками за переиспользуемые компоненты, но это не должно перерастать в фанатизм. Есть много случаев когда тесносвязанные компоненты абсолютно необходимы. А если в какой-то момент понадобится переиспользовать один из таких компонентов - это отличный повод для того чтобы вынести этот компонент в common или на один или несколько уровне вложенности выше.

[Vitaliy]

Александр, мой коммент выше прочтите. Не вижу смысла в этой демагогии, так как вы явно не имели опыт работы над большим проектом на фронте, а пришли сюда с вопросом "а можно ли так делать?" и конвертируете его в утверждение "только так и нужно делать, а все остальное - фуфло"

[Александр]

Виталий Столяров, имел

[Александр]

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

[Vitaliy]

> этот компонент в common или на один или несколько уровне вложенности выше.

вот и ответ. Вложенности, как оказалось, необходимы. И пока их нет и все "удобненько", значит проект мелкий

[Александр]

Виталий Столяров, что?

[Vitaliy]

> Больше не нужно. Попробуйте сами так сделать.

Делал, в начале, и потом понял, что такой подход слишком убогий в плане DX даже на средних проектах

[Александр]

Виталий Столяров, видимо те кто писал vue style guide - идиоты

[Vitaliy]

> Я объективно стал меньше времени тратить на то чтобы найти и открыть нужный компонент

Если у вас были проблемы с поиском, то это проблема не в наличии иерархической структуры директорий с компонентами, а в плохой иерархической структуре.

[Александр]

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

[Vitaliy]

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

[Александр]

Виталий Столяров, там не написано, что это рассчитано на маленькие проекты

[Vitaliy]

Александр, ахах.. все ясно с вами. Да, конечно, я не имел, ни со Vue.js, ни с Angular, и не знаю какие есть преимущества у Angular над Vue в плане этого вопроса

[Vitaliy]

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

[Александр]

Виталий Столяров, давайте уточним для начала хотя бы что является большим проектом. 500 компонентов - большой проект?

[Vitaliy]

Александр, допустим. И?

[Vitaliy]

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

[Александр]

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

А что самое главное - данное правило вообще никак не зависит от размера проекта. Суть в том что если у нас есть проект из 500 компонентов и допустим 10 основных разделов, то можно во первых разбить их по папкам common, layouts, pages, а во вторых создать папки для всех основных разделов. Итого в каждой папке раздела будет 30-40 компонентов, что является оптимальным кол-вом и наиболее удобно для быстрой ориентации по проекту. Создавать папку для дочерних компонентов каждого компонента - вот что плохо и что объясняется в style guide.

[Vitaliy]

Александр, есть примеры? Может что-то в open source'е или из pet проектов?
Идите поучите Angular и принципы проектирования, потом пересмотрите свое видение данного вопроса. Вы явно не разбираетесь в вопросе и выставляете свое субъективное видение за объективное, не учитывая всех параметров. Иначе этот топик не был бы создан

[Александр]

Виталий Столяров, при чём тут Angular? Зачем примеры? У меня есть наглядная метрика. Я только что перевёл свой pet проект на эту структуру и стало удобнее, что тебе ещё надо? Ради чего эти мириады вложенных папок? Чтобы потом их постоянно открывать закрывать? Чем это удобнее? Мне лично эти лишние действия уже порядком надоели.

[Vitaliy]

Александр, омг.. ТЕБЕ бы не помешало на одном проекте с людьми поработать, они бы тебе отвесили люлей за подобные выходки

[Александр]

Виталий Столяров, какие выходки? О чём ты?

[Vitaliy]

Тема закрыта, дальнейший диалог бессмыслен, так как топикстартер почему-то так лихо перешел на ТЫ, наверное в порывах бешенства

[Александр]

Виталий Столяров, я конечно случайно это сделал, но учитывая то что на западе вообще такого понятия как "ВЫ" нет делаю вывод, что ВЫ порождение совка. Только совки являются такими яростными апологетами общения на ВЫ.

[Vitaliy]

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

[Александр]

Виталий Столяров, лол)

[Александр]

Виталий Столяров, а с "you" тебя так же триггерит на англоязычных форумах?