-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great, thanks! I have a suggestion to scope down the SubscriberRow
type but I don't think it's blocking, would like to hear what you think about that.
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.