Support geoPath.digits(n) in geo projection components

[kachkaev]

When @visx/geo generates an SVG, paths end up containing more than 10 fractional digits. This increases page download size but is not practically useful. Fractional digits are often ‘random’, which means that transport-level compression cannot be very efficient for them.

Here is an example: https://airbnb.io/visx/geo-custom

It turns out that d3-geo supports path.digits(n) since version 3.1.0 (see d3/d3-geo#272 for context). It’d be nice to add support for digits in @visx/geo, similar to how it’s already done for pointRadius:

  <CustomProjection<FeatureShape>
    {...miscProps}
    pointRadius={2}
+   digits={3}
  >

The result would be a much smaller SVG:

-<path d="M365.0728966344956,172.6175701076138L364.8094078304068,172.92693679404636L364.47832959211263,172.75727516334257ZM369.92342393578775,172.58797232220107L369.90552269562437..." fill="#f4448b" stroke="#252b7e" stroke-width="0.5" class="jsx-296077636"></path>
+<path d="M365.072,172.617.809,172.926.478,172.757.923,172.587.905..." fill="#f4448b" stroke="#252b7e" stroke-width="0.5" class="jsx-296077636"></path>

---

Here is the file we’ll need to change:

visx/packages/visx-geo/src/projections/Projection.tsx

Lines 150 to 152 in ca38100

	const path = geoPath().projection(currProjection);
	if (pointRadius) path.pointRadius(pointRadius);

  const path = geoPath().projection(currProjection);

+ if (digits) path.pointRadius(digits);
  if (pointRadius) path.pointRadius(pointRadius);

We’ll also need to bump d3-geo from ^1.11.3 to ^3.1.0 for the new prop to work. Although d3-geo@3 depends on d3-array@2.5.0 - 3, this change may be blocked by #1267.

WDYT folks?

[kachkaev]

@williaster would you be willing to review a PR if I manage to get this task done in a few days? I guess I’ll need to add d3-geo to @visx/vendor but I guess it will be similar to #1678.

[williaster]

@kachkaev thanks for opening the issue with such great details. I'd be happy to review the change 👀 and get it in if you'd like to take it on 🙏

You are 100% correct about adding @visx/geo to @visx/vendor because it an ESM-only package and therefore would break our dual CJS / ESM exports. We really tried to make this simple for contributors, so hopefully all you need to do to bump the package is to:

• imitate https://github.com/airbnb/visx/pull/1678/files#diff-c9c1a2ad4e0114d3f318e276d111e033cd713f2ffcc33b8f8e098a8213703d7e with the new version of @visx/geo to add it to @visx/vendor
• change the d3-geo dep in @visx/geo to @visx/vendor
• update all references to d3-geo inside @visx/geo to @visx/vendor/d3-geo

lmk if you have any questions along the way – here or on a new PR

[kachkaev]

Great, thanks for your reply and for the hints! I’ll try to produce something by the end of this week if things go as planned 🤞

[kachkaev]

👋 @williaster! I have started a PR in #1767. The description is missing – feel free to help me with it if it’s quick for you. Apart from that, I seem to have produced the diff that works as expected. Happy to do more iterations on this PR, it’d be just great to get some initial feedback from you or your colleagues. The DX was neat, nice setup!

[williaster]

Amazing! I'll take a look asap today/tomorrow