Fifth and hopefully last pass at editing.

articles/lit/guides/security/spring-stateless.adoc

@@ -15,7 +15,7 @@ Unlike server-side authentication storage solutions -- which commonly rely on se
 Using stateless authentication brings benefits in the following use cases:
 
 **Horizontal Scaling of the Backend**::
-Helps to avoid the complexity of managing shared or sticky sessions between multiple backend servers.
+This helps to avoid the complexity of managing shared or sticky sessions among multiple backend servers.
 
 **Seamless Deployment**::
 Backend servers can be restarted without logging out users, and without the need for session persistence.
@@ -28,7 +28,7 @@ Hilla provides stateless authentication support in applications using Spring Sec
 
 == Enabling Stateless Authentication
 
-The following examples describe the steps to enable stateless authentication in a Hilla application that uses Spring Security. They involve adding dependencies, configuring Spring Security, the JWT authentication principal, and verification.
+The following examples illustrate the steps to enable stateless authentication in a Hilla application that uses Spring Security. They involve adding dependencies, configuring Spring Security, the JWT authentication principal, and verification.
 
 
 === Dependencies
@@ -86,7 +86,7 @@ echo "my.app.auth.secret=$(openssl rand -base64 32)" > config/local/application.
 Spring Boot supports many ways of configuring properties. See the link:https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config[Externalized Configuration] feature section in the Spring Boot Reference manual.
 
 
-=== Handle the JWT Authentication Principal
+=== Handle JWT Authentication Principal
 
 When using stateless authentication, the [methodname]`SecurityContext.getAuthentication().getPrincipal()` call returns a `Jwt` instance that contains only the username and roles. In your application, you need to verify that the reference returned by [methodname]`Authentication.getPrincipal()` is a `Jwt` instance.
 
@@ -101,7 +101,7 @@ include::{root}/src/main/java/com/vaadin/demo/fusion/security/stateless/Security
 
 ==== Verification
 
-After the previous steps, your application should be using stateless authentication. To verify this, start the development server. From there, open your application and log in. Then restart the development server. You should remain logged in after the restart.
+After completing the previous steps, your application should be using stateless authentication. To verify this, start the development server. From there, open your application and log in. Then restart the development server. You should remain logged in after the restart finishes.
 
 
 == JWT Expiration

articles/lit/guides/upgrading/index.adoc

@@ -19,10 +19,10 @@ Hilla 2 uses the latest Spring Boot 3 and Spring Framework 6 versions. This lead
 *Java 17*::
 Hilla 2 requires Java 17 or later. This is dictated by Spring framework and newer versions of application servers.
 
-Aside from these changes in Hilla dependencies, here are the notable changes in the framework itself:
+In addition to these changes in Hilla dependencies, below are notable changes in the framework itself:
 
 *Multi-Module Endpoints Parser & Generator*::
-Hilla 2 changes the parser and generator that are used to produce TypeScript code for endpoints. As a result, some adjustments to Java endpoints and entities code in Hilla applications might be required. The `hillaEngine` experimental feature flag was removed.
+Hilla 2 changes the parser and generator used to produce TypeScript code for endpoints. As a result, some adjustments to code for Java endpoints and entities in Hilla applications might be required. The `hillaEngine` experimental feature flag was removed.
 
 *Reactive Endpoints*::
 Released previously as an experimental feature behind the `hillaPush` feature flag, reactive endpoints are now enabled by default.
@@ -38,14 +38,14 @@ Before migrating any application, a few tasks must be done. They're described in
 
 === Set Up Node.js
 
-Installing an up-to-date version of Node.js 18 is recommended before starting with Hilla 2 migration. For an optimal and smooth application development experience, make sure to have `node` executables in the `PATH` environment variable. Follow the link:https://nodejs.dev/en/learn/how-to-install-nodejs/[Node.js installation instructions].
+Install an up-to-date version of Node.js 18 before starting a Hilla 2 migration. Be sure to have `node` executables in the `PATH` environment variable. Follow the link:https://nodejs.dev/en/learn/how-to-install-nodejs/[Node.js installation instructions].
 
 
 === Maven Wrapper
 
-Hilla 2 requires either a Maven wrapper script in the application, or the `mvn` executable in the environment, for configuring the endpoints parser and generator from the settings declared `pom.xml`.
+Hilla 2 requires either a Maven wrapper script in the application, or the `mvn` executable in the environment, for configuring the endpoints parser and generator from the settings declared [filename]`pom.xml`.
 
-If your project has `mvnw` and `mvnw.cmd` Maven wrapper scripts, Hilla 2 uses it to install and run Maven. The link:https://maven.apache.org/wrapper/[Maven Wrapper] website offers download links and instructions for installing it in a project.
+If your project has `mvnw` and `mvnw.cmd` Maven wrapper scripts, Hilla 2 uses them to install and run Maven. The link:https://maven.apache.org/wrapper/[Maven Wrapper] website offers download links and instructions for installing it in a project.
 
 For installing Maven in your system environment, see the link:https://maven.apache.org/install.html[Installing Apache Maven] documentation page.
 
@@ -65,9 +65,9 @@ You can find the latest version number in the link:https://github.com/vaadin/hil
 
 == Jakarta EE 10 Namespaces
 
-You can find on GitHub a couple of free tools for the package name conversion: https://github.com/eclipse/transformer[Eclipse Transformer]; and https://github.com/apache/tomcat-jakartaee-migration[Apache Migration Tool].
+You can download from GitHub a couple of free tools for the package name conversion: https://github.com/eclipse/transformer[Eclipse Transformer]; and https://github.com/apache/tomcat-jakartaee-migration[Apache Migration Tool].
 
-When applied to a project, these tools convert when needed Java class imports, manifests, property files, and other resources to use `jakarta.*` namespace. Conversion instructions can be found in each tool's [filename]`README` file.
+When applied to a project, these tools convert as needed Java class imports, manifests, property files, and other resources to use the `jakarta.*` namespace. Conversion instructions can be found in each tool's [filename]`README` file.
 
 The last versions of IntelliJ IDEA offers https://www.jetbrains.com/help/idea/2022.2/migrate.html[migration refactoring] tools, including a Java EE to Jakarta EE package converter.
 
@@ -103,19 +103,20 @@ Below are some examples:
 
 == Spring Upgrade Instructions
 
-Spring Boot 3 and Spring Framework 6 don't fundamentally change how applications are developed. The main changes are around Jakarta EE 10 namespaces and supported products, Java version, and the dependency upgrades and deprecations.
+Spring Boot 3 and Spring Framework 6 don't fundamentally change how applications are developed. The main changes are related to Jakarta EE 10 namespaces and supported products, Java version, and the dependency upgrades and deprecations.
 
 Spring Boot 3 and Framework 6 use new versions of third-party dependencies: Hibernate 6, Hibernate Validator 8, servlet containers -- Jetty 11, Tomcat 10.1 and many others.
 
 Spring provides the https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide[Dedicated Migration Guide for Spring-boot 3.0] and the https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-6.x[Upgrading to Spring Framework 6.x Guide].
 
 To browse the full list of changes, see the https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Release-Notes[Spring-boot 3.0 Release Notes] and the https://github.com/spring-projects/spring-framework/wiki/What%27s-New-in-Spring-Framework-6.x[What's New in Spring Framework 6.x] page.
 
-Below is a general overview of the changes needed for Spring-based Vaadin applications:
+The following sub-sections provide a general overview of the changes needed for Spring-based Vaadin applications.
+
 
 === Upgrade Spring to Latest
 
-You'll need to upgrade Spring versions to the latest, including the starter parent dependency:
+You'll need to upgrade Spring to the latest versions, including the starter parent dependency:
 
 .pom.xml
 [source,xml]
@@ -127,7 +128,8 @@ You'll need to upgrade Spring versions to the latest, including the starter pare
 </parent>
 ----
 
-=== Deprecation*
+
+=== Deprecation
 
 Deprecated `VaadinWebSecurityConfigurerAdapter` was removed since Spring no longer has the `WebSecurityConfigurerAdapter` class. Use instead the `VaadinWebSecurity` base class for your security configuration. Below is an example of this:
 
@@ -160,7 +162,7 @@ Java 17 or later is required. Below is an example of how to use this version:
 
 == Maven Plugins
 
-Several plugins are available for use with Maven. Those that are relevant to upgrading a Hilla application to Hilla 2.0 are described here.
+Several plugins are available for use with Maven. The ones relevant to upgrading a Hilla application to Hilla 2.0 are described here.
 
 
 === Hilla Maven Plugin
@@ -203,6 +205,7 @@ This also affects nullability in generated TypeScript code. Consider using the l
 
 Upgrading a Hilla application to Hilla 2 can involve several breaking changes. They're described in the following sub-sections.
 
+
 === Behavior & Styling
 
 Upgrading can lead to changes in the behavior and styling. Below is a list of these changes and what you might do to resolve problems they may cause:
@@ -239,6 +242,7 @@ The following changes affect the client-side APIs of Vaadin components:
 
 
 === Update Component Styling
+
 .Click and read if you have styled Vaadin components:
 [%collapsible]
 ====

articles/react/components/auto-grid/index.adoc

@@ -14,7 +14,7 @@ Auto Grid is a component for displaying tabular data based on a Java backend ser
 
 == Basic Usage
 
-Auto Grid requires a Java service that implements the `ListService<T>` interface. In the example here, the `ProductService` class extends `ListRepositoryService<T, ID, R>`, which in turn implements the `ListService<T>`:
+Auto Grid requires a Java service that implements the `ListService<T>` interface. In this example, the `ProductService` class extends `ListRepositoryService<T, ID, R>`, which in turn implements the `ListService<T>`:
 
 [.example]
 --
@@ -58,7 +58,7 @@ Here's what the rendered grid looks like:
 include::{root}/frontend/demo/component/auto-grid/react/auto-grid-basic.tsx[render,tags=snippet,indent=0,group=React]
 ----
 
-As you can see, Auto Grid automatically expands properties of `@OneToOne` relationships -- in this case the properties of the `supplier` -- and it displays them as columns in the grid. However, properties annotated with `@Id` or `@Version` are excluded by default. If you want to show them, though, you can use the `visibleColumns` property to specify which columns should be displayed. This is covered in the next section.
+As you can see, Auto Grid automatically expands properties of `@OneToOne` relationships -- in this case the properties of the `supplier` -- and it displays them as columns in the grid. However, properties annotated with `@Id` or `@Version` are excluded by default. To show them, though, you can use the `visibleColumns` property to specify which columns to display. You can find more information on this in the next section.
 
 
 == Customizing Columns
@@ -70,7 +70,7 @@ It's possible to customize the columns displayed by Auto Grid. How this is done
 
 To choose which of the data properties should be displayed as columns in Auto Grid, and to specify the column order, set the property names to the `visibleColumns` property.
 
-The following example uses only the `category`, `name`, `supplier.supplierName`, and `price` properties, in this order:
+The following example uses only the `category`, `name`, `supplier.supplierName`, and `price` properties -- in that order:
 
 .Auto Grid with Chosen Columns
 [source,tsx]
@@ -102,7 +102,7 @@ You can pass the same options as when rendering a column in a regular grid. See
 
 === Adding Custom Columns
 
-To add a custom column by joining the value of two or more properties and displaying them in a single column, this can be done by using the `customColumns` property. The `customColumns` property takes an array of `GridColumn` instances and renders them after the auto columns. Refer to the <<../grid/#,Grid>> documentation page for more information on the `GridColumn` type.
+To add a custom column that joins the values of multiple properties and displays them in a single column, use the `customColumns` property. This property takes an array of `GridColumn` instances and renders them after the auto columns. Refer to the <<../grid/#,Grid>> documentation page for more information on the `GridColumn` type.
 
 The following example uses the `customColumns` property to render a custom column that concatenates and displays the product's supplier `name` and `headquarterCity` properties in the same column:
 
@@ -114,12 +114,12 @@ include::{root}/frontend/demo/component/auto-grid/react/auto-grid-custom-columns
 
 .Customizing vs. Adding Columns
 [NOTE]
-In general, when it comes to customizing automatically rendered columns, you can use the `columnOptions` property. As for adding or customizing the custom columns, use `customColumns`.
+In general, for customizing automatically rendered columns, you can use the `columnOptions` property. As for adding or customizing the custom columns, use `customColumns`.
 
 
 ==== [since:dev.hilla:[email protected]]#Custom Columns Order#
 
-By default, custom columns are added after the automatically rendered columns. You can also define the order of appearance for custom columns by using the `visibleColumns` property. Custom columns can be freely placed before, in between, or after other columns. To achieve this, you'll need to provide the `key` property of the custom column in the `visibleColumns` property. 
+By default, custom columns are added after the automatically rendered columns. You can also define the order of appearance for custom columns by using the `visibleColumns` property. Custom columns can be freely placed before, in between, or after other columns. To do this, you'll need to provide the `key` property of the custom column in the `visibleColumns` property.
 
 The following example shows a custom column with `supplierInfo` as the `key` placed between two automatically rendered columns:
 
@@ -184,7 +184,7 @@ The example here enables single-row selection in the Auto Grid by using a combin
 include::{root}/frontend/demo/component/auto-grid/react/auto-grid-selection.tsx[render,tags=snippet,indent=0,group=React]
 ----
 
-You can read more on the properties, and use cases supported, on the <<../grid#,Grid component>> documentation page.
+You can read more about the properties, and use cases supported, on the <<../grid#,Grid component>> documentation page.
 
 ++++
 <style>