Хороший материал!
Вам не кажется, что понятие «дизайн система», должна исключать ситуации, когда дизайнер, может создать уникальный специфичный элемент, который никогда и нигде не будет переиспользован и будет жить сам по себе вне дизайн системы, брошенный и неучтенный?
Если уникальных специфичных элементов будет много, то где будет та системность, ради которой все создавали и создают «Дизайн Систему»?
Не надо пытаться загнать в компоненты абсолютно всё. В любом проекте есть специфические вещи, которые используются однократно или имеют риск погибнуть в боях с правками заказчиков — не завязывайте на них родительские библиотечные компоненты, чтобы не зависеть от ненадёжных и слишком нетипичных узлов.
Считаю что все элементы, которые рождаются на этапе дизайна, а затем идут в работу, обязательно должны быть в конечном счете(после всех правок, игрищ и согласований) оформлены как компоненты, даже если его переиспользование в будущем под большим сомнением.
Дизайнер, может каждый день рожать уникальные компоненты, не продумывая их жизненный цикл, и как наркоман говорить, что это в последний раз, продолжая создавать все больше и больше таких элементов. Те правильные вещи, о которых вы пишите в статье, на мой взгляд, немного отрезвляют дизайнера. Его энтузиазм, запилить что-то фееричное — гаснет, так как это надо все правильно раскидать по слоям, присвоить имена элементам, продумать как оно дальше будет жить, вести и т.д.
В идеале, хочу держать в свое сторе как можно более полное состояние приложения, чтобы потом при ошибке у пользователя получить набор экшнов, который к этому привел, и с точностью воспроизвести ошибку.
Часто вижу такие комментарии и понять не могу, как вы код пишете, что не понимаете, что происходит в приложении при ошибке. Вам в консоль валится полный трейс откуда ноги растут, а вы без всяких чудесных расширений для хрома, не понимаете что происходит.
Это ж сколько времени должно быть свободного, чтобы читать все ответы на тостере каждого кандидата, анализировать его адекватность и его ответов?
Как это работает вообще, приведите пример из жизни?
да несколько разных и равноправных. Если над проектом работает один разработчик, он скорее всего так и сделает, но если в проект пришел еще один разработчик, который не в курсе что где-то там есть еще один такой блок с таким же именем. Он не выковыривая из носа, следуя бизнес логике называет этот блок точно так же. И получаем проблему.
Ну вот есть у меня блок .catalog-products-list еще в одном месте, и это логичное имя для этого блока, сколько слов бы ты не использовал, пересечение все равно очень сильно вероятно.
Допустим, есть у нас большой проект нарисованный на БэМе, в проекте на одной из страниц есть блок «Клиенты» с классом .clients, приходит новый сотрудник и ему ставят задачу сверстать новый макет, в котором есть блок «Клиенты» но внешне он совершенно другой. Он создает свой класс .clients и пишет свои стили, в результате чего верстка начинает ехать. Как Бем решает эту проблему?
function hookupevents() {
for (var i = 0; i < 3; i++) {
document.getElementById("button" + i)
.addEventListener("click", function() {
alert(i);
});
}
}
About Type Erasure, what's the output of this Java snippet, and why?
ArrayList<Integer> li = new ArrayList<Integer>();
ArrayList<Float> lf = new ArrayList<Float>();
if (li.getClass() == lf.getClass()) // evaluates to true
System.out.println("Equal");
Вам не кажется, что понятие «дизайн система», должна исключать ситуации, когда дизайнер, может создать уникальный специфичный элемент, который никогда и нигде не будет переиспользован и будет жить сам по себе вне дизайн системы, брошенный и неучтенный?
Если уникальных специфичных элементов будет много, то где будет та системность, ради которой все создавали и создают «Дизайн Систему»?
Считаю что все элементы, которые рождаются на этапе дизайна, а затем идут в работу, обязательно должны быть в конечном счете(после всех правок, игрищ и согласований) оформлены как компоненты, даже если его переиспользование в будущем под большим сомнением.
Дизайнер, может каждый день рожать уникальные компоненты, не продумывая их жизненный цикл, и как наркоман говорить, что это в последний раз, продолжая создавать все больше и больше таких элементов. Те правильные вещи, о которых вы пишите в статье, на мой взгляд, немного отрезвляют дизайнера. Его энтузиазм, запилить что-то фееричное — гаснет, так как это надо все правильно раскидать по слоям, присвоить имена элементам, продумать как оно дальше будет жить, вести и т.д.
Часто вижу такие комментарии и понять не могу, как вы код пишете, что не понимаете, что происходит в приложении при ошибке. Вам в консоль валится полный трейс откуда ноги растут, а вы без всяких чудесных расширений для хрома, не понимаете что происходит.
Как это работает вообще, приведите пример из жизни?
Или я тебя не правильно понял :)
CSS Modules к бему не относится, вопрос чисто про бем был.
Есть еще вот такая штука
Это специально так? Или это ошибка копипаста?