It is totally unclear from the description that the color of the top of the border should be set to a random color instead of the default "null" when the component is actually mounted, so this should at least be stated explicitly in the description.
But actually, the "random color" thing does not seem to add much value to this Kata and is IMO rather distracting. Perhaps consider removing it altogether?
Needs more fixed tests and random tests. For example, try simulating input values of different length and see if selection on clicking works properly to prevent hardcoding.
The maximal recursion depth is limited by JavaScript engine. We can rely on it being 10000, some engines allow more, but 100000 is probably out of limit for the majority of them. There are automatic optimizations that help alleviate this (“tail calls optimizations”), but they are not yet supported everywhere and work only in simple cases.
no, your own ones. the ones you don't see match, its your own braces that don't. you can easily show this by removing your own code and running empty code. you can avoid adding unbalanced braces by inserting and removing them in pairs, and you can avoid writing more code than you're able to debug by running your code after each small change.
FYI - Not sure what's going on, but I just tried your solution and it worked fine.
It is the best solution because it has constant time complexity. Any cycle method will lose against it.
It is totally unclear from the description that the color of the top of the border should be set to a random color instead of the default "null" when the component is actually mounted, so this should at least be stated explicitly in the description.
But actually, the "random color" thing does not seem to add much value to this Kata and is IMO rather distracting. Perhaps consider removing it altogether?
Needs "true" random tests, on top of the current mocked
Math.random()valuesNeeds more fixed tests and random tests. For example, try simulating input values of different length and see if selection on clicking works properly to prevent hardcoding.
Offline listener was tested but online listener should be tested as well.
Needs more fixed tests on top of the random tests @FArekkusu mentioned.
my self esteem after seeing these 1 line solutions be like "not stonks".
The maximal recursion depth is limited by JavaScript engine. We can rely on it being 10000, some engines allow more, but 100000 is probably out of limit for the majority of them. There are automatic optimizations that help alleviate this (“tail calls optimizations”), but they are not yet supported everywhere and work only in simple cases.
How does the number to character convertion happen? Is it ASCII or Unicode?
no, your own ones. the ones you don't see match, its your own braces that don't. you can easily show this by removing your own code and running empty code. you can avoid adding unbalanced braces by inserting and removing them in pairs, and you can avoid writing more code than you're able to debug by running your code after each small change.
This comment is hidden because it contains spoiler information about the solution
the smartest!
the invisible ones..? i cleared the page, refreshed - retyped the entire code sign for sign..
presumably your own braces don't match up
Loading more items...