Fix types, CSS import in frontend #5257
Conversation
This applies the same styles, but adds some spaces in the combined CSS. This rule: height:calc(var(--g)*1px) Becomes this rule: height:calc(var(--g) * 1px) That's the same CSS rule, but it does cause a hash change from 58e1c80c0e503be3.css to 1b1c275d4655b992.css.
| @@ -13,7 +13,7 @@ const mockedUseInboundContact = useInboundContact as jest.MockedFunction< | |||
| >; | |||
|
|
|||
| export function getMockInboundContact( | |||
| inboundContact: Partial<InboundContact> | |||
| inboundContact: Partial<InboundContact> | undefined, | |||
There was a problem hiding this comment.
question (non-blocking): Why do we explicitly accept undefined data type here, and then explicitly pass undefined to this function? I also don't understand how this worked before where the code called getMockInboundContact() while this function definition seems to require an inboundContact parameter?
There was a problem hiding this comment.
FYI this is what GitHub Copilot said:
The selection modifies the function getMockInboundContact to accept an additional data type, undefined, as a valid input for its inboundContact parameter. This change allows the function to be called without providing an argument, which is why the code now explicitly passes undefined when calling getMockInboundContact.
Previously, the code called getMockInboundContact() without any argument, which was possible because TypeScript allowed calling the function with an argument that was a partial InboundContact. However, with the updated type definition, the function now explicitly permits undefined, ensuring the function call remains valid even when no argument or an undefined argument is provided.
This change enhances the function's flexibility by allowing it to handle cases where the inboundContact parameter might be undefined, thereby preventing potential runtime errors.
| @@ -7,7 +7,7 @@ import { | |||
| } from "react"; | |||
| import Link from "next/link"; | |||
| import { ToastContainer, Slide } from "react-toastify"; | |||
| import "react-toastify/scss/main.scss"; | |||
| import "react-toastify/dist/ReactToastify.css"; | |||
There was a problem hiding this comment.
praise: ooo, this might also fix the CSS for the react-toastify 11.0.2 update.
| if (typeof allEntries[1].content !== "string") { | ||
| return; | ||
| } |
There was a problem hiding this comment.
TIL (via Copilot):
The if (typeof ...) { return; } block is not strictly necessary if the expect(typeof ...).toBe("string") call already ensures that allEntries[1].content is a string. However, the if block provides a safeguard to exit the function early if the type check fails, preventing any further execution that relies on the assumption that allEntries[1].content is a string. This can be useful to avoid runtime errors and make the test more robust.
|
Yup. I rebased the react-toastify branch on this one and the build error is fixed AND the styling looks right. |
When attempting to fix PR #5248, I found several typescript errors, and continued to get style warnings. This PR fixes those errors, most of which are in test code.
next.config.jstonext.config.ts, pass type checkingfxaFlowTracker.test.tsto use a number for the time parameter instead of a string, matching the codeimport "react-toastify/dist/ReactToastify.css", to avoid dart sass warnings. This has the same declarations but with some additional space, which caused the CSS hash to change.How to test:
cd frontendnpx tsc --noEmitruns with no warnings or errorsnpm run testruns with all tests passing