Calculations and input

[nickslick03]

Big things:

• The input component has changed from it's value prop being a (string | number | boolean) to a generic, (T | null), where T means that the input is valid and null means the input is invalid. This change is also reflected in the persistentState hook, which returns the actual value and not the string representation. This means when using the context values throughout the app, null checking is needed, but is better then the hodge podge checking I was doing previously.
• The inputs now have a invalid message. They currently show by using display: hidden; which can widen the meal info inner container a bit. Using visibility: invisible; fixes this but adds uneven spacing between the inputs. let me know what you think of this.
• The getMealTotal now takes an array of all the meal listings to search from. You'll probably have to clear your localStorage. Let me know what you think.

[cdrice26]

Okay, I cleared localStorage and ran the app, and for the most part it works well, though there were a few issues:

• The starting balance input doesn't seem to have an error message in Safari, it still allows me to input letters without showing the message. It does, however, hide the rest of the UI until you change it back to a number. This may just be a really poor design choice on Apple's part that we can't do anything about, but I thought I'd mention it just in case you have any ideas.
• Additionally, I noticed this a while ago but keep forgetting to bring it up, the dot character doesn't show up on the iPhone keyboard for number inputs so you can't type decimals. I fixed this particular issue with my latest commit.
• The results bar now displays the starting balance for the $ Extra/Over value
• I got a really weird issue where I made a custom meal and edited the price multiple times and from the first edit on it kept setting the actual price to a value of slightly less than half of what I entered. The incorrect value displayed everywhere except in the custom meal editor, where the correct value continued to be displayed. After clearing localStorage a second time I could not reproduce this issue. Not sure if this is something we need to look into or if my browser was just out of whack.

[nickslick03]

• I don't have a Mac so I can't replicate the error, so I built the commit I just made to gh-pages and tried it on my iPhone and there is an invalid input message on the starting balance. Maybe try some console logging to see if there's a macOS Safari-specific issue. I'd start around line 93 in Input.tsx to see what newValue is. That's weird that it only happens on Safari.
• 👍good catch
• fixed the resultsBar glitch and moved results and resultsBar memos up to App.tsx to avoid redundancy.
• I'm not seeing that issue, so we'll keep an eye out ig

[cdrice26]

Okay so I'm actually seeing the error message now in Safari, the only exception being if the starting balance in localStorage is null when the page is loaded and then it won't show up until you type a number into it and then mess it up because the value just stays null. I just discovered that the weird price issue is just because I had the dining dollars discount turned on and it automatically adjusts the prices. If you want to take a look at the issue of it not seeing an initial null, feel free, otherwise I think it's good to merge.

[cdrice26]

Although the issue of the error message on the starting balance not showing initially may be more of a feature than a bug...I would be kind of annoyed if I started up an app and it was already giving me error messages, haha. But it is misleading to be able to type nonsense into it and have it still be null without sending an error because no state has been updated. This is not an issue in non-Safari browsers since they won't even let you input non-numbers but for some reason Safari does.

[nickslick03]

Firstly, I aplogize for not creating a bunch of different inputs, but I'm honesty too lazy and too tired to do that. The fix was to use the onInput event (thanks chatGPT) which fires for any change, and it seems to work. I also made the elements uncontrolled since the outside state handles it pretty much. The input behemoth lives on.

[cdrice26]

Oh yes I forgot about the onInput event, I think that's actually considered the better event to use for capturing input from a so we're good there. Yes, it's still a behemoth component, but it works and so I think we're good at this point. I'm going to merge.