tddbin / katas Goto Github PK

Morning sir 🌅

I'm wondering if we move CHANGELOG.md into separate issues, and tag them with help-wanted or pull-requested-welcomed, then we can know what to contribute first and close it as soon as possible.

Another way to organize the roadmap might be utilizing Project panel and integrate with Issues panel, so that you can prioritize these planned feature.

Finally, I want to express my sincere love for this project 😂💖

Hi there,

I don't really get whether I should just implement parseInt here or also fix the tests ? On https://tddbin.com/#?kata=es1/language/global-api/parseInt it is showing var numericString = ''; compared to here:

Not sure if I am missing anything but to solve this one has to change assert line, yeah? But comment instructions still tell you not to do so.

Hi!
You've grouped destructuring kata into rest parameter syntax. But I think it's not correct, because in case of destructuring you are not using rest syntax, you are using spread operator instead. It just happens that spread can behave similarly to the rest syntax. In specs it is called SpreadElement http://www.ecma-international.org/ecma-262/6.0/#sec-array-initializer. And Mozilla thinks the same https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator.

'coercion, as in == and ===, does NOT apply'

Triple equals (===) a.k.a. "Strict Equality Operator" is not coercive.

I want to disagree with you about renaming kata http://tddbin.com/#?kata=es6/language/destructuring/rename. I think there is no renaming. Let me explain my point of view.

We have this code [1]:
const {x: y} = {x: 1};
assert.equal(y, 1);

It is equivalent to [2]:
const {x: x} = {x: 1};
assert.equal(x, 1);

Which is in turn equivalent to [3]:
const {x} = {x: 1};
assert.equal(x, 1);

So in snippet 3 we have a case of shorthanding the destructuring assignment. Basically it means: destructure an object which has a property by the name "x" and assign it's value to a variable named "x". The explicit version of this is in snippet 2.
Snippet 1 on the other hand tells: destructure an object which has a property by the name "x" and assign it's value to a variable named "y".
There is no renaming of any kind, just a classical destructuring.

We can see this in specs: http://www.ecma-international.org/ecma-262/6.0/#sec-destructuring-assignment. The grammar reads as follows:
AssignmentProperty[Yield] :
IdentifierReference[?Yield] Initializer[In,?Yield]opt
PropertyName : AssignmentElement[?Yield]
AssignmentElement[Yield] :
DestructuringAssignmentTarget[?Yield] Initializer[In,?Yield]opt

So we have a "PropertyName" and an "AssignmentElement", which is no more than a "DestructuringAssignmentTarget" with an optional "Initializer".
In out example:

const {
x: // PropertyName
y // DestructuringAssignmentTarget
} = {x: 1};

or even:

const {
x: // PropertyName
y // DestructuringAssignmentTarget
=42 // Initializer
} = {y: 23};

Trying to run a build

$ npm run build

> [email protected] build /katas
> ./scripts/build.sh

sed: -e expression #1, char 40: unknown option to `s'
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: `./scripts/build.sh`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

I think it may have something to do with the slashes in the sed commands in build.sh.

class extends null was reverted by ECMAScript in tc39/ecma262#781 ( tc39/ecma262@c57ef95 ) and is still broken.

The kata is abnormal since it doesn't have a solution in the test itself.
So, the question is whether we should have that test for class extends null?

However, I found a possible solution thanks to devdocs.io ( which had a previous version of the MDN Web Docs; revision ) :

class NullClass extends null {}
assert.equal(Object.getPrototypeOf(NullClass), Function.prototype);

When calling super.constructor in last test you get

AssertionError: 'class A {\n constructor() {\n "parent";\n }\n\n }' == 'class A {constructor() {"parent"}}'@spec-runner.js line 105073 > eval:77:5

Related: es6katas.org:#31

Practicing Reflect.defineProperty while focusing on one parameter at a time will not provide a good understanding of the function if the third parameter is omitted. Reflect.defineProperty will throw if it does not receive an object as its third parameter.

The following test will always pass:

//@@line 17~21
  describe('the 1st parameter is the object on which to define a property', function() {
    it('fails if it is not an object', function() {
      let noObj = {};
      assert.throws(() => { Reflect.defineProperty(noObj); }, TypeError);
    });

The following tests will always fail:

//@@line 22~29
    it('accepts an object', function() {
      let obj = '';
      assert.doesNotThrow(() => { Reflect.defineProperty(obj); });
    });
    it('accepts an instance (of a class)', function() {
      let instance;
      assert.doesNotThrow(() => { Reflect.defineProperty(instance); });
    });
//@@line 91~95
      it('when no 3rd parameter, the descriptor is given', function() {
        let instance = new class {};
        const wasPropertyDefined = Reflect.defineProperty(instance, 'prop', {value: 1});
        assert.equal(wasPropertyDefined, false);
      });

since Reflect.defineProperty throws when the third param is not an object (in these cases, the third param would be undefined if the user tries to abide the assertion statements).

Not too sure what's going on here:

//@@line 85~90
    describe('returns false', function() {
      it('when no property name is given (since no property has been added)', function() {
        let instance = new class {};
        const wasPropertyDefined = Reflect.defineProperty;
        assert.equal(wasPropertyDefined, false);
      });

If you specify the second param as no property name or '', this returns true because the property is assigned to instance[''], causing the test to fail.

let instance = new class{}
Reflect.defineProperty(instance, '', {value: 'foo'})
instance[''] //returns 'foo'

we're fetching xdmomain from https://unpkg.com in proxy.html ( at least for the production website ).

we also have an outdated version of xdomain vendored in vendor/xdomain. I understand that this was probably done for working offline

questions :

1. do we really need to keep the outdated vendoring? if yes, then why not just use it for the main website as well? that'd be one third-party request ( and cookie ) lesser when loading the katas online ( apart from https://cdn.jsdelivr.net, https://cdnjs.cloudflare.com and https://ajaxorg.github.io that are being called from https://tddbin.com anyway ). also, if yes, we need to update the vendored script.

2. if we decided to stick with the script being fetched from a CDN, then can we please change the CDN from unpkg to cloudflare or JSDelivr?

the argument here is to reduce the number of third-parties being called from the root domain.

aside : I'll open another issue at tddbin-frontend to unify all the library loading to a single provider.

next, coming to the usage of the vendored script itself.

like I mentioned earlier, I understand that the vendoring was done to work offline. however, when I looked at build-for-offline.sh, it has been outdated for at least 8 months now because the script src domain in proxy.html was changed from https://cdn.rawgit.com to https://unpkg.com but not in the script. so now, the question is, do we need the offline build capability at all? I know that's a dumb question ( because Wolfram seems to say that quite a lot in a different places ;) ). I'm going to assume the answer is yes, but its just that the script was just missed to be updated.

for context, the reason I'm asking these questions is because I'm trying to optimize the build scripts ( and in turn the CI system as well ) and I'd like to know what capabilities to maintain support and spend time on. It would be useless to spend time to extend the functionality so a feature that is seldom used.

I couldn't get the kata to resolve. So I checked out the original checkin (which should pass). Tests 2&3 don't work.

But pasting it into Chrome debugger, it works properly (as it should).

Test

  describe('extending a `Promise`', function() {
    it('is possible', function() {
      class MyPromise extends Promise {}
      const promise = new MyPromise(resolve => resolve());

      promise
        .then(() => done())
        .catch(e => done(new Error('Expected to resolve, but failed with: ' + e)));
    });
    it('must call `super()` in the constructor if it wants to inherit/specialize the behavior', function() {
      // WARNING: this example doesn't fulfill the Liskov principle
      class ResolvingPromise extends Promise {
        constructor() {
          super(resolve => resolve());
        }
      }

      return new ResolvingPromise();
    });
  });

Returns

extending a Promise
is possible ‣
TypeError: # is not a promise
at new MyPromise (eval at runSpecs (http://tddbin.com/mocha/spec-runner.js:95056:7), :28:81)
at eval (eval at runSpecs (http://tddbin.com/mocha/spec-runner.js:95056:7), :34:21)
at r (http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:9112)
at r.o.run (http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:9812)
at o.runTest (http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:13250)
at http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:13824
at r (http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:12787)
at http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:12763
at n (http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:12554)
at http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:12618
must call super() in the constructor if it wants to inherit/specialize the behavior ‣
TypeError: # is not a promise
at new ResolvingPromise (eval at runSpecs (http://tddbin.com/mocha/spec-runner.js:95056:7), :53:88)
at eval (eval at runSpecs (http://tddbin.com/mocha/spec-runner.js:95056:7), :61:14)
at r (http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:9112)
at r.o.run (http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:9812)
at o.runTest (http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:13250)
at http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:13824
at r (http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:12787)
at http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:12763
at n (http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:12554)
at http://cdnjs.cloudflare.com/ajax/libs/mocha/2.1.0/mocha.min.js:2:12618

In Chrome

done = (retval) => `done ${retval}`
(retval) => `done ${retval}`
      class MyPromise extends Promise {}
      const promise = new MyPromise(resolve => resolve());

      promise
        .then(() => done())
        .catch(e => done(new Error('Expected to resolve, but failed with: ' + e)));

Returns

Promise {[[PromiseStatus]]: "resolved", [[PromiseValue]]: "done undefined"}

  it('one parameter can be written without parens', () => {
    var func = p => param - 1;
    assert.equal(func(23), 24);
  });

Pretty sure func(23) should be func(25).

I came across https://jskatas.org as a reference to learning JavaScript.

I was wondering if it was a good idea to have a template repository that people could just fork and start learning by fixing the tests within the repository itself ( committing the fixed code and pushing to remote could also introduce learning some git along the way too ).

this way one could show progress and validate whether the solutions are correct with a peer who knows better.

I started using the online version and then found myself not sure whether my changes were accurate ( though I was getting the tests to pass ).

So, I thought why not just clone the repository and then do the tests locally? And as I was navigating the repository is when I got this idea.

I noticed the mention of nobody has nodejs installed globally anymore. While I don't want to argue / contest that notion, I believe that it would be of use for people to be able to just fork a repository, clone it locally, start fixing tests and learn javascript along the way. If they pushed to remote, they could get those tests validated from their peers too.

So, here's my proposal :

• create a separate template repository
• move all the test files ( with the tests failing ) into the repository.
• add a relevant package.json with relevant packages and scripts ( bonus : we could add scripts per file / category ).
• add a relevant README to show how to use the repository

... watch how people use it and gain insights to make it better

what do you think?

Hello there!

Solution for Kata 40 freezes the browser tab, not sure why: https://gist.github.com/nullv01d/f114cb4560750834d4c57f25d8da2551

It's replicable on Chrome, IE and Firefox.

Not an issue/bug, just an offer:

I could change (via PR) the initial code
from
let thisStep = generator;
let [value, done] = [thisStep.value, thisStep.done];
to shorter
let {value, done} = generator;
.

http://tddbin.com/#?kata=es6/language/arrow-functions/binding
Description of test is:

can NOT bind a different context

but assert is:

assert.strictEqual(fn.call(anotherObj), expected);

It looks that meant notStrictEqual

In the chapters Promise/basics (75) and Promise/chaining (77) there is one test green. It is not the right code but it is green by accident. This is confusing for beginners.

On http://tddbin.com/#?kata=es6/language/destructuring/rename the kata "rename object key" is green right away (tested only in in FF & Chrome).