@@ -1141,11 +1141,11 @@ You can also trigger a specific "action" instead of a normal re-render:
1141
1141
1142
1142
## Embedded Components
1143
1143
1144
- Can you embed one live component inside another one? Absolutely ! As a rule
1144
+ Need to embed one live component inside another one? No problem ! As a rule
1145
1145
of thumb, ** each component exists in its own, isolated universe** . This
1146
- means that embedding one component inside another might be really simple...
1147
- or a bit more complex if your components share "model" data or are
1148
- "connected" in other ways .
1146
+ means that embedding one component inside another could be really simple
1147
+ or a bit more complex, depending on how inter-connected you want your components
1148
+ to be .
1149
1149
1150
1150
Here are a few helpful things to know:
1151
1151
@@ -1155,11 +1155,11 @@ If a parent component re-renders, the child component will _not_ (most
1155
1155
of the time) be updated, even though it lives inside the parent. Each
1156
1156
component is its own, isolated universe.
1157
1157
1158
- But... this is not always what you want. For example, suppose a
1159
- parent component holds a form and a child component holds one field.
1160
- When you click a "Save" button on the parent component, it validates
1161
- the form and re-renders with errors - including a new ` error ` value
1162
- that it passes into the child:
1158
+ But this is not always what you want. For example, suppose you have a
1159
+ parent component that renders a form and a child component that renders
1160
+ one field in that form. When you click a "Save" button on the parent
1161
+ component, that validates the form and re-renders with errors - including
1162
+ a new ` error ` value that it passes into the child:
1163
1163
1164
1164
``` twig
1165
1165
{# templates/components/post_form.html.twig #}
@@ -1172,20 +1172,24 @@ that it passes into the child:
1172
1172
1173
1173
In this situation, when the parent component re-renders after clicking
1174
1174
"Save", you _ do_ want the updated child component (with the validation
1175
- error) to be rendered. And, this _ will_ happen because the system detects
1176
- that the parent component has _ changed_ how it's rendering the child.
1175
+ error) to be rendered. And this _ will_ happen automatically. Why? because
1176
+ the live component system detects that the ** parent component has
1177
+ _ changed_ how it's rendering the child** .
1177
1178
1178
1179
This may not always be perfect, and if your child component has its own
1179
1180
` LiveProp ` that has changed since it was first rendered, that value will
1180
- be lost when the parent component causes the child to re-render.
1181
+ be lost when the parent component causes the child to re-render. If you
1182
+ have this situation, use ` data-model-map ` to map that child ` LiveProp ` to
1183
+ a ` LiveProp ` in the parent component, and pass it into the child when
1184
+ rendering.
1181
1185
1182
1186
### Actions, methods and model updates in a child do not affect the parent
1183
1187
1184
1188
Again, each component is its own, isolated universe! For example, suppose
1185
1189
your child component has:
1186
1190
1187
1191
``` html
1188
- <button data-action =" live#action" data-action-name =" save" ></button >
1192
+ <button data-action =" live#action" data-action-name =" save" >Save </button >
1189
1193
```
1190
1194
1191
1195
When the user clicks that button, it will attempt to call the ` save ` action
@@ -1209,7 +1213,7 @@ However, sometimes this isn't what you want! Sometimes, in addition
1209
1213
to updating the child component's model, you _ also_ want to update a
1210
1214
model on the _ parent_ component.
1211
1215
1212
- To help with this, whenever a model updates, a ` live:update-model `
1216
+ To help with this, whenever a model updates, a ` live:update-model ` event
1213
1217
is dispatched. All components automatically listen to this event. This
1214
1218
means that, when the ` markdown_value ` model is updated in the child
1215
1219
component, _ if_ the parent component _ also_ has a model called ` markdown_value `
@@ -1218,8 +1222,8 @@ it will _also_ be updated. This is done as a "deferred" update
1218
1222
1219
1223
If the model name in your child component (e.g. ` markdown_value ` ) is
1220
1224
_ different_ than the model name in your parent component (e.g. ` post.content ` ),
1221
- you can make sure both are set by leveraging both the ` data-model `
1222
- and ` name ` attributes:
1225
+ you have two options. First, you can make sure both are set by
1226
+ leveraging both the ` data-model ` and ` name ` attributes:
1223
1227
1224
1228
``` twig
1225
1229
<textarea
@@ -1234,7 +1238,25 @@ component (because `data-model` takes precedence over `name`). But if
1234
1238
any parent components have a ` markdown_value ` model _ or_ a ` post.content `
1235
1239
model (normalized from ` post[content ` ] `), their model will also be updated.
1236
1240
1237
- ** NOTE** : If you _ change_ a ` LiveProp ` ofa child component on the server
1241
+ A second option is to wrap your child element in a special ` data-model-map `
1242
+ element:
1243
+
1244
+ ``` twig
1245
+ {# templates/components/post_form.html.twig #}
1246
+
1247
+ <div data-model-map="from(markdown_value)|post.content">
1248
+ {{ component('textarea_field', {
1249
+ value: this.content,
1250
+ error: this.getError('content')
1251
+ }) }}
1252
+ </div>
1253
+ ```
1254
+
1255
+ Thanks to the ` data-model-map ` , whenever the ` markdown_value ` model
1256
+ updates in the child component, the ` post.content ` model will be
1257
+ updated in the parent component.
1258
+
1259
+ ** NOTE** : If you _ change_ a ` LiveProp ` of a child component on the server
1238
1260
(e.g. during re-rendering or via an action), that change will _ not_ be
1239
1261
reflected on any parent components that share that model.
1240
1262
0 commit comments