I made a JS Calculator and I’m pretty sure it satisfies all the user stories but it won’t pass the tests. I think it’s because I don’t allow the user’s expression to chain operators - instead it immediately evaluates the prior expression and applies the new operator to the result
It’s hard to explain so here are the links to my calculator and the github repo if you wanna see the code
The sample project on codepen would add it all to the expression and not evaluate anything until ‘=’ is pressed
My calculator, when the second ‘+’ is pressed will evaluate the 2 + 3, and a new expression is started on the result, so the new expression would be ‘5+’. Then when the 4 is pressed the expression updates to ‘5+4’.
I think this immediate execution thing keeps the tests from passing even tho it functions according to the user stories
Was wondering if I could get a sympathy pass
Would love any feedback / bug reports, spent alot of time on this sucker
I think the problem might be that I store the user’s input numbers as strings instead of as numbers?
The ‘clear’ button test fails (I think) because the test expects the calculator to display 0 and mine displays “0”?
But the user stories don’t say which data type you have to store or display the numbers as. Going through the tests my calculator is failing, when I perform the test manually it performs exactly the way the user story describes with immediate execution logic.
I’ll have to come back to it tho, I’ve hit pause on learning node for too long while working on this.
I have always wished I was able to give myself (good) haircuts!
You are 100% right. When I started working on this I peeped the sample project’s regex hell and made my own highest-priority user story of not doing it that way. Probably shouldn’t prioritize avoiding something I could def use some practice with.
But I’m still convinced the tests have some specificities that aren’t defined in the user stories that are keeping my calculator from passing. But I’m also convinced I’m very tired and could be completely and embarrassingly wrong.
Random question tho, is the eval() method not dangerous in this application because I’m restricting the input characters to just numbers and a few symbols? I had nightmares last night of hackers crashing the github pages server because of my calculator, woke up in a cold sweat
Displaying, writing or printing is a symbolic representation. JS can work on numbers as a data type, but the data type used for visually representing numbers are strings, or characters really (which internally is just numbers, i.e. character encoding). The page is just a text document. It doesn’t contain numbers, only symbols.
You perform math on number types and display them using string types.
Random question tho, is the eval() method not dangerous in this application because I’m restricting the input characters to just numbers and a few symbols?
Yes, it is dangerous. In a real world app you would want to come up with a better solution. But that would make this project too difficult. In reality, I’m sure there are libraries out there that can handle this.
I had nightmares last night of hackers crashing the github pages server because of my calculator, woke up in a cold sweat
I’m no security expert, but I’m not sure how that would happen. I assume that the gitpages server is insulated from the code it is serving. At best they could wreak havoc on your little calculator app. I think they could disrupt that instance and slow down the server. But since it is just a static page, I don’t know what they could do any real damage in this case.
There’s no risk to using eval() in this context purely on the client side as you’re not sending data to a server so code injection isn’t possible, the input values of a calculator wouldn’t allow for it anyway,
Avoid using eval for this though I used it on my calculator and the performance is rubbish
Sure. I just know that this has been solved with mapping the buttons. And that would be a typical way to solve this. It is a very common practice in React.
Yeah, I’m not seeing why that wouldn’t work. I don’t like using random values for keys, but I don’t think that would cause the problem and if you are doing it outside a component (therefore not being rerun with different values) then it shouldn’t matter anyway - still, why not use the id?
It’s the way you are using nanoid. When I tested the mapped buttons with a fixed key (like the id) it passed the tests. If you move the object arrays out of the component and create a key property using nanoid it passes as well.
You’re totally right, why am I using nanoid? Totally unnecessary, probably just blindly repeating a tutorial I was doing at the time, where it made sense.
Well, there are cases where the mapped data doesn’t contain unique values so you need to generate it, and using an uuid is a good way to make sure it is unique. But in this case, as you are in control of the data and can add whatever you want using something simpler for the keys does make sense.
I see a lot of people use some kind of random generator for keys. Just to reiterate, it is fine if it happens once, but React is counting on those keys to be the same each time. If you throw a random key on there, it’s fine as long as it doesn’t change. But if the data has something unique to each element already, itls better to just use that. Butlike I said, I’ve seen that mistake a lot, even in tutorials.