Add gas utility selector #197
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## Links - https://app.asana.com/0/1208668890181682/1208886892124341 ## Description - Show the gas utility selector if the `/utilities` call returns a response with the `gas_utilities` key present. This is the way I came up with for the API to indicate whether the choice of gas utility matters: key is present means yes, key is absent means no. If the key is present but there are no gas utilities, we still show the selector to offer the choice of "no gas service" vs. "other", which is significant in the Mass Save case. - The selector always has three items at the bottom, after any real utilities: "Delivered propane or fuel oil", "No gas service", and "Other". The former two behave exactly the same behind the scenes, but are intended to reduce confusion: users may not know that we mean natural/methane gas pipeline service when we say "gas service" or "gas utility". - I had to add the `previousResponse` field to FetchState's loading state, so that the gas utility selector can stay visible and populated if you enter a new zip code. Otherwise, the selector would disappear while the `/utilities` call was pending, and it would look janky. As implemented, when you enter a zip code in MA and the `/utilities` call completes, the gas utility selector just pops in. This is pretty disruptive to the rest of the form in the two-column view, because all the other fields reposition --- they're in the same tabbing order, but ones that were on the left are now on the right and vice versa. It's not so bad in one-column view. I think this is tolerable for now, especially since the selector will only appear for MA zip codes. But it may be worth a rethink. ## Test Plan Add `api-host` attribute to the element on index.html to hit my local API server (so gas utilities are returned). Enter zip codes in MA to see the gas selector pop in, and make sure the options make sense. E.g. 02130 (Boston; has Eversource) and 01011 (middle of nowhere; has no gas). Enter one MA zip code, then another; make sure the gas selector stays visible throughout. Then enter a non-MA zip code; make sure the selector disappears once the new location's electric utilities are populated. Submit the form with the various gas options selected. Use network inspector to check the `gas_utility` param sent to the API. (Currently the API's response won't change based on it.) It should be `none` if "delivered fuels" or "no gas service" is selected, absent if "other" is selected, and a utility ID if a real gas utility is selected.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Two Spanish strings are missing translations; if reviewers are OK with the English, I'll take care of that. |
veekas
reviewed
Dec 11, 2024
Comment on lines
+209
to
+210
| sb2d056e8d2ea5bc5: `Delivered propane or fuel oil`, | ||
| s52d768131ca697d4: `No gas service`, |
There was a problem hiding this comment.
was this supposed to be en español?
veekas
reviewed
Dec 11, 2024
| <Select | ||
| id="gas_utility" | ||
| labelText={msg('Gas Utility', { desc: 'as in utility company' })} | ||
| tooltipText={msg('Choose the company you pay your gas bill to.')} |
There was a problem hiding this comment.
(no change required) "to which you pay your gas bill" if probably more grammatically correct but also overly formal, hmmm...
veekas
reviewed
Dec 11, 2024
Comment on lines
+789
to
+794
| <trans-unit id="sb2d056e8d2ea5bc5"> | ||
| <source>Delivered propane or fuel oil</source> | ||
| </trans-unit> | ||
| <trans-unit id="s52d768131ca697d4"> | ||
| <source>No gas service</source> | ||
| </trans-unit> |
There was a problem hiding this comment.
are you waiting on translations for this?
veekas
approved these changes
Dec 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Links
Description
Show the gas utility selector if the
/utilitiescall returns aresponse with the
gas_utilitieskey present. This is the way Icame up with for the API to indicate whether the choice of gas
utility matters: key is present means yes, key is absent means no.
If the key is present but there are no gas utilities, we still show
the selector to offer the choice of "no gas service" vs. "other",
which is significant in the Mass Save case.
The selector always has three items at the bottom, after any real
utilities: "Delivered propane or fuel oil", "No gas service", and
"Other". The former two behave exactly the same behind the scenes,
but are intended to reduce confusion: users may not know that we
mean natural/methane gas pipeline service when we say "gas service"
or "gas utility".
I had to add the
previousResponsefield to FetchState's loadingstate, so that the gas utility selector can stay visible and
populated if you enter a new zip code. Otherwise, the selector would
disappear while the
/utilitiescall was pending, and it would lookjanky.
As implemented, when you enter a zip code in MA and the
/utilitiescall completes, the gas utility selector just pops in. This is pretty
disruptive to the rest of the form in the two-column view, because all
the other fields reposition --- they're in the same tabbing order, but
ones that were on the left are now on the right and vice versa. It's
not so bad in one-column view. I think this is tolerable for now,
especially since the selector will only appear for MA zip codes. But
it may be worth a rethink.
Test Plan
Add
api-hostattribute to the element on index.html to hit my localAPI server (so gas utilities are returned).
Enter zip codes in MA to see the gas selector pop in, and make sure
the options make sense. E.g. 02130 (Boston; has Eversource) and 01011
(middle of nowhere; has no gas).
Enter one MA zip code, then another; make sure the gas selector stays
visible throughout. Then enter a non-MA zip code; make sure the
selector disappears once the new location's electric utilities are
populated.
Submit the form with the various gas options selected. Use network
inspector to check the
gas_utilityparam sent to the API. (Currentlythe API's response won't change based on it.) It should be
noneif"delivered fuels" or "no gas service" is selected, absent if "other"
is selected, and a utility ID if a real gas utility is selected.