tlfjar / childsupportcalculator Goto Github PK

Describe the bug
Arkansas' support chart, found in support.json, ends at 30,000.00 combined monthly income. Exceeding this causes the program to freeze rather than returning a warning of some sort. This may also be considered a feature request.

To Reproduce
Steps to reproduce the behavior:

1. Fill out form normally with income numbers that combined exceed 30,000.00.
2. Error gets thrown in dev console, and parts of the page freeze up, preventing further modification.

Expected behavior
No paragraph returned, but all values continue to allow changes. Ideally, a warning would be returned listing the maximum support amount on the chart plus a blurb that anything more is subject to a significant amount of judicial discretion.

Screenshots
N/A

Desktop (please complete the following information):

• OS: Windows 11
• Browser: chrome
• Version: latest as of date on this post

Additional context
I haven't implemented any sort of error handling or validation to the form, which is badly needed. Some users really want to include the "$" symbol when entering income values, for example, which causes problems as well.

Is your feature request related to a problem? Please describe.
Almost all logic is confined to a single file, making modifications of what are otherwise discrete calculated values more taxing than it has to be.

Describe the solution you'd like
Use one component to gather inputs, and other components to handle the calculation-heavy paragraph maker. Each paragraph could be a component of its own, with the proper paragraph component being called depending on the payor's income and number of children. These components would contain only the functions necessary for the paragraph they create.

It may also be worth using a "submit" button, so that the paragraph doesn't change as numbers are being added.

Describe alternatives you've considered

1. Leaving the template portion of the page where it is, and only move the calculations to separate files. This is less likely to break things.

2. Creating discrete components for each paragraph style as described in the original solution, but with a fourth component that does all of the universal calculations in one file. This would cut down on code repetition, which I assume is a good thing.

3. Leave logic in page and move the paragraph templates to discrete files. This would also cut down on repetition.

Option 2 and 3 would leave calculations in one place, so any changes to them that are used in all the paragraph varieties would not have to be repeated. To make that happen, option 2 is the most appealing to me, if nothing else but because there would be less scrolling needed to get to the snippets that need to be changed.

Option 1 is only helpful because it wouldn't require messing with the rather hacky solution I'm using to write the paragraph. It's readability as it stands is terrible and fixing it would be a chore. With that said, moving the templates away from the page file would give an opportunity to write them in a cleaner way.

Additional context
I'm figuring this out as I go, so let me know if this feature would actually make things worse or just offer no meaningful utility.