a07ded7b-a5de-4b90-bbea-5284549fabc6

Committed 16 Dec 2024 01:18AM CUT coverage: 85.088% (+0.009%) from 85.079%

Build # a07ded7b-a5de-4b90-bbea-5284549fabc6

Build Type

Pull #5261

circleci

Committed by

web-flow

Commit Message

Bump phonenumbers from 8.13.51 to 8.13.52

Bumps [phonenumbers](https://github.com/daviddrysdale/python-phonenumbers) from 8.13.51 to 8.13.52.
- [Commits](https://github.com/daviddrysdale/python-phonenumbers/compare/v8.13.51...v8.13.52)

---
updated-dependencies:
- dependency-name: phonenumbers
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

Pull Request Pull Request #5261: Bump phonenumbers from 8.13.51 to 8.13.52

Run Details

2433 of 3561 branches covered (68.32%)

Branch coverage included in aggregate %.

16996 of 19273 relevant lines covered (88.19%)

9.92 hits per line

Source File
Press 'n' to go to next uncovered line, 'b' for previous

0.0

/frontend/src/components/Localized.tsx

// Imports of `Localized` from @fluent/react are forbidden because the component
// in this file should be used instead, but of course this component can use it
// just fine:
// eslint-disable-next-line no-restricted-imports
import { LocalizedProps, Localized as OriginalLocalized } from "@fluent/react";
import { cloneElement, isValidElement, useEffect, useState } from "react";
import { useL10n } from "../hooks/l10n";

/**
 * Wraps @fluent/react's Localized to be consistent between prerender and first render
 *
 * React will throw a tantrum if the HTML rendered during the build differs from
 * the DOM rendered by React when running client-side. However, at build-time we
 * don't yet know the user's locale. Thus, if we render strings in the user's
 * locale on the first client-side render, we'll make React unhappy, and who
 * wants that?
 *
 * To work around this, the useL10n hook makes sure that the English strings are
 * rendered when both prerendering and doing the first client-side render, and
 * only after that use the language that aligns with the user's preferences.
 * Thus, while pre-rendering and during the first client-side render, we call
 * out to that hook.
 *
 * This means tags embedded in the localised strings won't get added initially,
 * but since that's only for SEO and the initial render, that's acceptable.
 */
export const Localized = (props: LocalizedProps) => {
  const [isPrerendering, setIsPrerendering] = useState(true);
  const l10n = useL10n();

  useEffect(() => {
    setIsPrerendering(false);
  }, []);

  if (isPrerendering) {
    // `useL10n` makes sure that this is a prerenderable string
    return isValidElement(props.children) ? (
      cloneElement(
        props.children,
        {},
        <>{l10n.getString(props.id, props.vars)}</>,
      )
    ) : (
      <>{l10n.getString(props.id, props.vars)}</>
    );
  }

  return <OriginalLocalized {...props} />;
};

1	// Imports of `Localized` from @fluent/react are forbidden because the component
2	// in this file should be used instead, but of course this component can use it
3	// just fine:
4	// eslint-disable-next-line no-restricted-imports
5	import { LocalizedProps, Localized as OriginalLocalized } from "@fluent/react";	×
6	import { cloneElement, isValidElement, useEffect, useState } from "react";	×
7	import { useL10n } from "../hooks/l10n";	×
8
9	/**
10	* Wraps @fluent/react's Localized to be consistent between prerender and first render
11	*
12	* React will throw a tantrum if the HTML rendered during the build differs from
13	* the DOM rendered by React when running client-side. However, at build-time we
14	* don't yet know the user's locale. Thus, if we render strings in the user's
15	* locale on the first client-side render, we'll make React unhappy, and who
16	* wants that?
17	*
18	* To work around this, the useL10n hook makes sure that the English strings are
19	* rendered when both prerendering and doing the first client-side render, and
20	* only after that use the language that aligns with the user's preferences.
21	* Thus, while pre-rendering and during the first client-side render, we call
22	* out to that hook.
23	*
24	* This means tags embedded in the localised strings won't get added initially,
25	* but since that's only for SEO and the initial render, that's acceptable.
26	*/
27	export const Localized = (props: LocalizedProps) => {	×
28	const [isPrerendering, setIsPrerendering] = useState(true);	×
29	const l10n = useL10n();	×
30
31	useEffect(() => {	×
32	setIsPrerendering(false);	×
33	}, []);
34
35	if (isPrerendering) {	×
36	// `useL10n` makes sure that this is a prerenderable string
37	return isValidElement(props.children) ? (
38	cloneElement(	×
39	props.children,
40	{},
41	<>{l10n.getString(props.id, props.vars)}</>,
42	)
43	) : (
44	<>{l10n.getString(props.id, props.vars)}</>
45	);
46	}
47
48	return <OriginalLocalized {...props} />;
49	};

mozilla / fx-private-relay / a07ded7b-a5de-4b90-bbea-5284549fabc6

Source File Press 'n' to go to next uncovered line, 'b' for previous

Source File
Press 'n' to go to next uncovered line, 'b' for previous