docs(isEmpty): differences between Radashi and Lodash

[MarlonPassos-git]

Tip

The owner of this PR can publish a preview release by commenting /publish in this PR. Afterwards, anyone can try it out by running pnpm add radashi@pr<PR_NUMBER>.

Summary

Document differences between Radashi and Lodash in the function isEmpty

Initially, I attempted to incorporate all the test cases from Lodash into Radash, and the following are my initial findings:

spec	passed the test?	action
should work with jQuery/MooTools DOM query collections	true	add to current tests
should return false for non-empty values	true	add to current tests
should work with sets	true	add to current tests
should work with sets	true	add to current tests
should not treat objects with non-number lengths as array-like	true	add to current tests
should work with arguments objects	true	add to current tests
should return an unwrapped value when implicitly chaining	false	something very specific to lodash that doesn't make sense here
should return a wrapped value when explicitly chaining	false	something very specific to lodash that doesn't make sense here
should work with prototype objects	false	document the difference
should not treat objects with negative lengths as array-like	false	if we change it, this test passes
should not treat objects with lengths larger than MAX_SAFE_INTEGER as array-like	false	if we change it, this test passes

I will put the failed tests here to make analysis easier.

it.skip('should work with an object that has a `length` property', () => {
    expect(_.isEmpty({ length: 0 })).toBe(false)
  })

  it.skip('should work with prototype objects', () => {
    function Foo() {}
    Foo.prototype = { constructor: Foo }

    expect(_.isEmpty(Foo.prototype)).toBe(true)

    Foo.prototype.a = 1
    expect(_.isEmpty(Foo.prototype)).toBe(false)
  })

  it.skip('should not treat objects with negative lengths as array-like', () => {
    function Foo() {}
    Foo.prototype.length = -1

    expect(_.isEmpty(new Foo())).toBe(true)
  })

  it.skip('should not treat objects with lengths larger than `MAX_SAFE_INTEGER` as array-like', () => {
    const MAX_SAFE_INTEGER = 9007199254740991
    function Foo() {}
    Foo.prototype.length = MAX_SAFE_INTEGER + 1

    expect(_.isEmpty(new Foo())).toBe(true)
  })

Related issue, if any:

#85

For any code change,

• Related documentation has been updated, if needed
• Related tests have been added or updated, if needed
• Related benchmarks have been added or updated, if needed

Does this PR introduce a breaking change?

No

Bundle impact

Status	File	Size 1	Difference (%)
M	src/typed/isEmpty.ts	536	+43 (+9%)

Footnotes

1. Function size includes the import dependencies of the function. ↩

[aleclarson]

This looks great. Thanks for starting this one!

[MarlonPassos-git]

I ended up discovering a false positive in the isEmpty function

it('should work with an object that has a `length` property', () => {
    expect(_.isEmpty({ name: 'asfd', length: 0 })).toBe(false)
    expect(_.isEmpty({ length: 0 })).toBe(false)
})

Currently, both expects fail because of this line of code:

const length = (value as any).length
  if (isNumber(length)) {
    return length === 0
  }

In my view, this is incorrect, and this length check should only happen with arrays. So, I would change it to something like:

if (isArray(value)) {
    return value.length === 0
  }

Even though the JSDOC mentions "object with length property of 0," I'm not sure I agree with it. Even more so since we didn't even have tests to guarantee this case

[MarlonPassos-git]

In the end, the only valid point to document is the constructor property in the prototype of a function.

function Foo() {}
Foo.prototype = { constructor: Foo }

[aleclarson]

Was this intentionally closed?

[MarlonPassos-git]

Now that I see it, it wasn't 😅. My fork has some git problems. I'd rather delete the fork and create another one, but it looks like they closed the PR.

[MarlonPassos-git]

I'll have to open the PR for the new fork now