Problem

For now there are two problems with object/path types:

1. path doesn't infer type of a prop based on the strings inside array in all cases except a single value array

const user = {
  nestedProp: {
    name: 'John'
  },
};

const userName = path(['nestedProp', 'name'], user); // results in `unknown` type

2. using a type argument is not typesafe and repetative

// can do the trick
// but we throw all the typesafety away, because type of `name` can change in the future
// and this dirty cast will only error out in runtime.
// Also it feels like we gave compiler all the information it needs to infer this type
// and it feels weird that we have to add types ourselves
const userName1 = path<string>(['nestedProp', 'name'], user);

Solutions

I see two solutions here: implement ValueByPath helper type ourselves or use https://github.com/millsp/ts-toolbelt util
Both solutions are available in codesandbox: https://codesandbox.io/s/relaxed-lewin-e3njhm?file=/src/index.ts

Manual

import type { Prop, Paths } from "@tinkoff/utils/typings/types";
import curryN from "@tinkoff/utils/function/curryN";

type IsExactKey<T> = string extends T
  ? false
  : number extends T
  ? false
  : symbol extends T
  ? false
  : true;

type ValueByPath<P extends Paths, O, U = true> = P extends readonly [
  infer F,
  ...(infer R)
]
  ? F extends keyof O
    ? R extends []
      ? U extends true
        ? O[F] | undefined
        : O[F]
      : R extends Paths // In case we run into some kind of dynamic dictionary // something like Record<string, ..> or Record<number, ..> // We want to make sure that we get T | undefined instead of T as a result
      ? IsExactKey<keyof O> extends true
        ? ValueByPath<R, O[F], U>
        : ValueByPath<R, O[F], true>
      : undefined
    : undefined
  : undefined;

type Path = {
  (pathToProp: Prop[]): (obj: object) => unknown;
  (pathToProp: Prop[], obj: object): unknown;
  <P extends Paths>(pathToProp: P): <O>(obj: O) => ValueByPath<P, O>;
  <P extends Paths, O>(pathToProp: P, obj: O): ValueByPath<P, O>;
};

const _path = <K extends Prop, O extends Record<K, any>>(
  paths: Paths = [],
  obj: O = {} as any
) => {
  let val = obj;

  for (let i = 0; i < paths.length; i++) {
    if (val == null) {
      return undefined;
    }

    val = val[paths[i]];
  }

  return val;
};

export const path = curryN(2, _path) as Path;

TS-toolbelt

import type { Any, Object } from "ts-toolbelt";
import curryN from "@tinkoff/utils/function/curryN";

type Path = {
  (pathToProp: Any.Key[]): (obj: object) => unknown;
  (pathToProp: Any.Key[], obj: object): unknown;
  <P extends readonly Any.Key[]>(pathToProp: P): <O>(
    obj: O
  ) => Object.Path<O, P>;
  <P extends readonly Any.Key[], O>(pathToProp: P, obj: O): Object.Path<O, P>;
};

const _path = <K extends Any.Key, O extends Record<K, any>>(
  paths: readonly Any.Key[] = [],
  obj: O = {} as any
) => {
  let val = obj;

  for (let i = 0; i < paths.length; i++) {
    if (val == null) {
      return undefined;
    }

    val = val[paths[i]];
  }

  return val;
};

export const pathT = curryN(2, _path) as Path;

Migration problem

In case we implement any of these solutions some of the library dependants can have migration issues, because they could have leaned on the usage of type parameters and now the generic is completely different. To provide a more smooth migration story we can add two more overloads with a single type parameter, mark them as deprecated and remove them completely in future versions

type Path = {
  (pathToProp: Prop[]): (obj: object) => unknown;
  (pathToProp: Prop[], obj: object): unknown;
  /** @deprecated please use `path` without type parameters instead */
  <T>(pathToProp: Prop[]): (obj: object) => T;
  /** @deprecated please use `path` without type parameters instead */
  <T>(pathToProp: Prop[], obj: object): T;
  <P extends Paths>(pathToProp: P): <O>(obj: O) => ValueByPath<P, O>;
  <P extends Paths, O>(pathToProp: P, obj: O): ValueByPath<P, O>;
};

Consider adding shallow equal check

Заметил проблемку в findIndex, при вызове callback передается только один аргумент, тогда как в Array.prototype.findIndex их три. Не хватает индекса и массива. В find так же.

splitEvery is undocumented
https://tinkoffcreditsystems.github.io/utils.js/function/index.html#static-function-splitEvery

Since docs are generated automatically, shouldn't we store them only in the gh-pages branch?

Whether it was made intentionally or not, src/sanitize.js supports only one <em> tag. Are you planning to add some more important tags ( i.e <script>) or better yet let a developer himself to pass a Regex as an argument?

As every util has only default export, we can use something like https://github.com/59naga/babel-plugin-add-module-exports to get rid of imports like
const isArray = require('@tinkoff/utils/is/array')
in common.js environments.

Detailed overview of problem - https://babeljs.io/docs/en/babel-plugin-transform-es2015-modules-commonjs

Subject.

From README.md:

Most of the utilities are automatically curried

Auto-currying may be very convenient for those who already get it, but it also may be extremely confusing for newcomers (curried functions and higher-order functions in general are harder to use, let alone debug or build new code using them). We could transpile using a custom babel plugin and cut out curry() calls where appropriate (from top-level exports at least) by default, and let people opt-in using a different entry point.

I propose that we either implement the following schema using paths:

import map from '@tinkoff/utils/object/map' // requires all args

import mapR from '@tinkoff/utils/R/object/map' // auto-curried
// or
import mapR from '@tinkoff/utils/object/map/R' // auto-curried

or named exports

import default as map, {R as mapR } from '@tinkoff/utils/object/map' // for auto-curried exports

Очень часто нужно добавить элемент в массив по индексу и вернуть новый массив.
Такое простое действие каждый раз порождает неприятные конструкции в коде:

 const newArray = [...array]

 newArray.splice(index, 0, newElement)

или

const newArray = array.slice(0, index).concat([newElement]).concat(array.slice(index))

For example on - https://tinkoffcreditsystems.github.io/utils.js/ "Documented", "/is" and etc links do not work

In current implementation the first element in source array never will be placed at first place at result array.
Seems like a bug in generating a random index at https://github.com/TinkoffCreditSystems/utils.js/blob/master/src/array/shuffle.js#L15

It's possible to create custom type guard functions in typescript - https://basarat.gitbooks.io/typescript/docs/types/typeGuard.html

For example, function '/is/array' could be some something like this
const isArray = function (test): test is string { return !!test && Array.isArray(test); };

Omit not stringifies numbers for object key equation
ramda.omit([1], {'1': 'hello'}); // {} - empty object lodash.omit({'1': 'hello' }, [1]) // {} - empty object omit([1], {'1': 'hello'}); // {'1': 'hello} - not empty object, because 1 is number

Copying .babelrc to result package on npm may cause issues.
See babel/babel#4707 but for now we cant just just remove it, otherwise the webpack builds will fail for some specific configurations.
For more details: #8 (comment)

There is two identical utilities https://github.com/TinkoffCreditSystems/utils.js/blob/master/src/not.js and https://github.com/TinkoffCreditSystems/utils.js/blob/master/src/is/not.js remove one of the duplicate

This line https://github.com/TinkoffCreditSystems/utils.js/blob/master/src/array/maxBy.js#L17 is always executed and error may occure if callback not check its input

It doesn't works

pathOr<string, Array<any>>(['data', 'categories'], [], result);

Right now clone is 45% and sanitize around 65%

Problem:
In a case when a function throttled with throttleEnd is invoked several times within a wait period it is finally called by throttleEnd with arguments, provided at first invoke.

const throttled = throttleEnd(100, console.log)
throttled(1)
throttled(2)
throttled(3)
// -> 1

Lodash throttle behaves differentely:

const throttled = _.throttle(console.log, 100, { leading: false, trailing: true })
throttled(1)
throttled(2)
throttled(3)
// -> 3

RxJS operator auditTime, which is similar to throttleTime, but emits at the end of the wait period, behaves likewise:

const throttled = new Observable(observer => {
	observer.next(1)
	observer.next(2)
	observer.next(3)
}).pipe(auditTime(100))
throttled.subscribe(console.log)
// -> 3

Using the last provided set of arguments seems much more logical to me.

I suggest changing the throttleEnd implementation to make it more sense.

Bug Report

Hi everybody, nice lib.

I've found a small bug with isEqual.

Sometimes (not often) i need logic like this:

const positiveNumbers = numbers.filter(isPositiveNumber)
const negativeNumbers = numbers.filter(complement(isPositiveNumbers))
/// some tramsforms of this values
...

so it's not very fast and declarative. Also it becomes too repetetive, when there are more then 2 groups. So I need something like this:

const [positiveNumbers, negativeNumbers] = groupByArrays([isPositiveNumber], list);

So I mean that i can pick my sublist by index/
Also there is other usecase with more than 2 groups:

const [positiveNumbers, negativeNumbers, strings, rest] = groupByArrays([isPositiveNumber, isNegativeNumber, isString], list);

So realization can be something like this:

groupByArrays = (fns, arr) => {
    const result = [];
    let a, b = arr;
    
    return fns.map((fn) => {
        [a, b] = partition(fn, b);
        
        return a;
    }).concat([b])
}

It's very popular use case to write boilerplate:
import isEmpty from 'is/empty'; import complement from 'function/complement'; const notEmpty = complement(isEmpty) // or "isNotEmpty" name ...

In some cases i need converge function, f.e.
`
const extractOfferSuggestions = pathOr(["offerSuggestions"], []);
const extractWordSuggestions = pathOr(["wordSuggestions"], []);
const mapSuggestionsToOptions = (suggestions): SuggestOption[] => [];

// without converge
const transformSuggestionsToOptions = suggestions => {
const wordSuggestions = extractWordSuggestions(suggestions);
const offerSuggestions = extractOfferSuggestions(suggestions);
return mapSuggestionsToOptions({
offerSuggestions,
wordSuggestions
});
};

// with converge
const transformSuggestionsToOptions = converge(
([wordSuggestions, offerSuggestions]) =>
mapSuggestionsToOptions({ offerSuggestions, wordSuggestions }),
[extractWordSuggestions, extractOfferSuggestions]
);
// or with other mapSuggestionsToOptions signature (two params instead of one object param)
const transformSuggestionsToOptions = converge(
mapSuggestionsToOptions,
[extractWordSuggestions, extractOfferSuggestions]
);
`
Some points on this combinator https://jrsinclair.com/articles/2019/compose-js-functions-multiple-parameters/

I think, createSelector from 'reselect' has the same idea (but with memoization)