fix indexing into array with deep propery #385

Merged
merged 2 commits into from Mar 3, 2015

Projects

None yet

2 participants

@matthew-n
Contributor
  • added unit test to expect with code from documentation
  • added default to res in _getPathValue
@matthew-n matthew-n fix indexing into array with deep propery
* added unit test to expect with code from documentation
* added default to res in _getPathValue
57ef366
@keithamus
Member

@eldritch-fossicker thanks very much for the PR, but I must admit I can't really tell what this is solving or doing. Could you please elaborate on your explanation with what this aims to fix; perhaps with examples of currently broken code that will be fixed by this PR? Thanks

@matthew-n
Contributor

certainly the I had a test that kept failing which was very similar to:

expect(deepObj).to.have.property('teas')
  .that.is.an('array')
  .with.deep.property('[2]')
    .that.deep.equals({ tea: 'konacha' });

(from the chain-able portion of the property documentation) Trying to walk into the array by index always failed. So, I added the snipped from the documentation to the unit tests. Then I solved the problem by changing _getPathValue to return a value other than undefined to info.parent when path.length = 1

@keithamus
Member

I guess what is not making sense to me is the fix. It seems to be relying on a side-effect added to _getPathValue rather than explicitly tackling the problem. It feel as though the current fix is somewhere non-obvious and may well trip people up when refactoring. To me, it seems better to change L35 from:

parent: _getPathValue(parsed, obj, parsed.length - 1),

to:

parent: parsed.length > 1 ? _getPathValue(parsed, obj, parsed.length - 1) : obj,

As this is much more explicit as an indicator for what is going on. What are your thoughts @eldritch-fossicker?

@matthew-n
Contributor

@keithamus that will certainly fix the problem. My first conclusion when I looked at the function was that walking path to an index of 0 should return the object itself; therefore, the function should fixed. I think a conditional return or comment would be in order. But, I'm just concerned with fixing the error whichever solution.

@keithamus
Member

I see where you're coming from now @eldritch-fossicker. Ultimately it's neither here nor there - but the original patch seems slightly less explicit. On your point about if it were called with an index of 0 - I'd suggest that it shouldn't be called at all if that is the case.

If you could amend the patch to my reflect my comments above I'd be very happy at merging this though 😄

@keithamus
Member

🎉

@keithamus keithamus merged commit dbeb2a8 into chaijs:master Mar 3, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment