Object.assign присваивает свойства в целевой объект, а не копирует. Поэтому срабатывают и сеттеры и геттеры.

Кстати есть встроенный аналог, который копирует свойства рекурсивно и заменяет только значения если в целевом объекте уже есть ещё один объект, а если нету, то дополняет?

Типа array_merge_recursive , аналог в php

Кстати есть встроенный аналог, который копирует свойства рекурсивно и заменяет только значения если в целевом объекте уже есть ещё один объект, а если нету, то дополняет?

в JS? Как называется?

$.extend (с параметрами же)

$.extend(true, obejct1, object2, object3, ... )

Кстати есть встроенный аналог, который копирует свойства рекурсивно и заменяет только значения если в целевом объекте уже есть ещё один объект, а если нету, то дополняет?

ой, я не заметил, что это был вопрос) болею, в глазах все плывет

Кстати есть встроенный аналог, который копирует свойства рекурсивно и заменяет только значения если в целевом объекте уже есть ещё один объект, а если нету, то дополняет?

встроенного не припомню

в JS? Как называется?

Object.assign( {}, {})

Кстати есть встроенный аналог, который копирует свойства рекурсивно и заменяет только значения если в целевом объекте уже есть ещё один объект, а если нету, то дополняет?

https://lodash.com/docs/4.17.10#merge по описанию - оно

This method is like _.assign except that it recursively merges own and inherited enumerable string keyed properties of source objects into the destination object. Source properties that resolve to undefined are skipped if a destination value exists. Array and plain object properties are merged recursively. Other objects and value types are overridden by assignment. Source objects are applied from left to right. Subsequent sources overwrite property assignments of previous sources.

Можно нативной, я тебе выше написал

Object.assign( {}, {})

он умеет делать рекурсивно?

По мойму да

Ясно, спс. Да видел loadash, богатая библиотека. Просто хотелось чего-то простого из коробки, без дополнительных либ.

Проверь

По мойму да

нет)

))

То есть только 1 уровень?

Ясно, спс. Да видел loadash, богатая библиотека. Просто хотелось чего-то простого из коробки, без дополнительных либ.

из коробки много чего нет) поэтому есть столько утилитарных библиотек (ramda, lodash, underscore)

То есть только 1 уровень?

да, только 1й уровень, где примитивы копируются по значению, объекты и функции - по ссылке

То есть только 1 уровень?

насколько я понял, человеку нужен был deepMerge/deepClone

Ну похоже)

Можно и без лодаша: function deepClone(o) { return new Promise(resolve => { const { port1, port2 } = new MessageChannel(); port2.onmessage = ev => resolve(ev.data); port1.postMessage(o); }); } (async function () { const obj = { a: 1, b: { c: "foo" } }; const cloned = await deepClone(obj); console.log(cloned); })(); для ноды не будет работать, но там это и не нужно особо, хватает встроенных утилит

Можно руками быстро сделать

На самом деле, мне в JS вообще глубокое копирование почти не пригождалось

насколько я понял, человеку нужен был deepMerge/deepClone

Ну вот склонить можно через assign

Object.assign в 99.9% решает все проблемы

))

Ясно, спс. Да видел loadash, богатая библиотека. Просто хотелось чего-то простого из коробки, без дополнительных либ.

это нужно для работ в сфере frontend или backend?

если не секрет

В обоих направлениях)

или какая-то совсем специфическая задача

а)

Забудьте уже про lodash, ramda и прочие абстракции накладывающие нехилый оверхед и добавляющие килобайты кода

В обоих направлениях)

с JS недавно, или я ошибаюсь?)

Забудьте уже про lodash, ramda и прочие абстракции накладывающие нехилый оверхед и добавляющие килобайты кода

продолжайте)

мысль не закончена, явно

А что заканчивать? Вот смотри: https://gist.github.com/MaxGraey/e7486833ae3a7abe072ac35afce8a240

с JS недавно, или я ошибаюсь?)

Да пару месяцев, на ноде пишу

Фронтендер отказался php устанавливать, а там сложная дичь на вуе

А что заканчивать? Вот смотри: https://gist.github.com/MaxGraey/e7486833ae3a7abe072ac35afce8a240

я все прочитал, логика ясна, но вот только не все так просто

я пользовался и пользуюсь всем из этого, больше всего rxjs

я все прочитал, логика ясна, но вот только не все так просто

Ты сколько во фронтенде/бэкенде?)

нет, я везде

А что заканчивать? Вот смотри: https://gist.github.com/MaxGraey/e7486833ae3a7abe072ac35afce8a240

Очень натянутый и синтетический тест

Очень натянутый и синтетический тест

Ну так поэтому это гист.

Забудьте уже про lodash, ramda и прочие абстракции накладывающие нехилый оверхед и добавляющие килобайты кода

ты сказал "забудьте", и только потом добавил "ты из frontend". В абстракциях нет ничего плохого, и уж точно не в библиотеках - это абсурд

Ну так поэтому это гист.

что касается конкретно compose через reducer - очевидно, что он будет работать быстро

потому что ramda ужасно тяжелая из-за автокаррирования повсюду (у нее очень много внутренних оберток-абстракций в самих ее исходниках)

ну не используй Ramdу

используй более другие средства

в дополнение к этому любой pure-javascript подход будет добавлять оверхед

теперь, что касается массива с семью или сколько там нулей

нигде на бэкенде в жизни я не обрабатывал таких массивов данных

purejs будет чаще всего жырнее по loc и менее читабелен

node.js бэкенд - это "скоросшиватель" небольших по своей сути ответов от БД и других сервисов

поэтому мне не кажется, что та же ramda очень больно ударит по среднему бэкенд-сервису

максимум, что с чем мне придется работать (и то вряд-ли) в большинстве случаев - это сотня записей из БД, которые я покажу на очередном отрезке пагинации

где нибудь на клиенте

поэтому для узких мест, если они будут, я применю pure-lambda-подход, в остальных случаях, я не напишу что-то более производительное лодаша, если дело зайдет дальше compose или каррирования

нигде на бэкенде в жизни я не обрабатывал таких массивов данных

А при чем здесь это? С маленькими массивами будет все тоже самое, просто тайминги будут нулевые у всех так как conole.timeEnd выводит только три знака после запятрой

никуда ramda не ударит. в живой среде никто не будет 10 млн итераций гонять с помощью ramda

А при чем здесь это? С маленькими массивами будет все тоже самое, просто тайминги будут нулевые у всех так как conole.timeEnd выводит только три знака после запятрой

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

никуда ramda не ударит. в живой среде никто не будет 10 млн итераций гонять с помощью ramda

+

десятки, сотни, единицы тысяч записей в худшем случае из БД

ERROR: S client not available

если ты дергаешь миллионы записей из БД для обработки рамдой - иди писать в 1С, там таких любят

в чем этот gist меня должен убедить? не использовать вышеупомянутые абстракции в принципе?

Забудьте уже про lodash, ramda и прочие абстракции накладывающие нехилый оверхед и добавляющие килобайты кода

потому что звучало это так

поэтому для узких мест, если они будут, я применю pure-lambda-подход, в остальных случаях, я не напишу что-то более производительное лодаша, если дело зайдет дальше compose или каррирования

Посмотри реализации алгоритмов Арафонкина для mapbox.js тот же delaunator или earcut.js. Не найдешь там ни ramda ни lodash =)

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

я как раз сталкиваюсь, только не на js :)

мне это как-то все кажется притянутым за уши, если честно :) мне в принципе на бэкенде все вышеупомянутое не часто требовалось compose/pipe я итак руками пишу всегда и кидаю в папку utils

в остальном, я не знаю, что мне ответить

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

все эти штуки типа триангуляции и mapboxjs это всё очень очень специфичные штуки

вживой природе овер 90% программеров этого не трогает

и рамда и lodash будет для них прекрасным инструментом

все эти штуки типа триангуляции и mapboxjs это всё очень очень специфичные штуки

да, и тут еще очень важен компромисс

а когда они дойдут до бигдаты - они сами поймут каким способом и что сделать и что рамда тут лишний

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

всегда будут абстракции - это факт

утилиты, библиотеки, хелперы - все это абстракции, без которых никак

среди них всегда есть альтернативы для выбора

Что там про сальто говорили?) Если для таких простых вещей нужно тянуть внешние зависимости то пожалуйста, в npm подобного добра завались

и тот же lodash и рамда прекрасные инструменты для отлаживания алгоритмов и возможно потом и не надо будет от них избавлятся потому что выясница что тормоза не из-за них

утилиты, библиотеки, хелперы - все это абстракции, без которых никак

Так я же не против хелперов) Я против стандартных хелперов которые к тому же являются обвертками уже втроенных средств и собраны в огроменные либы

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

нет, не последний, но важный.

Так я же не против хелперов) Я против стандартных хелперов которые к тому же являются обвертками уже втроенных средств и собраны в огроменные либы

как можно быть вообще абсолютно против чего-либо? :)

ты все равно в итоге напишешь велосипед

тот же lodash.curry немного толще твоего curry будет

ты все равно в итоге напишешь велосипед

А зачем пользоваться чьим то велосипедом (или точнее трактором, танком и т д) если тебе нужен скейт?)

вот это уже более конкретный вопрос

согласен тут на 100%

вот пример

есть желающие получить кучу вопросов от начинающего студента, возможно на постоянной основе?)

мне нужен equalityCheck для потока данных в rxjs, я гляжу в lodash, там есть метод isEqual