• This comment is hidden because it contains spoiler information about the solution

  • in this kata we mutate object, so if we will replace primitives with object/array, we will lost their data.

    for example,

    const obj = {a: ['x', 'y']}
    deepAssignment(obj, 'a[0].b', 1), obj.a[0]
    obj.a[0] // we can expect 'x', but get {b: 1}

    And in fact we should not assign props to primitives, and it looks like deepAssignment should throw an exeption, that this path is invalid or something like that.

  • Thanks for pointing this out.

    I can add a test to clarify that the string type should be converted, based on getter access? Or rather, what do you think would make more sense, and make the kata more useful?

  • My solution - if a primitive value found in chain - replace it with object/array

  • Yes, I just looked at the last test case and that's pretty much it.

    I think we need some author clarification :)

  • I've got a problem with final case.

    Input object is something like { ..., ddd: [ 'ddd[0]', ... ], ...}
    Input path is kinda ddd[0].asdfe.ddd[2]...

    When we resolve path like this, we go to the array ddd, take the first element (which is ddd[0]) and then we need to assign asdfe to the string ddd[0], but it would not work for primitive values like String.

    So test fails because we can't read .ddd in asdfe, because it's undefined in string.

    It can be assumed, that this test means that we need to go up and use the parent Array for values like this, but it's not clear and there is nothing about in description.

    We need to fix the last test or update the description with better clarification, because this behavior is implicit

  • cool and awesome.

    That'd be great. I put in an honest attempt at figuring out why the last test was sketchy.

    I'd be interested in finding out what it is.


  • Approved

    (As for the final test case, I'll look at it later. If you have problems with it, just try resubmitting a few times.)

  • yeah i spent the better part of a day trying to figure out what the problem was as well. i am pretty confused about it.

  • After reviewing the kata's internals, it turns out I was incorrect about the keyPath output as mentioned earlier; it was actually the kata test that was evaluating whether the output was as expected. Without investing a lot more time into reviewing each component of the generated object in the final test, I'm unable to see where things are going wrong.

    I'll mark this issue as resolved for now; perhaps someone else may be able to spot what's causing solutions to fail part of the time. My solution passes final tests about 25% of the time. Several other submitted solutions (that have passed) from other CW users are failing the final test as well.

  • Interesting. Let me know if you find what the issue is. I'll keep looking when i get more time. It is happening in the last test case, this much i know. haha.

  • This comment is hidden because it contains spoiler information about the solution

  • This comment is hidden because it contains spoiler information about the solution

  • I'll have a look at it this weekend.

  • There appears to be an error with how the final test case is generated. Sometimes it will create keyPath values such as the following:


    If the author is no longer active on CW, I'll look into fixing this and hopefully we get this kata approved. It's a good quality challenge.

  • Loading more items...