Skip to content
This repository has been archived by the owner on Oct 1, 2024. It is now read-only.

sewing-kit-koa now checks for matching locales #1199

Merged
merged 1 commit into from
Nov 29, 2019

Conversation

GoodForOneFare
Copy link
Member

Description

When provided with manifests containing a locale attribute, sewing-kit-koa will now attempt to match a user request to a set of assets with that locale's translations embedded into its JavaScript.

This is a companion to the react-i18n PR that supports per-locale builds: #1197. The advantages of this are:

  • Bundlers like webpack don't get bloated with metadata about where to find async translations
  • Users don't have to download multiple sets of translations

Type of change

  • @shopify/sewing-kit-koa Minor: New feature (non-breaking change which adds functionality)

Checklist

  • I have added a changelog entry, prefixed by the type of change noted above

@GoodForOneFare GoodForOneFare changed the title sewing-kit-koa now checks for matching locales (optional!) sewing-kit-koa now checks for matching locales Nov 28, 2019
@GoodForOneFare GoodForOneFare marked this pull request as ready for review November 28, 2019 13:25
Copy link
Contributor

@marutypes marutypes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good to me, I had a few small nits and questions.

I'm also curious of the performance impact on the middleware itself (ever since that one time we accidentally made the sewing_kit equivalent way slower I've been a bit more paranoid about making these thing slow). I'd expect it would only add a few ms, but on an app like web with many languages we might want to be aware of how it changes, especially once there are 100+. Do we have numbers or anything for that?

packages/sewing-kit-koa/src/manifests.ts Outdated Show resolved Hide resolved
packages/sewing-kit-koa/src/manifests.ts Outdated Show resolved Hide resolved
packages/sewing-kit-koa/src/manifests.ts Outdated Show resolved Hide resolved
packages/sewing-kit-koa/src/manifests.ts Outdated Show resolved Hide resolved
acc: Map<string, ConsolidatedManifest>,
manifest: Manifest,
) {
const locales = manifest.identifier!.locales;
Copy link
Contributor

@marutypes marutypes Nov 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is identifier really optional? If not why don't we change the type (it's from this library isn't it?) if so, we should maybe do an assertion above with a nice error message if it's not there?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's optional for now because identifier's presence depends on an unreleased version of sewing-kit 😅

The mandatory part can come 🔜 🤞

export default class Assets {
assetPrefix: string;
userAgent?: string;
manifestPath: string;
private manifests: Manifests;
private resolvedManifestEntry?: Manifest;

constructor({assetPrefix, userAgent, manifestPath}: Options) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that we create one instance of this per request is there a reason we don't add locale to the class itself? Then we could remove the params all over the place for locale and just use the class attribute. Feels weird that we have a mix of params and class attributes for things that are per request.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yah, this is nasty ☹️ It's an artefact of how userAgent is available when the middleware creates Assets, but our apps tend to fetch locale info via GraphQL.

Locales are a niche feature right now, and I figure it's better to just add this verbose version of things before we put any more work into the API.

@GoodForOneFare
Copy link
Member Author

but on an app like web with many languages we might want to be aware of how it changes, especially once there are 100+. Do we have numbers or anything for that?

The cost is all up front: read a larger manifest on first request, and sort it into buckets. For every other request:

  • There's one extra map operation to see if the user's locale exists
  • For locale / no locale flows, exactly the same number of browser checks are performed as before

So it feels to me like the runtime cost is one extra map access and maybe an extra function call ‾\(ツ)/‾

@GoodForOneFare GoodForOneFare merged commit 8e90354 into master Nov 29, 2019
@GoodForOneFare GoodForOneFare deleted the multi-locale-koa branch November 29, 2019 14:32
@GoodForOneFare GoodForOneFare temporarily deployed to production November 29, 2019 15:58 Inactive
@theodoretan theodoretan temporarily deployed to gem December 10, 2019 21:19 Inactive
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants