Error Calculator Challenge

I am very grateful for all that you do at freeCodeCamp. I have joined your community about 1 month ago. I have been able to earn 2 certifications, and I have almost ready the 4th job (the Calculator) to get the from-end development certification.
It is happening to me that several of the validations of your testing, are not satisfactory, which is contradictory for me.
If someone could take a few minutes and review the functionality of to see if bundle.js fails and not my implementation.
Thank you very much in advance.

1 Like

I noticed that if I click on the calculator ‘display’ and then type on the keyboard, the calculator doesn’t read the numbers. I’m not sure if that’s you’re problem for sure. But you could compare that with the behavior of the FCC example calculator.

The FCC example does not use the keyboard, it only uses mouse events.
For that reason I have tried disabling the keyboard treatment and still the errors persist when I run the tests.

I am not able to understand what is happening.

Thanks for your time.

The problem of losing focus when clicking on the display has already been solved. Testing errors continue.

I tested your code a bit and it looks like you are relying on mouse down/up events. When the tests run they are unlikely to use anything but click events. So you may need to rethink your approach. Sorry I can’t be more helpful than this. If you run the tests with your code like this, I think you’ll see what I mean.

  function onClickHandle() {
  function onMouseDownHandle() {
    //setCurrentDataDisplay(   ;
1 Like

All your problem tests are on ones that involve clicking (#10 does too, but it expects no change, which it gets, so it passes), so my guess is that when the tests run, they are not able to click your buttons, since that’s what the tests are trying to do (the tests are finding the elements by id, then calling their .click() function).

It’s difficult to trace, but it looks like the only part of your code that is handling clicks is the two display/result divs and the Key() function. Everywhere else seems to be using various up/down events, so the mouse and keyboard work interactively and the calculator passes the eye test, but fails the computer testing since it relies on click events.

Personally, I think you need to simplify things considerably. You’ve got state, props, refs, context, and effects and it’s hard to follow. You only really need to track enough state to generate the current formula to evaluate (like 5 * - 5), from which you can then calculate and store a result (on =), clear, or extend and validate (make sure the next symbol is valid and append), etc. This can probably be done with one or two state variables either with classes or hooks. Regardless, to pass the tests you will have to use click events via the onClick attribute or the fCC tests will not be able to manipulate your calculator (that’s why all the error messages say expected 123 but got 0 or somesuch).

Jeremy. you are right, I have complicated this calculator quite a bit.

I wanted to handle the keyboard events, so that it would be extensible and reusable to other apps.

Also didn’t want this code to look like other FCC calculators, and so much so that it failed the tests.

I could notice that at least the tests did the operations when I made the change suggested by dlaub3

function onClickHandle () {
        setCurrentDataDisplay (;
        setPadStyle (inactiveStyle);

but even so the tests continue to fail.

I think what is happening is that react takes its time to render depending on the handling of the states, and the tests do not wait for the render to finish.

I will try to make some changes to get through the tests.

Thank you very much for your help, it has helped a lot.

That’s true, but with this change, only 8 of the tests passed when I checked. It could be the rendering time, but I still think your click() events are getting swallowed or ignored higher up from here because you calculator context does not handle clicks (IIRC).

1 Like

What happens is that I am using the mouse events together with the same treatment that I give to the keyboard events. To achieve this I just update the context. Then the hooks in charge of listening to this context in the next render will update the corresponding values.

All of this happens by trying to handle keyboard events in simple divs at the same time as mause events.

This results in that I always work a late render, or a delay event, today I will try to correct it, thank you very much for the help.

It has already been resolved, the help of both was very useful, it made me realize the delay of the event I was dealing with. That happened by using the context to save the event that occurred, then a hook that was listening to the context updated the content of the display through states.

All this allowed me to delay an event or a rendering, something that bugge testing did not consider.

My calculator is working correctly now. Thank you.

1 Like

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