b206ad72-e127-4ddf-98e5-979270588f0c

Committed 30 Dec 2024 01:30AM CUT coverage: 85.075% (-0.01%) from 85.088%

Build # b206ad72-e127-4ddf-98e5-979270588f0c

Build Type

Pull #5287

circleci

Committed by

web-flow

Commit Message

Bump swr from 2.2.5 to 2.3.0

Bumps [swr](https://github.com/vercel/swr) from 2.2.5 to 2.3.0.
- [Release notes](https://github.com/vercel/swr/releases)
- [Commits](https://github.com/vercel/swr/compare/v2.2.5...v2.3.0)

---
updated-dependencies:
- dependency-name: swr
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

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

Pull Request Pull Request #5287: Bump swr from 2.2.5 to 2.3.0

Run Details

2432 of 3561 branches covered (68.3%)

Branch coverage included in aggregate %.

16994 of 19273 relevant lines covered (88.18%)

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 / b206ad72-e127-4ddf-98e5-979270588f0c

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