Советы по либе

Снаружи выглядит как переизобретение lodash. Не очень понятно, почему это того стоило (вполне допускаю, что могли быть причины).

Хотел бы видеть сравнение с популярными аналогами

«id» прибито гвоздями?

Снаружи выглядит как переизобретение lodash

lodash, конечно, могуч, но не про то. Точнее про всё понемногу, а тут акцент именно на массивы (списки, коллекции, кому как удобнее). Плюс, завёрнуто в класс, вместо вызова отдельных независимых функций

Хотел бы видеть сравнение с популярными аналогами

И правда! Какие-то конкретные популярные аналоги имеются в виду? Есть вот такая, но она лезет в прототипы встроенных объектов , и имеет куча какого-то сомнительного функционала с listener`ами

намертво

лично мне надоело писать одно и то же

Так всё равно же придётся. Большинство этих операций нужные ведь не сами по себе, а в контексте работы с конкретными данными и поэтому во-первых названия функций должны быть (в пользовательском коде) не абстрактными, а во-вторых может потребоваться небольшая обработка напильником.

А так вообще, ради науки, у тебя я вижу что нет flatten. Кроме того, неплохо было бы соответствовать различным стандартным интерфейсам, например Map.

lodash, конечно, могуч, но не про то. Точнее про всё понемногу, а тут акцент именно на массивы (списки, коллекции, кому как удобнее). Плюс, завёрнуто в класс, вместо вызова отдельных независимых функций

Пока звучит как вкусовщина. Для конструктивного обсуждения-критики действительно надо очень внятно сформулировать уникальность.

На лодаше, если что, можно врапнуть объект и через точку чейнить операции.

И правда! Какие-то конкретные популярные аналоги имеются в виду? Есть вот такая, но она лезет в прототипы встроенных объектов

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

Поэтому первый же вопрос, который зададут - зачем была сделана еще одна, и где ее преимущества.

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

Так всё равно же придётся

Конечно, но меньше. Например:

// вместо такого
const itemInd = array.findIndex( it => it === 3 )
if ( itemInd !== -1 ) { 
  return array.splice(itemInd, 1)[ 0 ]
}
return null

// такое
return collection.remove( 3 )

у тебя я вижу что нет flatten

Да, надо добавить, и не только его. Но, честно говоря, не видел человека, которому бы flatten понадобился

соответствовать различным стандартным интерфейсам, например Map

Это ж другая структура

Пока звучит как вкусовщина

Естественно, куда ж без неё) Кому-то вон вообще redux нравится

надо очень внятно сформулировать уникальность

Тут да, в этом я точно убедился

И библиотек на эту тему должны быть тонны

В теории, да, но путём гугления (совсем не долгого), не обнаружил что-то, что меня бы устроило

Не обижайся, но апи выглядит как «стихийное»

По мне всё логично, но это я его и писал, надо поспрашивать ещё у народа.

другая структура

А какая разница для целей реализации интерфейса? У тебя уже половина из Map есть, осталось ещё парочку добавить, а кое-что переименовать (toArray -> values, reset -> clear и т.д.). Даже если не рассматривать варианта передачи твоего контейнера куда-то вместо Map, то хотя бы из соображений единообразия.

не видел человека, которому бы flatten понадобился

Постоянно бывает нужен при массовой обработке. Впрочем, наверное, только если писать в ФП стиле.

вместо такого такое

К чему такие сложности? Я бы просто сделал arr.filter(e => e !== 3).

Не нужно: https://github.com/tc39/proposal-iterator-helpers

Нинужно. Сокращение кода на пару строк не стоит того, чтобы тащить в проект лишнюю сущность со своей спецификой и благами.

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

Не нужно

Нинужно

Наконец-то! Я уж начал думать, что лор уже не тот

В общем, спасибо всем! Картина стала яснее

https://github.com/tc39/proposal-iterator-helpers

Интересная ссыль, данке

Наконец-то! Я уж начал думать, что лор уже не тот

Просто обижать не хочется.

Много лет назад, когда довелось осиливать жыэс, тоже всякую ботву клепали https://www.npmjs.com/package/types. Но я вовремя понял что надо соскакивать :)

Плюс, завёрнуто в класс, вместо вызова отдельных независимых функций

Так это не плюс.

Да не, какие обиды. Я может тоже соскочу, но для этого сначала туда залезть

Он самый.

Array.prototype.flat

Так это пока proposal. Я в курсе про полифилы, но у ТС-а другой подход же.

Сейчас всего два браузерных движка: Chromium и высер от Mozilla. Они оба поддерживают Array.protype.flat -> все нормальные браузеры его поддерживают

export function isNum( some: any ): some is number {
  return typeof some === 'number'
}

typeof Infinity

«number»

Fail

все нормальные браузеры его поддерживают

И даже все китайские барузеры непонятного происхождения на мобилах? А как там в сафари дела на ипхончиках, в т.ч. старых? Полифил один хрен нужен, для спокойствия.

Это что и зачем?

Можно позавидовать такой точке зрения. Мне до сих пор IE приходится поддерживать

И? Не хватает для примера NaN и Number()

Раз уж ты выкинул свои поделки, надо это сделать и мне.

Суть библиотеки в том, чтобы облегчить работу с данными в виде массивов, особенно, если у элементов есть некий id. Т.к. лично мне надоело писать одно и то же)

Она у тебя нихрена не умеет в общем. Кучка методов завёрнута в класс на ts. Часто нужно, например, смержить по id два массива разными способами. Т.е. с точки зрения рбд - нужны join'ы, нормализация, денормалицация, выборки так, чтобы не под 1 кейс и чтобы не получилось, что телодвижений надо делать столько же или больше.