Set of best practices that you can use as checklist for your project.

front-end-best-practices's People

Contributors

Stargazers

Watchers

Forkers

krashaen alextsk encrypticus igorsushko1 apploidx viktoriya-ch natalylittlefox v02m makysheva nelliza dimktsoy gruwa alanreidt isavlex ivanushkapr anshnv pullso scket4 feinminen doksna imin314 dron79-79 k8ray ausgard ilanevazno kosmich zhen9bes rostoriginal svetlanakudryavtseva dywork hacktivision madgoby darkvoice1996 victor7stepanov danilovvik metalhead89 kornavol liberpolly anyageexy sultseven sergey-fomin alohadancex kickgodx alecodew brian-iproject dv-loginov andrewboyar72 zhukanna maedrock tars-tarkas frontend200tb yabuyanishe nilienta foana bobrikovaleksey dmitrynikolaev-metalamp polarush nikolajgromkov xelatnu rompt-prompt andreykokorev tusya-sereda hamdanhussein avatarsik6699 mvodev dmitryi698 whereisexit iavalli michael3468 eugenewhistler stevegerr lipan4836 verminas kozandre krepyshev tabrisel kandrukkv speksya

front-end-best-practices's Issues

перевести содержание 7 пункта в разделе семантика

заголовок на русском, а содержание на английском) это very странно

[JS] Добавить использование Numeric Separators

Имена css-классов.

CSS/generalRequirements.md

12.Имена:

использовать lower-case-hyphenated (то есть не mySuperAwesomeElement и не my_super_awesome_element);
имена должны отображать смысл, а не описание стилей ("loading" а не "big-yellow-spinny-thing");

Здесь еще можно добавить, что нельзя именовать классы с нумерацией: .icon-1, icon-2, icon-3... Мне кажется, такое часто встречается.

Доработать концепцию именования bem-модификаторов

Концепция не удовлетворяет области применения для модификаторов с «ключами»

#27

Регламентирование использования z-index

Почему бы не добавить стандарт, добавляющий регламентацию css свойства z-index?

Схема, которую нашел:

0-9 - в пределах компонента;
10-19 - для всплывающих менюшек, подсказок и т.д.;
20-25 - для выезжающих меню, модалок и т.д.;
для сторонних плагинов добавлять обертки с меньшим z-index.

Что думаете?

Нейминг приватных полей класса

Привет всем!
В goodPractice.md имеется пункт про следованию стайлгайду от AirBnB. И хотя там же присутствует оговорка

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

тем не менее, хотелось бы акцентировать внимание на спорных рекомендациях касательно нейминга (квази)приватных методов класса:

В js нет публичных и частных свойств, поэтому частные методы просто делать с префиксами "_" (нижнее подчеркивание)

Как вы считаете, возможно, стоит этот пункт переписать с учетом правил, изложенных в стайлгайде AirBnB, и использовать для имитации приватных полей WeakMap или, как вариант, символы?

Изменить формулировку пункта 4.4 в разделе CSS

https://github.com/fullstack-development/front-end-best-practices/blob/master/CSS/README.md#4.4

Предлагаю:

Удалить явно лишнее быть.
Удалить тавтологию с должен.
Изменить окончание в слове самодостаточен на ным (быть каким?).

Как итог: "Каждый компонент должен иметь только явные зависимости, быть самодостаточным."

Использование кавычек в CSS.

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

Сделать шаблон для Issues и PR

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

Создано после обсуждение в #36

Create topic for React best practices

Для стайл гайда Airbnb есть нормальный русский перевод

Здравствуйте!
Надеюсь, обратился в правильное место. Я стажер.
В лучших практиках указано, что нужно придерживаться стайлгайда Airbnb,
и читать его только на оригинальном английском, так как в нем описаны es6 фичи.
Я наткнулся на перевод Леонида Лебедева, где так же хорошо описаны эти фичи.
https://github.com/leonidlebedev/javascript-airbnb#ecmascript-6-es-2015-styles
Прошу обратить на это внимание.

Добавить тестирование реакта

Сделать как с AirBnb, только вот на эту доку: https://github.com/eventbrite/javascript/blob/master/react/testing.md

Внимание! нарушается инкапсулияци

front-end-best-practices/CSS/bem.md

Нарушается инкапсулияци

Wrong link in text

Frontend Best Practices - HTML
Paragraph 3: Константин Константинопольский
Delete last symbol in link: https://tema.livejournal.com/1322108.html/

Сделать пункты в топиках якорями

Мне кажется будет удобнее прикладывать ссылку в ишью стражеров на конкретный пункт.

уточнить цель

есть пункт "Прогонять картинки через kraken.io или использовать свои CLI-утилиты для этого;"
https://github.com/fullstack-development/front-end-best-practices/blob/master/HTML/includeFiles.md
наверно нужно пояснить для чего их нужно прогонять

Использование W3C Markup Validation Service

Предлагаю вынести некоторые пункты HTML стандартов в один: "Прогонять страницы через валидатор".

Решаемые проблемы:

уплотнится структура стандартов, что упростит запоминание;
процесс поиска многих ошибок будет частично автоматизирован;
валидатор также сообщает и о ошибках, не отображенных в текущих стандартах: <input> внутри <button> или <a>.

Пункты стандартов, которые проверяет валидатор:

P.S.: расширение позволяет прогонять страницы локально.

Орфография

Не знаю можно ли создавать issue по этому поводу, но когда изучаю best practices иногда встречаются такие ошибки

Если нужно, буду сюда заносить неточности

Обсуждение требования по установке одновременно ширины и высоты для тэга img.

Проблемы

Изображения установленные через background не индексируются.
Теряем семантику.
CSS cвойство object-fit которое может дать изображению img поведение как при background-size: cover нуждается в установке ширины и высоты, что противоречит требованию.

Варианты решения

Требование мы можем:
1.1. Расширить, добавив информацию о том как быть в тех или иных ситуациях.
1.2. Сократить, на пример - Избегайте действий нарушающие пропорции изображений.
1.3. Убрать требование вовсе.
Вне зависимости от того что было выбрано в пункте 1, предлагаю:
- Добавить в карту развития jun1/css: Что делает свойство object-fit?
- Перенести с карты развития jun3/css вопрос Когда стоит использовать тег img, а когда background-image? в jun1/html или css, так как без знания когда и как подключать изображения знания про object-fit и прочие рекомендации будут менее эффективны. Учитывая то, как часто перед нами стоит выбор img или background-image это надо знать уже на позиции jun1.

Результаты Can I use. Поддержка большинством передовых браузеров началась с 2013-14 годов.

Соблюдать стандарты самим :)

В первом пункте пишем про одно, а затем ниже сами его и нарушаем, надо исправить
https://github.com/fullstack-development/front-end-best-practices/blob/master/JS/jQuery.md

В разделе "инициация" глобальные библиотеки имеется ввиду библиотеки, которые собираются в бандле?

Здравствуйте!
В моем личном представлении глобальные библиотеки - библиотеки, которые установлены в системе, а не в проекте.
Речь, наверное идет о библиотеках, которые попадают в конечную сборку, то есть не только находятся в проекте при разработке, но и на продакшене.
В файле package.json они описаны в Dependencies.
Надеюсь я правильно понял, и лучше изменить "глобальные" на "которые попадут в продакшн"

Недействительная ссылка на перевод Flexbugs

В конце раздела о CSS:

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

Ссылка на русскоязычный материал не работает (это просто свободный домен на данный момент). Я погуглил свежие материалы на эту тему, но ничего раньше 2015 года не нашел – ссылка на материал с css-live.

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

Структура папок.

CSS/generalRequirements.md

Все правила должны быть разбиты на разные файлы по страницам и блокам, каждый файл не должен быть длинее чем 1000 строк;

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

Определение элемента footer

Мне кажется не совсем точно указано п.8 определение для элемента. Footer может использоваться не только как подвал страницы, а также как нижний колонтитул section, article и aside. Думаю стоит дополнить, т.к. это достаточно важно для придания семантики документу

Форматирование размещения импортов

Думаю, следует дополнить стандарт примерами для:

использования путей с алиасами;
что делать в случае если импорт используется только для правки порядка импорта ресурсов сборщиком (при использовании bem компонент должен быть импортирован раньше модификаторов, которые лежат глубже).

Ссылка на стандарт

Расписать как правильно писать коммиты и структурировать вносимые изменения

Ввести ограничение на вложенность селекторов.

Я читала, что хорошей практикой считается вложенность селекторов не больше двух уровней, т.к. большая вложенность усложняет читабельность и поддержку кода.

Неправильно. Вложенность больше двух уровней

.block {
  display: block;

  .description {
    font-size: 14px;

    .title {
      font-size: 16px;
    }
  }
}

Правильно. Псевдоэлменты, псевдоселекторы, родственные и соседние селекторы не влияют на вложенность.

.checkbox__input:checked ~ .checkbox__label::before {   
  border-color: #3D4975;
}

Регламентировать 'кавычки' в PUG файлах

На данный момент имеется несколько разногласных issues для нескольких людей, где в одном issue указано, что все кавычки в pug файлах необходимо заменить на двойные, а в issue другого человека, другой ревьювер написал о необходимости использовать двойные кавычки в pug HTML атрибутах, а в местах где используется js код - одинарные. Нужно регламентировать данный момент в best practices, во избежание спорных моментов, и желательно использовать второй вариант, где:

- const anyWord = "word";               // Плохо, т.к это уже js код, хоть и внутри PUG файла, 
                                        // у него должны быть одинарные кавычки
button(type="button")= anyWord          // type="button" - HTML атрибут, 
                                        // он должен быть в двойных кавычках

- const anyWord = 'word';               // Хорошо
button(type="button")= anyWord

Добавить пункт про баги в либах

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

Например, кейс который ща у Лехи Жмайлика случился с тем что нативные focus/blur не всплывают, а у реакта какого-то фига всплывают (и эта штука висит с 2016 года) facebook/react#6410 (comment)

fullstack-development / front-end-best-practices Goto Github PK