Skip to content

Conversation

@darrensapalo
Copy link
Contributor

@darrensapalo darrensapalo commented Nov 13, 2025

Description

Groundwork for the TaxEstimateView component. Internal unstable build of TaxEstimateView.

Changes

  • New views and components related to tax estimation.

Out of scope

Blockers

How this has been tested?

Visual inspection with the demo-finguard app.

References

@darrensapalo darrensapalo changed the title darren/tax estimates Unstable experimental build for TaxEstimateView Nov 13, 2025
Comment on lines +59 to +61
<Span
size='md'
className={item.isDeduction ? 'Layer__tax-estimate__deduction-item' : ''}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Layer__tax-estimate__deduction-item is just adding padding - we can do that directly on the span without the class name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we do need it- because spans only have padding-block but not padding-inline (left-right).

Does it make sense to extend Span to have pb but also pi?

Comment on lines +77 to +82
<Heading size='md' className='Layer__tax-estimate__agi-total-amount'>
{convertNumberToCurrency(item.amount)}
</Heading>
</TooltipTrigger>
<TooltipContent>
<Span className='Layer__tax-estimate__tooltip' size='sm'>{item.formula}</Span>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Layer__tax-estimate__tooltip and Layer__tax-estimate__agi-total-amount are just for colors, I expect we can do that with properties on our text components.

I'm definitely okay with some shortcuts here, but this one feels like it might be even easier to use text props here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have properties on our TextStyleProps to determine colors.

src/views/TaxFiling/taxEstimate.scss

Image

I don't want to make design decisions for our buttons under crunch time, so I'd rather this be a specific class name that we later clean up (if we do decide to extend our Span component.

Comment on lines +59 to +61
<Span
size='md'
className={item.isDeduction ? 'Layer__tax-estimate__deduction-item' : ''}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we do need it- because spans only have padding-block but not padding-inline (left-right).

Does it make sense to extend Span to have pb but also pi?

Comment on lines +77 to +82
<Heading size='md' className='Layer__tax-estimate__agi-total-amount'>
{convertNumberToCurrency(item.amount)}
</Heading>
</TooltipTrigger>
<TooltipContent>
<Span className='Layer__tax-estimate__tooltip' size='sm'>{item.formula}</Span>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have properties on our TextStyleProps to determine colors.

src/views/TaxFiling/taxEstimate.scss

Image

I don't want to make design decisions for our buttons under crunch time, so I'd rather this be a specific class name that we later clean up (if we do decide to extend our Span component.

Comment on lines 39 to 41
.Layer__tax-estimate__deduction-item {
padding-left: var(--spacing-xl);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spans currently do not have padding-inline (left, right) and only support padding-block (top, bottom).

Understandably, spans are inline objects, so there is a case to be made that spans shouldn't have padding-inline because that seems weird. I don't want to encourage Span users to use padding-inline if this is a usually unexpected styling approach.

Maybe the better thing to do is wrap a Span with a container, and then have the container manage the padding instead. In terms of DOM structure optimization & also library size, fewer VStack and HStack might be a better preference. Those containers add up, or dare I say... stack. 👀

@@ -0,0 +1,34 @@
.Layer__tax-filing {
max-width: 1460px;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This magic number is the same magic number used for .Layer__view-header__content.

@darrensapalo darrensapalo marked this pull request as ready for review November 14, 2025 01:35
@greptile-apps
Copy link
Contributor

greptile-apps bot commented Nov 14, 2025

Greptile Overview

Greptile Summary

This PR introduces a new experimental TaxFilingView component that provides tax estimation and filing functionality. The implementation includes:

  • New tax filing view with tabs for Overview, Tax Estimates, Tax Payments, and Tax Profile
  • Collapsible detail sections for Adjusted Gross Income, Federal Taxes, and State Taxes
  • Reducer-based state management for form data
  • Enhanced View/ViewHeader components with headerActions prop support
  • Improved dropdown menu disabled state styling

Key Changes:

  • Added 15 new files in src/views/TaxFiling/ directory
  • Component follows existing patterns and uses colocated styles
  • Types properly use type declarations instead of interface for data objects per custom rules
  • Exported as unstable_TaxFilingView to indicate experimental status

Style Issues:

  • Uses padding-left instead of RTL-aware padding-inline-start in one location (violates RTL rule)
  • Uses 1px instead of 0.0625rem for border widths in one location (violates rem rule)

Code Quality:

  • Well-structured component hierarchy with proper separation of concerns
  • Good use of TypeScript types and proper prop interfaces
  • State management follows React best practices with useReducer
  • No logical errors or security concerns identified

Confidence Score: 4/5

  • This PR is safe to merge with minimal risk - it's experimental groundwork with no logical errors
  • Score reflects well-structured code with only minor style guideline violations. The experimental nature (unstable_ prefix) appropriately signals this is groundwork. No logical errors, security issues, or data integrity concerns found. The two style issues (RTL padding and px vs rem) are non-critical and easily addressable.
  • Pay attention to src/views/TaxFiling/taxEstimate.scss for style guideline compliance before stabilizing the feature

Important Files Changed

File Analysis

Filename Score Overview
src/views/TaxFiling/taxEstimate.scss 3/5 Styling file with padding violations (uses padding-left instead of RTL-aware properties), height in rem (good), but missing some rem conversions
src/views/TaxFiling/TaxEstimate.tsx 4/5 Main tax estimate component with good structure, uses type definitions correctly, properly imports colocated styles
src/views/TaxFiling/TaxFilingView.tsx 4/5 Main view component with good state management, proper reducer usage, and well-organized tab structure
src/views/TaxFiling/AdjustedGrossIncomeSection.tsx 4/5 Table-based section component with tooltip support, good structure but could simplify nested ternaries
src/views/TaxFiling/FederalTaxesSection.tsx 4/5 Similar structure to AGI section, handles rates vs amounts correctly, complex nested ternaries
src/views/TaxFiling/StateTaxesSection.tsx 4/5 Duplicate of FederalTaxesSection with minor naming changes, potential for code reuse

Sequence Diagram

sequenceDiagram
    participant User
    participant TaxFilingView
    participant Toggle
    participant TaxEstimate
    participant Sections
    participant Store
    
    User->>TaxFilingView: Load View
    TaxFilingView->>Store: Initialize with reducer
    TaxFilingView->>Toggle: Render tabs
    
    alt User not onboarded
        TaxFilingView->>TaxFilingView: setActiveTab('tax-profile')
        User->>TaxFilingView: Fill profile form
        User->>TaxFilingView: Click Save
        TaxFilingView->>Store: Dispatch profile actions
        TaxFilingView->>TaxFilingView: setIsOnboarded(true)
        TaxFilingView->>TaxFilingView: setActiveTab('tax-estimates')
    end
    
    User->>Toggle: Select 'tax-estimates' tab
    Toggle->>TaxFilingView: onChange
    TaxFilingView->>TaxEstimate: Render with defaults
    TaxEstimate->>Sections: Render AGI, Federal, State sections
    
    User->>Sections: Click section to expand
    Sections->>TaxFilingView: onExpandedChange(true)
    TaxFilingView->>TaxFilingView: Update expansion state
    TaxFilingView->>Sections: Re-render with expanded=true
    Sections->>User: Show detailed breakdown
    
    User->>TaxEstimate: Click tax amount
    TaxEstimate->>TaxFilingView: onFederalTaxesOwedClick
    TaxFilingView->>TaxFilingView: setActiveTab, expand section
    TaxFilingView->>Sections: Re-render expanded section
Loading

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

22 files reviewed, 2 comments

Edit Code Review Agent Settings | Greptile

Comment on lines +20 to +22
width: 15rem;
border-right: 1px solid var(--color-base-300);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

style: Use rem instead of px for the border-right width

Suggested change
width: 15rem;
border-right: 1px solid var(--color-base-300);
}
.Layer__tax-estimate__overview-total {
width: 15rem;
border-right: 0.0625rem solid var(--color-base-300);
}

Context Used: Rule from dashboard - When writing CSS styles, prefer rem instead of px usage. (source)

Prompt To Fix With AI
This is a comment left during a code review.
Path: src/views/TaxFiling/taxEstimate.scss
Line: 20:22

Comment:
**style:** Use `rem` instead of `px` for the border-right width

```suggestion
.Layer__tax-estimate__overview-total {
  width: 15rem;
  border-right: 0.0625rem solid var(--color-base-300);
}
```

**Context Used:** Rule from `dashboard` - When writing CSS styles, prefer `rem` instead of `px` usage. ([source](https://app.greptile.com/review/custom-context?memory=2d1130c2-7a17-4663-ac54-76dc142598ad))

How can I resolve this? If you propose a fix, please make it concise.

@darrensapalo
Copy link
Contributor Author

@sarahraines Before reviewing this PR please check out the hooks first #1002 (integration branch) which would merge into this feature branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants