readme tweaks

Author: weaverryan

README.md

@@ -37,7 +37,7 @@ integrating it into [Webpack Encore](https://github.com/symfony/webpack-encore).
 -   [Twig Component](https://github.com/symfony/ux-twig-component):
     A system to build reusable "components" with Twig
 -   [Live Component](https://github.com/symfony/ux-live-component):
-    Gives Twig Components a URL and a JavaScript library to automatically re-render via Ajax as your user interacts with it 
+    Gives Twig Components a URL and a JavaScript library to automatically re-render via Ajax as your user interacts with it
 
 ## Stimulus Tools around the World
 

src/LiveComponent/README.md

@@ -19,14 +19,14 @@ use Symfony\UX\LiveComponent\LiveComponentInterface;
 class ProductSearchComponent implements LiveComponentInterface
 {
     public string $query = '';
-    
+
     private ProductRepository $productRepository;
-    
+
     public function __construct(ProductRepository $productRepository)
     {
         $this->productRepository = $productRepository;
     }
-    
+
     public function getProducts(): array
     {
         // example method that returns an array of Products
@@ -48,7 +48,7 @@ class ProductSearchComponent implements LiveComponentInterface
         value="{{ this.query }}"
         data-action="live#update"
     >
-    
+
     <ul>
         {% for product in this.products %}
             <li>{{ product.name }}</li>
@@ -139,7 +139,7 @@ component's interface to `LiveComponentInterface`:
 }
 ```
 
-Then, in the template, make sure there is *one* HTML element around
+Then, in the template, make sure there is _one_ HTML element around
 your entire component and use the `{{ init_live_component() }}` function
 to initialize the Stimulus controller:
 
@@ -158,7 +158,7 @@ and give the user a new random number:
 ```twig
 <div {{ init_live_component(this) }}>
     <strong>{{ this.randomNumber }}</strong>
-    
+
     <button
         data-action="live#$render"
     >Generate a new number!</button>
@@ -172,7 +172,7 @@ cool, but let's keep going because... things get cooler.
 
 ## LiveProps: Stateful Component Properties
 
-Let's make our component  more flexible by adding `$min` and `$max` properties:
+Let's make our component more flexible by adding `$min` and `$max` properties:
 
 ```php
 // src/Components/RandomNumberComponent.php
@@ -192,7 +192,7 @@ class RandomNumberComponent implements LiveComponentInterface
     {
         return rand($this->min, $this->max);
     }
-    
+
     // ...
 }
 ```
@@ -208,10 +208,10 @@ But what's up with those `@LiveProp` annotations? A property with
 the `@LiveProp` annotation (or `LiveProp` PHP 8 attribute) becomes
 a "stateful" property for this component. In other words, each time
 we click the "Generate a new number!" button, when the component
-re-renders, it will *remember* the original values for the `$min` and
+re-renders, it will _remember_ the original values for the `$min` and
 `$max` properties and generate a random number between 5 and 500.
 If you forgot to add `@LiveProp`, when the component re-rendered,
-those two values would *not* be set on the object.
+those two values would _not_ be set on the object.
 
 In short: LiveProps are "stateful properties": they will always
 be set when rendering. Most properties will be LiveProps, with
@@ -222,9 +222,9 @@ the component is rendered) and
 
 ## data-action="live#update": Re-rendering on LiveProp Change
 
-Could we allow the user to *choose* the `$min` and `$max` values
+Could we allow the user to _choose_ the `$min` and `$max` values
 and automatically re-render the component when they do? Definitely!
-And *that* is where live components really shine.
+And _that_ is where live components really shine.
 
 Let's add two inputs to our template:
 
@@ -237,7 +237,7 @@ Let's add two inputs to our template:
         data-model="min"
         data-action="live#update"
     >
-    
+
     <input
         type="number"
         value="{{ this.max }}"
@@ -252,8 +252,8 @@ Let's add two inputs to our template:
 
 Notice the `data-action="live#update"` on each `input`. When the
 user types, live components reads the `data-model` attribute (e.g. `min`)
-and re-renders the component using the *new* value for that field! Yes,
-as you type in a box, the component  automatically updates to reflect the
+and re-renders the component using the _new_ value for that field! Yes,
+as you type in a box, the component automatically updates to reflect the
 new number!
 
 Well, actually, we're missing one step. By default, a `LiveProp` is
@@ -273,7 +273,7 @@ class RandomNumberComponent implements LiveComponentInterface
 -    /** @LiveProp() */
 +    /** @LiveProp(writable=true) */
     public int $max = 1000;
-    
+
     // ...
 }
 ```
@@ -292,7 +292,7 @@ don't need to think about it.
 ### Lazy Updating on "blur" or "change" of a Field
 
 Sometimes, you might want a field to re-render only after the user
-has changed an input *and* moved to another field. Browsers dispatch
+has changed an input _and_ moved to another field. Browsers dispatch
 a `change` event in this situation. To re-render when this event
 happens, add it to the `data-action` call:
 
@@ -330,7 +330,7 @@ is clicked). To do that, use the `updateDefer` method:
 
 Now, as you type, the `max` "model" will be updated in JavaScript, but
 it won't, yet, make an Ajax call to re-render the component. Whenever
-the next re-render *does* happen, the updated `max` value will be used.
+the next re-render _does_ happen, the updated `max` value will be used.
 
 ### Using name="" instead of data-model
 
@@ -347,7 +347,7 @@ code works identically to the previous example:
 +        name="min"
         data-action="live#update"
     >
-    
+
     // ...
 </div>
 ```
@@ -365,7 +365,7 @@ re-rendering or an [action](#actions) is processing. For example:
 <span data-loading="show">Loading</span>
 ```
 
-Or, to *hide* an element while the component is loading:
+Or, to _hide_ an element while the component is loading:
 
 ```twig
 <!-- hide when the component is loading -->
@@ -448,13 +448,13 @@ class RandomNumberComponent implements LiveComponentInterface
         $this->min = 0;
         $this->max = 1000;
     }
-    
+
     // ...
 }
 ```
 
 To call this, add `data-action="live#action"` and `data-action-name`
-to an element (e.g.  a button or form):
+to an element (e.g. a button or form):
 
 ```twig
 <button
@@ -488,7 +488,7 @@ request will be made!
 #### Actions & Services
 
 One really neat thing about component actions is that they are
-*real* Symfony controllers. Internally, they are processed
+_real_ Symfony controllers. Internally, they are processed
 identically to a normal controller method that you would create
 with a route.
 
@@ -514,7 +514,7 @@ class RandomNumberComponent implements LiveComponentInterface
         $this->max = 1000;
         $logger->debug('The min/max were reset!');
     }
-    
+
     // ...
 }
 ```
@@ -556,12 +556,12 @@ class RandomNumberComponent extends AbstractController implements LiveComponentI
     public function resetMinMax()
     {
         // ...
-        
+
         $this->addFlash('success', 'Min/Max have been reset!');
-        
+
         return $this->redirectToRoute('app_random_number');
     }
-    
+
     // ...
 }
 ```
@@ -723,7 +723,7 @@ class PostFormComponent extends AbstractController implements LiveComponentInter
 
 The trait forces you to create an `instantiateForm()` method,
 which is used when the component is rendered via AJAX. Notice that,
-in order to recreate the *same* form, we pass in the `Post` object
+in order to recreate the _same_ form, we pass in the `Post` object
 and set it as a `LiveProp`.
 
 The template for this component will render the form, which is
@@ -760,23 +760,23 @@ Mostly, this is a pretty boring template! It includes the normal
 `init_live_component(this)` and then you render the form however you want.
 
 But the result is incredible! As you finish changing each field, the
-component  automatically re-renders - including showing any validation
+component automatically re-renders - including showing any validation
 errors for that field! Amazing!
 
 This is possible thanks to a few interesting pieces:
 
-* `data-action="change->live#update"`: instead of adding `data-action`
-  to *every* field, you can place this on a parent element. Thanks to
-  this, as you change or type into fields (i.e. the `input` event),
-  the model for that field will update and the component will re-render.
+-   `data-action="change->live#update"`: instead of adding `data-action`
+    to _every_ field, you can place this on a parent element. Thanks to
+    this, as you change or type into fields (i.e. the `input` event),
+    the model for that field will update and the component will re-render.
 
-* The fields in our form do not have a `data-model=""` attribute. But
-  that's ok! When that is absent, the `name` attribute is used instead.
-  `ComponentWithFormTrait` has a modifiable `LiveProp` that captures
-  these and submits the form using them. That's right: each render time
-  the component re-renders, the form is *submitted* using the values.
-  However, if a field has not been modified yet by the user, its
-  validation errors are cleared so that they aren't rendered.
+-   The fields in our form do not have a `data-model=""` attribute. But
+    that's ok! When that is absent, the `name` attribute is used instead.
+    `ComponentWithFormTrait` has a modifiable `LiveProp` that captures
+    these and submits the form using them. That's right: each render time
+    the component re-renders, the form is _submitted_ using the values.
+    However, if a field has not been modified yet by the user, its
+    validation errors are cleared so that they aren't rendered.
 
 ### Form Rendering Problems
 
@@ -831,13 +831,13 @@ public function buildForm(FormBuilderInterface $builder, array $options)
 
 ### Submitting the Form via an action()
 
-Notice that, while we *could* add a `save()` [component action](#actions)
+Notice that, while we _could_ add a `save()` [component action](#actions)
 that handles the form submit through the component, we've chosen not
-to do that so far. The reason is simple: by creating  a normal route &
-controller that handles the submit, our form continues  to work without
+to do that so far. The reason is simple: by creating a normal route &
+controller that handles the submit, our form continues to work without
 JavaScript.
 
-However, you *can* do this if you'd like. In that case, you wouldn't
+However, you _can_ do this if you'd like. In that case, you wouldn't
 need any form logic in your controller:
 
 ```php
@@ -864,7 +864,7 @@ And you wouldn't pass any `form` into the component:
 }) }}
 ```
 
-When you do *not* pass a `form` into a component that uses `ComponentWithFormTrait`,
+When you do _not_ pass a `form` into a component that uses `ComponentWithFormTrait`,
 the form will be created for you automatically. Let's add the `save()`
 action to the component:
 
@@ -947,7 +947,7 @@ class EditPostComponent implements LiveComponentInterface
 }
 ```
 
-In the template, let's render an HTML form *and* a "preview" area
+In the template, let's render an HTML form _and_ a "preview" area
 where the user can see, as they type, what the post will look like
 (including rendered the `content` through a Markdown filter from the
 `twig/markdown-extra` library):
@@ -975,9 +975,9 @@ where the user can see, as they type, what the post will look like
 
 This is pretty straightforward, except for one thing: the `data-model`
 attributes aren't targeting properties on the component class itself,
-they're targeting *embedded* properties within the `$post` property.
+they're targeting _embedded_ properties within the `$post` property.
 
-Out-of-the-box, modifying embedded properties is *not* allowed. However,
+Out-of-the-box, modifying embedded properties is _not_ allowed. However,
 you can enable it via the `exposed` option:
 
 ```diff
@@ -996,12 +996,12 @@ class EditPostComponent implements LiveComponentInterface
 ```
 
 With this, both the `title` and the `content` properties of the
-`$post` property *can* be modified by the user. However, notice
-that the `LiveProp` does *not* have `modifiable=true`. This
+`$post` property _can_ be modified by the user. However, notice
+that the `LiveProp` does _not_ have `modifiable=true`. This
 means that while the `title` and `content` properties can be
 changed, the `Post` object itself **cannot** be changed. In other
 words, if the component was originally created with a Post
-object with id=2, a bad user could *not* make a request that
+object with id=2, a bad user could _not_ make a request that
 renders the component with id=3. Your component is protected from
 someone changing to see the form for a different `Post` object,
 unless you added `writable=true` to this property.
@@ -1011,8 +1011,8 @@ unless you added `writable=true` to this property.
 **NOTE** If your component [contains a form](#forms), then validation
 is built-in automatically. Follow those docs for more details.
 
-If you're building some sort of form *without* using Symfony's form
-component, you *can* still validate your data.
+If you're building some sort of form _without_ using Symfony's form
+component, you _can_ still validate your data.
 
 First use the `ValidatableComponentTrait` and add any constraints you need:
 
@@ -1038,7 +1038,7 @@ class EditUserComponent implements LiveComponentInterface
      * @Assert\IsTrue()
      */
     public bool $agreeToTerms = false;
-    
+
     public static function getComponentName() : string
     {
         return 'edit_user';
@@ -1050,12 +1050,12 @@ Be sure to add the `@Assert\IsValid` to any property where you want
 the object on that property to also be validated.
 
 Tahnks to this setup, the component will now be automatically validated
-on each render,  but in a smart way: a property will only be validated
+on each render, but in a smart way: a property will only be validated
 once its "model" has been updated on the frontend. The system keeps track
 of which models have been updated (e.g. `data-action="live#update"`)
 and only stores the errors for those fields on re-render.
 
-You can also trigger validation of your *entire* object manually
+You can also trigger validation of your _entire_ object manually
 in an action:
 
 ```php