Interface, насчет reduce согласен, лишние операции. Но удобство.
Функцию reduce оправдывает ее читаемость и лаконичность, но там где нужна производительность ее использовать не следует. Но это точно не про текущую задачу, тут ее использовать удобно.
Доводы вы поняли не правильно и то и другое просадка в производительности. Внизу будет бенчмарк.
А вот этот алгоритм эффективней вашего решения, только из-за одного подхода.
const result = {
status: 'approved',
message: [],
};
for (var i = 0; i < arr.length; i++) {
if (arr[i].status === 'approved') {
result.message.push(arr[i].message);
}
}
result.message.join('\n');
Вот бенчмарк на средний показатель за 500 проходов по 10000 элементам.
В бенчмарке в комментарии ниже решение с reduce, да еще и с дополнительным условием, и оно дает результаты не хуже вашего решения.
Так что думайте сами, что менее оправданно reduce или ваши два прохода.
pterodaktil, в том самом месте где, по-видимому, заканчиваются ваши знания основ js.
Вот пример который призван объяснить вам в каком месте это происходит и почему ваше предположение "а на каждой следующей итерации идет заполнение/дополнение этого объекта" не имеет ничего общего с тем, что происходит в действительности.
Interface, вижу вы не видели исходный код функции reduce. Создается объект(в нашем случае) перед проходом, наполняется данными и возвращается.
В случае же этого алгоритма во время второго прохода, на каждом элементе создается и возвращается новый объект. С учетом дополнительного прохода, работы больше в разы(от двух и более). Чем больше элементов, тем сильнее разница в скорости выполнения задачи. В контексте данной задачи, не существенно. А вот, скажем, плагин для IDE так лучше не писать.
hollanditkzn, не подходит для задач веба. В вебе лучше всего показали себя компонентная архитектура + Flux. Если интересно почитайте про историю развития веб фреймворков и архитектуры вебприложений.
почитайте любую статью-руководство по npm. Там все просто. Устанавливаете нужные модули, импортируете и используете в коде. Потом если это клиентский(который будет выполняться в браузере), его надо собрать. Тут могут помочь gulp + gulp-babel или webpack. Я советую попробовать оба инструмента, так как они совершенно разные.
Polyakh, ох как-то все запутанно.
У вас не работает собранный проект в production режиме? Но работает собираемый на лету в development?
Первая ошибка в vendor бандле.
Попробуйте в конфиге в LoaderOptionsPluginminimize: false, debug: true поставить. Может так понятней будет.
Никита Полевой, с этого и надо было начинать, что не имеете представления о промышленных стандартах.
Но изучить этот вопрос и повысить качество своего кода никогда не поздно.
Правило, еще раз оговорюсь, не мое. В вашем случае "гениально", однобоко посмотрев на проблему, смеяться над правилом, которое включило в стандарты сообщество JS программистов, в лице одних из лучших его представителей, досконально изучив проблему и возможные последствия. Если интересно можете поискать и почитать обсуждения.
Зайдите на сайт https://eslint.org найдите плашку Who's using ESLint и нажмите. Узнаете, что это стандарт чуть ли не для всего передового фронтенда, а с ними и для многих других компаний.
Можете посмотреть на Prettierhttps://prettier.io/en/users/, он также набирает популярность.
Сам рекомендую к использованию оба инструмента.
Вот ESLint файл из первого попавшегося репозитория Mozillahttps://github.com/mozilla/thimble.mozilla.org/blo...
Они тут так же используют Prettier. Не удивлюсь если узнаю, что он используется во всех их более менее новых JS проектах как стандарт.
Вот правило https://eslint.org/docs/rules/no-prototype-builtins . ESLint сейчас стандарт в промышленной JS разработке. Prettier скоро им станет.
Попробуйте устроиться в маломальски серьезную компанию использующую ESLint и precommit проверки в проектах. Скорей всего, если это правило нарочно не отключили, что вряд ли, то вы даже коммит сделать не сможете.
Никита Полевой, это не моя паранойя, а промышленные стандарты. Почитайте в документации и обсуждениях на github ESlint почему к этому пришли.
Вот сохранять в константу нет никакого смысла.
Мне не надо смотреть в документацию Mozila, так как я работаю в больших промышленных проектах с высокими требованиями к качеству и безотказности кода.
А это всего лишь один из стандартов гарантирующих безопасность и безотказность. Спорить с этим глупо.
А обсуждения почитайте на досуге, там много примеров.
"ибо любые извращения, включая вызов hasOwnProperty из прототипа, не пройдут еще на стадии ревью."
Вам prettier, используемый сейчас в куче известных и серьезных компаний и проектов, с настройками по-умолчанию, код с использованием hasOwnProperty, но без такого "извращения" даже закоммитить не даст, какое там ревью.
Morfeey, Проверка hasOwnProperty исключит наследуемые перечисляемые свойства. А вызов ее из протоипа объекта исключит ее возможное переопределение на экземпляре, в случае которого приложение может поймать исключение и завершиться ошибкой.
Все это конечно маловероятно, но в промышленных проектах с кучей разработчиков лучше застраховаться от всего. По крайней мере, знать полезно.
1. Переменные в js в верхнем регистре называть не принято.
2. for in не гарантирует соблюдение очередности при итерации.
3. Использовать правильно и безопасно for in надо так:
for (var key in yourObj) {
if(Object.prototype.hasOwnProperty.call(yourObj, key) ) {
var obj = yourObject[key];
if (obj.status === "error") {
console.log(obj.text);
}
}
}
Функцию reduce оправдывает ее читаемость и лаконичность, но там где нужна производительность ее использовать не следует. Но это точно не про текущую задачу, тут ее использовать удобно.
Доводы вы поняли не правильно и то и другое просадка в производительности. Внизу будет бенчмарк.
А вот этот алгоритм эффективней вашего решения, только из-за одного подхода.
Вот бенчмарк на средний показатель за 500 проходов по 10000 элементам.
https://jsfiddle.net/rockon404/mqpha6qg/
В бенчмарке в комментарии ниже решение с reduce, да еще и с дополнительным условием, и оно дает результаты не хуже вашего решения.
Так что думайте сами, что менее оправданно reduce или ваши два прохода.