#4994: Make links in Field descriptions clickable

[fregante]

1. Visit https://app.pixiebrix.com/activate?id=@pixies/content-management-demo
2. Click "Configure"

Before	After

Discussion

This is the lowest-level place I found. If you know of other parts that would benefit from linkification, let me know.

This change also applies to the page editor. Here it ignores any pre-existing links/dom:

An alternative solution with a broader impact would be to use a barebones "markdown" parser so we don't have to create JSX for this kind of content:

pixiebrix-extension/src/pageEditor/tabs/quickBar/QuickBarConfiguration.tsx

Lines 58 to 68 in 9dfc712

	<span>
	URL match patterns to show the menu item on. See{" "}
	<a
	href="https://developer.chrome.com/docs/extensions/mv2/match_patterns/"
	target="_blank"
	rel="noreferrer"
	>
	<code>match_patterns</code> Documentation
	</a>{" "}
	for examples.
	</span>

However this requires further discussion and research so I skipped it for now. We just need support for code and a, not the whole marked module.

Team Coordination

• This PR introduces a new library: double check it's MIT/Apache2/permissively licensed

Checklist

• Add tests
• Designate a primary reviewer: @BALEHOK

[fregante]

Hopefully in the future:

• Output React component sindresorhus/linkify-urls#38

[fregante]

No rel needed, see pixiebrix/eslint-config-pixiebrix#37

[codecov]

Codecov Report

Merging #4993 (9dfc712) into main (fc3d4a0) will increase coverage by 0.00%.
The diff coverage is 100.00%.

❗ Current head 9dfc712 differs from pull request most recent head cc20341. Consider uploading reports for the commit cc20341 to get more accurate results

@@           Coverage Diff           @@
##             main    #4993   +/-   ##
=======================================
  Coverage   59.16%   59.16%           
=======================================
  Files         964      965    +1     
  Lines       29077    29084    +7     
  Branches     5568     5569    +1     
=======================================
+ Hits        17202    17209    +7     
  Misses      11875    11875           

Impacted Files	Coverage Δ
src/components/LinkifiedString.tsx	100.00% <100.00%> (ø)
src/components/form/FieldTemplate.tsx	96.49% <100.00%> (+0.06%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[BALEHOK]

Nice!

[BALEHOK]

Let's sue regular snapshots:

1. that's consistent
2. the tests are easier to grasp
3. when you need to update the snapshots, you don't need to make the changes manually
4. you can always explore the snapshot file to see what is the expected output

[fregante]

when you need to update the snapshots, you don't need to make the changes manually

The point of snapshots is that they're automated, use jest --updateSnapshot

the tests are easier to grasp
you can always explore the snapshot file to see what is the expected output

Are you talking about .toMatchSnapshot?

The actual test file is indeed easier to scan, but then to see the result you have to find it in the external file. This is fine when there's a single test but it becomes hard to find which is which when there are multiple snapshots.

With inline snapshots the results is right here, it's like manual "expect x to exist" tests, except they're fully automated.

that's consistent

We're already using inline snapshots in many other tests, especially for smaller components.

[BALEHOK]

@fregante

when you need to update the snapshots

Pls disregard, I thought auto-update doesn't work for inline snapshots.

Are you talking about .toMatchSnapshot?

Yes.

We're already using inline snapshots in many other tests, especially for smaller components.

Personally, I prefer to have tests in one file and results in another file, always, regardless of the component size, so everyone on the team has the same knowledge, understanding, and expectations for reading and authoring the snapshot tests.
Let's not get into a long discussion though, the PR has been approved, leaving the final decision to you as the PR author.

[twschiller]

My two cents: I would prefer to use file-based snapshots for React components

Also, I've had problems with Jest failing to update the inline snapshots in files that use import {type Foo} from "foo" syntax

[fregante]

I've had problems with Jest failing to update the inline snapshots in files that use import {type Foo} from "foo" syntax

That's a temporary issue that has or will be fixed. I do agree however that sometimes they cause annoyances.

File-based snapshots are good to ensure large components don't change, but they make tests unreadable. There's no way for me to see what the expectations are by just looking at this file:

https://github.com/pixiebrix/pixiebrix-extension/blob/main/src/components/LinkifiedString.test.tsx

everyone on the team has the same knowledge, understanding, and expectations for reading and authoring the snapshot tests.

I don’t think inline snapshots are difficult to understand and are definitely easier to author than manually copy-pasting the results like in this case:

pixiebrix-extension/src/blocks/transformers/parseDate.test.ts

Lines 68 to 82 in 251b6d5

	expect(result).toEqual({
	utc: {
	iso8601: "2021-12-10T03:00:00.000Z",
	date: "12/10/2021",
	time: "3:00:00 AM",
	humanReadable: "Fri, 10 Dec 2021 03:00:00 GMT",
	epochMillis: 1_639_105_200_000,
	},
	local: {
	iso8601: "2021-12-09T22:00:00.000-05:00",
	date: "12/9/2021",
	time: "10:00:00 PM",
	humanReadable: "12/9/2021, 10:00:00 PM",
	},
	});

👆 this one was a prime example of when to use (automated) inline snapshots.

[github-actions]

No loom links were found in the first post. Please add one there if you'd like to it to appear on Slack.

Do not edit this comment manually.