легаси надо переписывать в параллели с поддержкой

легаси надо переписывать в параллели с поддержкой

Расскажи это банкам с коболом))

Java is new COBOL

Я буду мстить бекендерам, говнокодившим в мой фронтенд

Убивший дракона сам становится драконом))

кобол норм, на нем самолеты американские летают

Это те, которые переворачивались над Мёртвым морем?)

и те, и те, что летают до сих пор

и в штатах за кобол пиздец сколько платят, кстати

джаве не снилось

Ожидаемо) Страна первая внедряла высокие технологии, богатого легаси завались

Нью-Йоркское метро на релюшках столетней давности вообще)

как и наши атомные подлодки

как и наши атомные подлодки

вот почему они возле нью-ерка плавают

НИКТО

А сам то

const items = new Array(count).fill(null) .map(index => blaBlaBla(index)); Вместо const items = []; for (const index = 0; index < count; index++) { items.push(blaBlaBla(index)); } Мм?

@bigslycat Норм, только вот зачем тут return? .map(index => return blaBlaBla(index)); без него не работает что ли?

Ой. Забыл убрать, когда приводил к сокращённому синтаксису.

Ну, в данном примере можно сократить и до const items = new Array(count).fill(null) .map(blaBlaBla);

Весь вопрос в адекватности конструкции new Array(count).fill(null).map(...);

Один вопрос — зачем?))

Чем тебе просто map не угодил?)

Тем, что new Array(count) создаёт массив заданного размера, но значения его элементам не присвоены. Array.prototype.map() и Array.prototype.forEach() просто пропускают такие элементы. Поэтому, прежде чем обойти такой массив, я заполняю его значениями null или undefined.

new Array(3) // [ , , ] new Array(3).fill(undefined) // [ undefined, undefined, undefined ]

👆Это вывод ноды.

А хотите пораскинуть мозгами?

Тем, что new Array(count) создаёт массив заданного размера, но значения его элементам не присвоены. Array.prototype.map() и Array.prototype.forEach() просто пропускают такие элементы. Поэтому, прежде чем обойти такой массив, я заполняю его значениями null или undefined.

Зачем обходить пустой массив 😵 Если ты используешь map, то у тебя должен быть исходный массив, его и обходи) Если проблема просто именно в том, что не обходятся пустые элементы, то не знаю, мне проще ramda включить, в котором forEach и map пофикшены из коробки и не забивать голову такими вещами)

Зачем обходить пустой массив 😵 Если ты используешь map, то у тебя должен быть исходный массив, его и обходи) Если проблема просто именно в том, что не обходятся пустые элементы, то не знаю, мне проще ramda включить, в котором forEach и map пофикшены из коробки и не забивать голову такими вещами)

Вместо for

Зачем обходить пустой массив 😵 Если ты используешь map, то у тебя должен быть исходный массив, его и обходи) Если проблема просто именно в том, что не обходятся пустые элементы, то не знаю, мне проще ramda включить, в котором forEach и map пофикшены из коробки и не забивать голову такими вещами)

Изначально речь идёт о том, чтобы сгенерировать массив.

Вместо for

Я не про это)

Я представил 2 способа.

Первый — создание массива с заданной длиной и заполнение его значениями.

Второй — создание массива с нулевой длиной и генерация значений во внешнем цикле.

Второй способ — традиционный.

Первый — не очень.

Но красивый и компактный.

Я просто не понимаю, зачем нужен просто массив, в отрыве от данных let usedItems = [1,2,3] let resultedArray = usedItems.map(e=>e*e) Что не устраивает здесь то?)

Блин.

Содержание массива заранее неизвестно.

А как это мешает сделать map?)

Оно генерируется или получается. Заранее известна только его длина.

О боже.

Забей.

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

Задача очень тривиальная.

Да)

Допустим, тебе нужно сгенерировать массив объектов. У объектов должны быть свойства, которые рассчитываются на основе индекса родителя в массиве. Писать const items = [1, 2, 3, ...].map( ... ); не вариант, т.к. объектов может быть 100... 1000... Не-не, это уж слишком. Соответственно, тебе нужно сгенерировать последовательность.

Поэтому let usedItems = [1,2,3] здесь не катит.

Редъюз тоже.

Ну, хотя, написать специальный редъюсер — тоже красиво. Но бессмысленно.

function _map(fn, functor) { var idx = 0; var len = functor.length; var result = Array(len); while (idx < len) { result[idx] = fn(functor[idx]); idx += 1; } return result; } Это map из ramda, фактически твой случай, только уже написанный, ещё и максимально упрощённо. Уже с тестами, документацией и прочим. Поэтому я не парюсь по такой фигне а просто пишу const mapper = R.map(anyFunc) let newArray = mapper(anyArray) Незачем изобретать велосипед))

Можешь использовать его, тащемта

Эммм... Очень сомневаюсь, что мне нужно подключать либу ради решения такой задачи. Я понимаю, если она сократит мой код на стопиццот строк, но она в данном случае сокращает всего лишь длину одной строки моего кода.

Такие вещи не длину сокращают, а время)

Ну и велосипеда здесь нет. И времени я не затрачиваю больше.

Ты уже пол часа размышляешь))

Я же не пишу никаких новых конструкций.

Ты думаешь, что подключаемые библиотеки существуют, чтобы избавить от необходимости думать? =) Нет. Это не так.

А для чего же 😵

И тем не менее, почему тебя не устраивает _map = func=>e=>e.map(func) "Это уж слишком" — не ответ, родной map хотя бы движком соптимизируется

const mapper = _map((e,i)=>e+i) let newArray = mapper(anyArray)

И тем не менее, почему тебя не устраивает _map = func=>e=>e.map(func) "Это уж слишком" — не ответ, родной map хотя бы движком соптимизируется

Где здесь вообще задаётся количество элементов?

Где то внутри V8, я хз где, пусть оно сам делается

Ты в корне не понял задачу.

Задача — не обойти массив, а сгенерировать.

У объектов должны быть свойства, которые рассчитываются на основе индекса родителя в массиве У тебя есть индекс родителя и функция-генератор (e,i)=>{}, это всё, что нужно для генерации нового массив

Задача — не обойти массив, а сгенерировать.

Это одно и то же. map возвращает новый массив, как бы, не?

const items = new Array(count).fill(null) .map(index => blaBlaBla(index));

У объектов должны быть свойства, которые рассчитываются на основе индекса родителя в массиве У тебя есть индекс родителя и функция-генератор (e,i)=>{}, это всё, что нужно для генерации нового массив

Ага, и где взять индекс родителя до создания самого родителя?

Ага, и где взять индекс родителя до создания самого родителя?

Ну это не map тогда, выглядит странно. Да и создавать новый массив, потом проход по индексам, потом результат в новый массив — это хуже, чем просто while/for второго варианта

Ну это не map тогда, выглядит странно. Да и создавать новый массив, потом проход по индексам, потом результат в новый массив — это хуже, чем просто while/for второго варианта

Ну, с точки зрения производительности, безусловно.

А с точки зрения логики - у меня вот fatal error случился от маппинга ничего в массив %) Map это преобразование, к созданию его прикручивать противоестественно

о.0

Какой код ты выполнил? =)

Ну мне оказалось достаточно просто прокрутить в голове))

Ну, прокрутить в голове что? =)

Процент ложных срабатываний ниже

Какие юзер-агенты брал? Откуда база? Я слабо верю, что в одно лицо можно сделать что-либо лучше, чем пхпшный mobile detect.

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

Если часто нужно, то должен быть налажен процесс, чтобы самому это делать кмк.

лан, позанудствовал, хватит