Basic Level: Completed

[learn-javascript-courses]

Basic Level: Completed

[ericelliott]

Cool UI!

UX design

The explanation really only needs to be seen the first time you run the app -- after which you should be able to dismiss it completely. Try looking at the app on your cell phone -- the form should be front and center with the call to action (accept/reject) buttons clearly inviting users to add questions.

Instead, the screen is dominated by text that doesn't need to be there after the first time the user has seen it.

I recommend designing your UI using a mobile view by default, which you can emulate in Chrome Dev Tools. Make sure it looks good on mobile, first -- particularly because this is a game you should take everywhere with you so you can add questions as they are asked and answered in the course of your day.

Separation of concerns

I noticed you have a bunch of unit tests that look roughly like this:

  it('checkScore should give the right score for accepted and rejected buttons', () => {
    const inputFirst = addElement('input');
    const inputSecond = addElement('input');
    inputFirst.className = 'accepted-button add';
    inputSecond.className = 'rejected-button add';

    assert.equal(1, checkScore(inputFirst), 'should give 1 for accepted');
    assert.equal(10, checkScore(inputSecond), 'should give 10 for rejected');
  });

The problem with this test is that you're testing domain logic:

• Given an accepted or rejected answer, what should we add to the score?

Why then are we manipulating the DOM to do it? The reason is that you're using the DOM to store and retrieve application state. The problem is that the DOM is like a giant global variable. Anything can reach out and mutate it at any time, and those manipulations may change the results of calling this function.

Ask yourself: Does calculating a score have anything to do with the state of what's being drawn to the screen?

The answer is No. You could have a list of questions in an array, with answers. You could calculate the score by reducing over that array and adding up the results, so you know the complete app state before you ever draw to the screen -- in fact, being able to load and save state in an explicit requirement.

Domain logic, such as state calculations, should be made up of pure functions -- that means they can't rely on external mutable state such as the DOM. See "What is a Pure Function?".

One interesting way to make sure all your state is calculated with pure functions is to embrace Redux. See "10 Tips for Better Redux Architecture" for more on Redux and why it's currently the most popular state management architecture in production JavaScript software.

In your next version, try implementing the app using React + Redux -- keeping all your state manipulations in pure reducer functions, rather than storing state dependencies directly on the DOM. Your DOM should depend on your application state -- not the other way around.