Exclude IRA rebates; add ability to show generic info about HEAR/HER #155
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
cypress/e2e/state-calculator.cy.ts
Outdated
There was a problem hiding this comment.
Does this test also ensure that something from the API is displayed too?
There was a problem hiding this comment.
Yeah, all the checks below are for API-sourced incentives.
## Description This excludes all federal non-tax-credit incentives that come from the API, and adds in these visually-distinct cards with less-specific info about HEAR rebates if the API response indicates the user is below 150% AMI. One slight difference from the design spec is that the description text is grey-500, rather than 400, which fails the a11y test for not having enough contrast with the yellow background. I can't even see the difference at a glance, so I think it's fine. (As a drive-by, I fixed a couple places where we had `gray` instead of `grey`.) Once we settle on copy, I'll start the translation workflow. We don't have any state-specific logic yet, but there's a clear place to add it once we figure out what exactly we want for each state. Some states will want us to show nothing at all (either because they don't want to commit to anything or because they already have actual HEAR programs represented in the API), some states may want semi-specific info in advance of rolling out actual programs, some may tell us they're going to exclude certain items, etc. All that can be built on this foundation. As background, I don't want to put this in the API because the kind of info we want for HEAR just doesn't fit within the current API shape: it's too vague and uncertain. I don't want to extend the API shape to encompass stuff like this because I think it's valuable, on principle, to hold the line that the API only returns concrete, actionable incentives that are certain, or close to certain, to be available. https://app.asana.com/0/1206661332626418/1206925887004341 ## Test Plan Cypress tests pass.
oyamauchi
force-pushed
the
owen.state-specific
branch
from
15402dc
to
34ee4e8
Compare
There was a problem hiding this comment.
The code LGTM! But, man the card is a lot harder to appreciate it on page. It is the Yellow on Yellow, that is rough to look at. Is it too late to consider an alternative? I know this is in alignment with the design, but it really make a diff seeing it on the page.
src/i18n/strings/es.ts
Outdated
| @@ -164,4 +164,15 @@ export const templates = { | |||
| sfc7214f623fe475d: `Selecciona la empresa a la que paga su factura de electricidad.`, | |||
| sfe16afc784bb9d76: `Tejado solar`, | |||
| sfe81d5d73a35a2cf: `Calcular`, | |||
| sb1ef6ac20f1ddfff: `Discount off an electric panel`, | |||
There was a problem hiding this comment.
Are these just placeholders as we wait for the translated strings? How do we usually manage translations?
There was a problem hiding this comment.
I was waiting until we got agreement on copy to request translations. This is just what happens if you run yarn strings:build without translations: the original string gets put in as a fallback. I'll wait until we get translations to land this.
…together from our rebate pages
Description
This excludes all federal non-tax-credit incentives that come from the
API, and adds in these visually-distinct cards with less-specific info
about HEAR rebates if the API response indicates the user is below
150% AMI.
One slight difference from the design spec is that the description
text is grey-500, rather than 400, which fails the a11y test for not
having enough contrast with the yellow background. I can't even see
the difference at a glance, so I think it's fine. (As a drive-by, I
fixed a couple places where we had
grayinstead ofgrey.)Once we settle on copy, I'll start the translation workflow.
We don't have any state-specific logic yet, but there's a clear place
to add it once we figure out what exactly we want for each state. Some
states will want us to show nothing at all (either because they don't
want to commit to anything or because they already have actual HEAR
programs represented in the API), some states may want semi-specific
info in advance of rolling out actual programs, some may tell us
they're going to exclude certain items, etc. All that can be built on
this foundation.
As background, I don't want to put this in the API because the kind of
info we want for HEAR just doesn't fit within the current API shape:
it's too vague and uncertain. I don't want to extend the API shape to
encompass stuff like this because I think it's valuable, on principle,
to hold the line that the API only returns concrete, actionable
incentives that are certain, or close to certain, to be available.
https://app.asana.com/0/1206661332626418/1206925887004341
Test Plan
Cypress tests pass.