doka-guide
Добавляет доку `Базовые операторы в JS`
Описание
- Добавит нового автора в
/people/anton-fomichev - Добавит первую версию статьи. Включает в себя:
- описание терминов "оператор" / "операнд"
- типы операторов
- математика
- работа операторов с объектами
- приоритет операторов
- присваивание
- инкремент и декремент
Closes #5077
Чек-лист
- [x] Текст оформлен согласно руководству по стилю
- [x] Ссылки на внутренние материалы начинаются со слеша и заканчиваются слэшем либо якорем на заголовок (
/css/color/,/tools/json/,/tools/gulp/#kak-ponyat) - [x] Ссылки на картинки, видео и демки относительные (
images/example.png,demos/example/,../demos/example/)
Нужна помощь с заполнением полей keywords и related. В ходе работы наткнулся на следующие страницы в Доке:
Мне кажется, что они хорошо подходят на роль кандидатов в related
Привет, спасибо за доку! Вернусь к более внимательному прочетнию в ближайшее время )
Нужна помощь с заполнением полей
keywordsиrelated. В ходе работы наткнулся на следующие страницы в Доке:* [Почти всё в JavaScript — объект](https://doka.guide/js/objects-objects-everywhere/) * [Преобразование типов](https://doka.guide/js/typecasting/)Мне кажется, что они хорошо подходят на роль кандидатов в
related
Я бы предложил Логические операторы
Если добавляем про приведение типов в случае + и -, то не лучше ли будет упомянуть что-то вроде:
При работе с операторами в JavaScript, стоит помнить о механизме приведения типов. Подробнее можно посмотреть в одноименной статье.
@anton-fomichev спасибо за труд и правки.
Я перечислю, что осталось доделать:
- Убрать или заполнить поле
keywordsв заголовке. Оно не обязательное. - Заполнить поле
related
Субъективное:
- "Отойти на пару шагов" (так обычно советуют делать художникам) и подумать над заголовками. Мне кажется, что у некоторых не самые точные названия.
- "Математика" -- "Арифметические операции"
- "Не только математика" -- "??"
- "Присваивание" -- поднять заголовок на уровень 2
Совсем "субъективное":
Сначала оба операнда последовательно приводятся к примитивам. Если хотя бы один из операндов — строка, то второй операнд будет приведён к строке и результатом операции будет конкатенация
-
Как я писал в коменте выше, к примитивам операнды приводятся, но только если эти операнды являются объектами: Да, в спеке указано, что над операндом выполняется операция
ToPrimitive. Но что происходит с примитивным значением ? оно просто возвращается. -
"Если хотя бы один из операндов — строка, то второй..." -- тут больше подходит "то другой"
-
"и результатом операции будет конкатенация" -- тут 'конкатенация' встречается первый раз в тексте, а её описание ниже. Или нужна ссылка или (лучше) заменить на объединение строк.
Чек-лист для новой статьи
Метаданные
- [ ] Код в поле
titleзавёрнут в бэктики - [ ] Есть поле
descriptionс описанием - [ ] Проставлен тег
article - [ ] Поле
keywordsсодержит ключевые слова, которых нет в тексте статьи - [ ] В поле
authorsуказан автор. Файл автора есть в папке people - [ ] В поле
relatedесть ссылки на материалы Доки, интересные в контексте данного (не более трёх)
Статья
- [ ] Структура совпадает с шаблоном
- [ ] Демки написаны по рекомендациям
- [ ] У картинок есть описание в
alt, у фреймов демок название вtitle - [ ] Статья добавлена в содержание раздела
- [ ] Для статьи указаны материалы Доки, интересные для дальнейшего чтения
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@Inventoris Мне казалось, что идея в том, чтобы делить статьи на несколько уровней (базовые/углубленные/узкоспециализированные), чтобы направлять аудиторию сразу в нужное место и лучше продвигаться в поиске, например.
Но если делать какую-то общую статью, то как, например, быть с отдельными статьями:
И если делать, то в каких рамках хотелось бы остаться внутри этой статьи?
[!NOTE] Тут забавный факт, что изначально я писал именно статью, но её предложили переделать в доку. Из-за этого материала получилось довольно много, хочется просто понять к какому результату хотим прийти в конечном итоге :)
@Inventoris Мне казалось, что идея в том, чтобы делить статьи на несколько уровней (базовые/углубленные/узкоспециализированные), чтобы направлять аудиторию сразу в нужное место и лучше продвигаться в поиске, например.
Но если делать какую-то общую статью, то как, например, быть с отдельными статьями:
И если делать, то в каких рамках хотелось бы остаться внутри этой статьи?
Note
Тут забавный факт, что изначально я писал именно статью, но её предложили переделать в доку. Из-за этого материала получилось довольно много, хочется просто понять к какому результату хотим прийти в конечном итоге :)
Да, факт забавный =) Но думаю ты был прав изначально. Всё таки хорошая структура документации, это когда есть большая обзорная статья со всем, но кратко, для ознакомления и быстрого поиска инфы, а также отдельные статьи уже более углубленные.
Например, есть дока (лучше бы ей быть статьей конечно) про функции, там кратко про стрелочные, чтобы въехать. А для погружения отдельная дока про стрелочные функции.
Тут стоит применить такой же подход. Делаем большую статью, но с краткой инфой по операторам, советами итд, ёмко. Не разрастаемся, оставляя пространство для будущих материалов с подробностями по каждому оператору отдельно.
Решил вернуться сюда после перерыва =)
С чего начал:
- Перевел материал из
dokaвarticle - Убрал лишнее "разработчики", как предложили выше
Не знаю, как лучше подступиться и в какую сторону двигаться. Взглянул спустя время, подумал над материалом и лично мне показалось, что дока выглядит лаконично.
@Inventoris, что думаешь?
@HellSquirrel Привет! Что думаешь по доке? Решил пингануть на всякий, потому что давно пр создавали