Set up email template infrastructure #4369
Conversation
This further refines the synchronous FTL loading to allow loading FTL files for multiple locales. This makes it useful to not just tests/Storybook, but also e.g. for rendering email templates. At some point, we should probably rename this from `mockL10n` to something that implies production use as well, and possibly see if the website's l10n code (in /src/app/functions/server/10n.ts) could/should also build on top of it.
| import { getSpecificL10nSync } from "../app/functions/server/mockL10n"; | ||
|
|
||
| export function getEmailL10n( | ||
| subscriber: SubscriberRow, |
There was a problem hiding this comment.
Not critical, but I wonder if instead of using SubscriberRow we should have more constrained types - e.g. we could Pick as a way to allow-list. There are properties in SubscriberRow we would never want to appear in an email.
There was a problem hiding this comment.
That's a great point. I've implemented that in the followup PR at #4370.
| import { getSpecificL10nSync } from "../app/functions/server/mockL10n"; | ||
|
|
||
| export function getEmailL10n( | ||
| subscriber: SubscriberRow, |
There was a problem hiding this comment.
Could we use a more specific type, e.g. using Pick? SubscriberRow is fairly broad and contains data we wouldn't want to appear in an email.
| args: { | ||
| subscriber: { | ||
| signup_language: "en", | ||
| } as SubscriberRow, |
There was a problem hiding this comment.
Same as above re: SubscriberRow, I know we tend to pass this around but I think allow-listing the properties would be prevent someone from accidentally exposing something in the email that shouldn't be there.
References:
Jira: MNTOR-3036
This bundles up the MJML work we've done so far in atomic commits (5b95d9c for the email-specific bits, rather than the preparatory Fluent work) to merge into
main. I'll submit a followup PR to start using this for an actual email (behind a flag).See an example render in Storybook.