You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reduce risk of debug variables being used in production
Maintain good developer UX
Background
To render an email in the UI, you need to provide default arguments e.g.
exportinterfaceMyEmailProps{name: string;}exportconstMyEmail=({
name ="World",}: MyEmailProps)=>{return(<Html><Head/><Body><Container><Text>
Hello {name}</Text></Container></Body></Tailwind></Html>);};
The problem here is that if I want a required argument (in this case name) I won't be able to preview it in the UI without providing a default, but in doing this I've effectively made my name property not required or worse I risk rendering debug values in production emails.
Current alternatives would be doing some additional checking to populate defaults e.g.
...
exportconstMyEmail=({ name }: MyEmailProps)=>{constargs=process.env.dev||!process.env.VERCEL_URL ? {name: "world"} : { name };
...
<Text>
Hello {args.name}</Text>...});
Proposal
Instead it would be interesting if the UI could use a similar approach to nextjs by providing some named exports to populate these developer examples in the react-email ui while ensuring that those values will never be seen in production.
Potential example would look like
exportinterfaceMyEmailProps{name: string;}// property name TBD but as an exampleexportconstpreviewArgs={name: "world"}// When the react-email ui renders the component, pass in the previewArgs as the propsexportconstMyEmail=({ name }: MyEmailProps)=>{return(<Html><Head/><Body><Container><Text>
Hello {name}</Text></Container></Body></Tailwind></Html>);};
This maintains a good UX and type safety without risking that dev variables get generated in production or requiring additional conditionals in the email template.
Future versions of the UI could build in this further by making the props editable within the ui with the previewArgs serving as good defaults.
Willing to contribute.....not sure if my skills would meet the teams requirements as I haven't contributed to a lot of open source projects.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Goals
Background
To render an email in the UI, you need to provide default arguments e.g.
The problem here is that if I want a required argument (in this case name) I won't be able to preview it in the UI without providing a default, but in doing this I've effectively made my
nameproperty not required or worse I risk rendering debug values in production emails.Current alternatives would be doing some additional checking to populate defaults e.g.
Proposal
Instead it would be interesting if the UI could use a similar approach to nextjs by providing some named exports to populate these developer examples in the react-email ui while ensuring that those values will never be seen in production.
Potential example would look like
This maintains a good UX and type safety without risking that dev variables get generated in production or requiring additional conditionals in the email template.
Future versions of the UI could build in this further by making the props editable within the ui with the
previewArgsserving as good defaults.Willing to contribute.....not sure if my skills would meet the teams requirements as I haven't contributed to a lot of open source projects.
Beta Was this translation helpful? Give feedback.
All reactions