Calculator fails test 8 (id=display)

JavaScript
1

Hi all,

I have no idea why my calculator is failing test 8, it all looks correct to me but I must be missing something. Can anyone point me in the right direction?

Pen is here: Calculator

Thanks,

Mark

2

I think the most obvious problem is that the calculator disappears when you click on it… If you open the console, you’ll see the error: TypeError: this.outputRef is undefined

It’s because you commented out this line:
this.outputRef = React.createRef();

Commenting that back in still doesn’t help though, you’ll get another error if you click on CE:
TypeError: this.debug is not a function

Otherwise, your calculator looks functional on first sight, so maybe you only have to fix the above errors to make the tests pass.

3

I’m an idiot @jsdisco , thought I removed the debug references; the outputRef was commented out to check for issues related to display.

Anyway, I have corrected those and still have the same problem; any ideas?

4

You can’t call yourself a developer unless you’re used to spending hours on fixing a stupid mistake, it happens to all of us…
Now since all of your functionaliy tests are failing (except the reset button), it’s likely that one of the tests produces a wrong result in the display, so all subsequent tests are failing, too. I’ve two guesses:

  1. You have a float number issue, you’ll see it if you enter 0.3x3

  2. If you enter 1+2x= into the example project, it just ignores the useless x operator and outputs 3, whereas your calculator returns Error: missing number. That would likely make other tests fail, too. For example a sequence 1+2x=/2 produces an output of 1.5 in the example project, but is 0 in yours.

I’m quite sure that fixing those two things will finally make all tests pass.

5

I didn’t actually do any testing, but I still think you might have a state issue in your app. Like I said in your other thread using top-level variables (unless static), even for deriving state from, is not something I would suggest doing in a React app.

Like I also mention in the other thread, if you punch in some numbers and then run the tests you will see more tests are now failing (including the reset) and in the error message you will see the numbers you entered. This suggests to me a possible state issue. But like I said this is not based on any testing and is just speculation so I might be wrong.

Side note. I would suggest you move the handlers up before the render it is confusing to have part of the component logic after the render.

6

Thanks again @jsdisco , I can look at the float issue, it looks like a rounding issue with eval.

As for the 1+2x, it is unclear from the stories how it should behave. This is an incomplete expression, the example project seems to ignore the final operator, a real calculator (Casio) results in error; in these cases I chose to emulate a real calculator - perhaps this is wrong?

Thanks again.

7

Thanks for the feedback again @lasjorg .

I’m not convinced about state being an issue, it is only updated after the main handler and processing has completed. Strange about punching numbers failing in the test though as I when I run all the test cases (the actual assert expressions) manually it produces the expected result. But I will look into it again.

Is the handler position just personal preference or does it affect anything?

Perhaps it’s just me, my background long ago is assember, C/C++, etc., so I’m used to defining things before using them.

Thanks again, really appreciate the feedback.

8

I wouldn’t call it personal preference, more like a standard convention.

I don’t think the render position can affect your app but the render with the JSX returned really should be the last thing in the class. Also, having to scroll past the render code every time you need to read/change code before/after is just not ergonomic.

But you are referencing methods inside the JSX before their definition, e.g. handleClick.

About the state…maybe not, but I also do not see the harm in putting variables that change and which the internal state depends on inside the component.

9

I’d have done it the same way as you (return “syntax error” or something), so I’d say you’re only “wrong” from the tests’ perspective. Which can be found here by the way, in case you’re curious:
https://github.com/freeCodeCamp/testable-projects-fcc/blob/master/src/project-tests/calculator-tests.js

The AC button is pressed before and after each test. So, since all the tests only pass for a human’s slow eyes, I agree that it might be a state update problem. Unfortunately I know absolutely nothing about class components and their lifecycle so I’m not of much help.

10

Ah ah! That link to the test is fantastic @jsdisco - it gives me something concrete to digest; thank you :+1:

I’ve learnt a little about React life cycles so I’ll take a look again at potential state issues.

I’m doing this (Freecodecamp) for curiosity and to keep a little fresh; I’m in my fifties and my dev days (very senior in the past) are long behind me; however I still try to learn what I can so really do appreciate the feedback; modern frameworks, tools etc. have changed a lot in 30 years!

11

Thanks again @lasjorg. I’m an old man learning modern frameworks and tools.

You are right - I was moving things around to see if it had any impact. Also if it’s convention to do it that way I’ll change it - good to know.

Thanks again.

12

Yeah it’s much easier to pass a challenge if you actually know what the challenge wants. The descriptions don’t always cover all possible cases, so looking at the tests saves you the hassle of tedious trial & error.

React is a little weird if you start off, but once you get used to it, it’s a pleasure to write code with it. The curriculum is a bit outdated, React is moving away from class components and now uses functional components instead. I’m kind of stubbornly refusing to learn class components (until I’m forced to because I have to work on a codebase that uses them). It doesn’t hurt though to dive into them, and depending on your coding background (more/less OOP), they might even be easier to reason with.

13

Thanks @jsdisco, good to know :+1:

14

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.