Добрый день! Есть ли разница в объединении спредом массивов и объектов?
Например:

const arr1 = ['E_01','Jack',32]
const arr2 = ['Software Dev','Paris']
const mergedArr = [...arr1,...arr2]
// здесь вроде O(n) в нашем случае 5 итераций
const emp = {
 'id': 'E_01',
 'name': 'Jack',
 'age': 32,
 'addr': 'India'
};

const job = {
 'title': 'Software Dev',
  'location': 'Paris'
};
const mergedObjects = {...emp, ...job};
// ???

Привет. Насколько понимаю, не должно быть разницы.
Чтобы объединить массивы нужно пройтись по ним. Для этого они будут итерироваться от нуля до length - 1 и копировать элементы в новый массив.
А чтобы объединить объекты нужно получить список свойств, перебрать их и скопировать свойства в новый объект. Даже если учитывать, что появится лишний цикл на получение списка свойств, сложность все равно останется линейной

Не знаю понятно ли я сформулирую, надеюсь что да. Короче, есть разные контейнеры с радио-кнопками, надо  чтоб в каждом отдельном можно было добавить активный класс выбранному элементу, убирая его у сиблингов. но чтоб это не влияло на другие контейнеры., и чтоб в каждом можно(нужно) было выбрать один из вариантов, не убирая активный класс у выбранного в другом контейнере. у контейнеров есть уникальные классы, но можно ли как-то грамотно динамически прописать это правило "мультиселекта"? то есть "мультирадио" в моем случае. или цепляться к родительскому классу каждого контейнера? в пределах одного контейнера все изи, код такой, как грамотно распространить его с другими? parent find siblings? jQuery('.attr-container label').click(function() {
 jQuery('.attr-container label').removeClass('attr-selected');
 jQuery(this).addClass('attr-selected');
});

мне надо лейблу той, что выбрана, добавлять класс, и так в каждом контейнере

чтоб не сваливать длинную портянку своей структуры, тут она уже слита https://stackoverflow.com/questions/66221711/how-to-choose-this-element-in-each-containerjquery

не могу понять, почему редьюс останавливается после 3го прохода, функция должна мержить 2 массива и сортировать их (сорт отключен). песочница: https://codesandbox.io/s/falling-paper-29zr0?file=/src/index.js

splice удаляет элементы из исходного массива. А reduce проверяет существует ли свойство перед тем как вызывать callback.
Т.е. он проходит по массиву 3 раза и каждый раз удаляет из него один элемент. Остается массив [3,2,3], в котором редьюсер ищет индексы 3, 4 и 5 которых нету, и ничего не делает

Считаете ли вы что неполноценные фронтенд фреймворки (типа библиотека React) занимаются по сути переносом сложности разработки в другую плоскость? В инженерии есть принцип необходимой вариативности: "только сложность может держать под контролем другую сложность." Во фронтенд разработке основная сложность это приведение разрозненных элементов (компонентов) к единому валидному состоянию объекта (в данном случае страницы) за ограниченный промежуток времени. Пользователь не должен видеть переход состояния ( промежуточные состояния) страницы. React например решает эту проблему путем переноса комбиноторной сложности проектирования перехода состояния системы, в сложность проектирования зависимостей состояния елементов от данных и от жизненных циклов состояния. По сути сложность не убирается, она только конвертируется в другую как по мне.

в целом, ничто не мешает тебе писать на ванили. Даже вакансии можно найти при желании. Просто со временем ты придешь к тому, что захочешь написать свою библиотеку, потому что тебя достало описывать функционал для каких-то базовых вещей, который есть в каждом проекте (типа динамического создания элементов). И тут уже нюансы: ты уверен, что напишешь лучше? Ты уверен, что это проще?

ммм. ну да согласен. просто трубят все что реакт упрощает разработку. по мне так это не очевидно.

а ты никого не слушай, и напиши хотя бы что-то простое сначала на ванили, а потом на реакте. И все станет немного очевидней. А потом ты станешь крутым разрабом и захочешь написать что-то большое на ванили, тогда все станет совсем очевидно. Главный вопрос вот в чем: с чего ты взял, что эти сложности Реакта куда-то денутся при разработке на ванили? Ну, называется будет иначе, но отслеживание жизненных циклов разных частей приложения никуда не денется, хоть на чем пиши, просто разное количество уровней абстракции

я немного о другом. реакт упрощает разработку сложных приложений часично из-за того что разработчики пишущие на реакте уже превыкли к новой сложности. но это не упрощение разработки в целом. хотя частично да фреймворки решают

сколько у тебя опыта разработки?

пару лет