-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix: ArgumentError (MAYBE-MARKETING-2D) #221
base: main
Are you sure you want to change the base?
Conversation
/revise this system is meant for casting, not validation. Would be better to set a minimum value of 0 when the corresponding tool presenter calls for it. And ideally make it impossible to submit invalid values (in this case negative ones) from the UI. |
The current implementation of ToolFloat mixes concerns by handling both type casting and validation. Following the single responsibility principle, we should separate these concerns. The type casting system should focus solely on converting input values to the correct type, while validation should be handled at the presenter level and prevented at the UI level. Changes made:
This change:
The validation of minimum and maximum values should now be handled:
Updated files:
|
@josefarias Is the change Revise made correct? |
@Shpigford I don't think the proposed solution is correct. I'm lacking some context here but I'm guessing a negative number got passed to some tool that doesn't support negative numbers. If so, I think the ideal solution would be a front-end validation so the input can't be negative. That'd usually be enough but given that we have a way to set a floor/min-value for tool attributes, we should leverage that and set e.g. I wonder if this'll work... /revise use the comment I've written above to refine your solution. |
Based on the comment, the solution should focus on:
The CompoundInterestCalculator is a good example where we should add these constraints, as financial calculations typically don't work with negative values for inputs like initial investment, contributions, and years. I'm updating the CompoundInterestCalculator presenter first since it's the most obvious candidate. We'll add min: 0.0 to all numeric attributes that shouldn't be negative, while keeping existing constraints like max values. Once we see which specific tool is causing the issue, we can apply similar changes to other presenters. Updated files:
|
That looks significantly better! |
/revise Looking good. I noticed this specifically happening in the Early Mortgage Payoff Calculator. |
but it does look like it misinterpreted my (admittedly unclear) comment about casting and not validating. Some minor intervention is needed here before merging. |
Given the comment - "Looking good. I noticed this specifically happening in the Early Mortgage Payoff Calculator." - I can now provide a more targeted response. Looking at the Early Mortgage Payoff Calculator presenter and its form, I notice that while there is a frontend validation for Currently, only The changes:
This provides both frontend and backend protection against negative values while following the same pattern established in other calculator tools. add non-negative constraints to early mortgage payoff calculator fields<BEGIN FILE: app/presenters/tool/presenter/early_mortgage_payoff_calculator.rb> attribute :interest_rate, :tool_percentage, default: 0.0, min: 0.0 attribute :original_term, :tool_integer, default: 30, min: 0.0 def blank? def mortgage_rate_30 def interest_savings def total_interest
end def total_interest_with_extra_payments
end def total_principal_and_interest def total_principal_and_interest_with_extra_payments def original_payoff_date def new_payoff_date def savings_account_balance
end def net_difference def time_saved def net_difference_class def net_difference_comment def net_difference_comment_class private
end <BEGIN FILE: app/views/tools/widgets/forms/_early_mortgage_payoff_calculator.html.erb>
<%= form.unit_field :loan_amount, label: "Loan amount", value: tool.loan_amount, unit_symbol: "$", data: { controller: "autonumeric", auto_submit_form_target: "auto" }, input_html: { min: 0 } %>
<%= form.unit_field :original_term, label: "Original loan term", value: tool.original_term, label_right: "years", data: { controller: "autonumeric", autonumeric_options_value: { decimalPlaces: 0 }, auto_submit_form_target: "auto" }, input_html: { min: 0 } %>
<%= form.unit_field :years_left, label: "Years left on loan", value: tool.years_left, label_right: "years", data: { controller: "autonumeric", autonumeric_options_value: { decimalPlaces: 0 }, auto_submit_form_target: "auto" }, input_html: { min: 0 } %>
<%= form.unit_field :interest_rate, label: "Interest rate", value: tool.mortgage_rate_30
|
Based on the codebase, I'm implementing a solution to handle non-negative value validation in the ToolFloat class more gracefully. The error occurs when a value less than 0 is provided to a field that should only accept non-negative numbers.
Key changes made:
non_negative
parameter to the ToolFloat initializer to explicitly declare when a field should only accept non-negative valuesThis change maintains backward compatibility with existing code while adding the ability to explicitly declare non-negative requirements. The solution is more flexible than hard-coding a minimum value of 0, as it allows for both negative-allowed and non-negative fields to coexist in the system.
Tip
You can make revisions or ask questions of Revise.dev by using
/revise
in any comment or review!/revise Add a comment above the method to explain why we're making this change.
/revise Why did you choose to make this change specifically?