@@ -71,6 +71,7 @@ your email template when you make changes.
71
71
You can refer to our [ demo emails source code] ( https://demo.react.email/preview/vercel-invite-user.tsx?view=source )
72
72
for an example of how we do this with our demo deploy on Vercel.
73
73
</Info >
74
+
74
75
</Accordion >
75
76
<Accordion title = " How can I define props specific to the email's preview?" >
76
77
Considering that you are already default exporting the React component
@@ -98,6 +99,7 @@ your email template when you make changes.
98
99
99
100
< Email {... Email .PreviewProps } / > ;
100
101
```
102
+
101
103
</Accordion >
102
104
<Accordion title = " How to make the preview server ignore directories?" >
103
105
Once the preview server has started and is now open on ` localhost ` , the preview server
@@ -118,6 +120,7 @@ your email template when you make changes.
118
120
```
119
121
120
122
Then the only file that will be shown on the preview server is going to be your ` email.tsx ` .
123
+
121
124
</Accordion >
122
125
<Accordion title = " The heuristics for files to be considered emails" >
123
126
To avoid uncanny files appearing in the sidebar of the preview server,
@@ -130,6 +133,7 @@ your email template when you make changes.
130
133
131
134
These can certainly fail as they are only heuristics, so if you do find
132
135
any issues with these, feel free to open an [ issue] ( https://github.com/resend/react-email/issues ) .
136
+
133
137
</Accordion >
134
138
</AccordionGroup >
135
139
@@ -156,16 +160,18 @@ Generates the plain HTML files of your emails into a `out` directory.
156
160
A very common misconception is to assume that this command is
157
161
the way meant to be used to send the email templates, but it is not.
158
162
159
- The preferable way is to render the email using the [ render] ( /utilities/render ) utility,
160
- by passing in the needed data through props, on the moment of sending the email,
161
- This gives for a much better developer experience that it would with ` email export ` .
163
+ The preferable way is to render the email using the [ render] ( /utilities/render ) utility,
164
+ by passing in the needed data through props, on the moment of sending the email,
165
+ This gives for a much better developer experience that it would with ` email export ` .
166
+
167
+ ` email export ` is a secondary way where the situation is not optimal. Two of them are:
168
+
169
+ - The email template is sent through some other language
170
+ - You are going to use separate templating, because the email platform you use forces you to do so
162
171
163
- ` email export ` is a secondary way where the situation is not optimal. Two of them are:
164
- - The email template is sent through some other language
165
- - You are going to use separate templating, because the email platform you use forces you to do so
172
+ We strongly recommend users to gravitate towards using the preferable way, because otherwise
173
+ you will end up having to fight a lot with the rendered markup and many other issues arise.
166
174
167
- We strongly recommend users to gravitate towards using the preferable way, because otherwise
168
- you will end up having to fight a lot with the rendered markup and many other issues arise.
169
175
</Info >
170
176
171
177
** Options**
@@ -185,4 +191,4 @@ Generates the plain HTML files of your emails into a `out` directory.
185
191
186
192
## ` email help <cmd> `
187
193
188
- Shows all the options for a specific command.
194
+ Shows all the options for a specific command.
0 commit comments