Skip to content

Commit 8a9a099

Browse files
committed
Formatting
1 parent 271d2be commit 8a9a099

File tree

1 file changed

+48
-47
lines changed

1 file changed

+48
-47
lines changed

README.md

Lines changed: 48 additions & 47 deletions
Original file line numberDiff line numberDiff line change
@@ -77,11 +77,11 @@
7777
- [Prevent Controller Action](#prevent-controller-action)
7878
- [Broadcasting Turbo Streams](#broadcasting-turbo-streams)
7979
- [State](#state)
80-
- [Server State](#server-state)
81-
- [Now State](#now-state)
82-
- [Client State](#client-state)
80+
- [Server-State](#server-state)
81+
- [Now-State](#now-state)
82+
- [Client-State](#client-state)
83+
- [Page-State](#page-state)
8384
- [State Resolution](#state-resolution)
84-
- [Page State](#page-state)
8585
- [Community](#community)
8686
- [Developing](#developing)
8787
- [Notable Files](#notable-files)
@@ -540,26 +540,26 @@ TurboBoost manages various forms of state to provide a terrific reactive user ex
540540

541541
Here’s a breakdown of each type:
542542

543-
### Server State
543+
### Server-State
544544

545-
Server state is the persistent state that the server used for the most recent render.
545+
Server-State is the persistent state that the server used for the most recent render.
546546
This state is signed, ensuring data integrity and security.
547547

548548
The client includes this signed state along with its own optimistic changes whenever a Command is invoked.
549-
The server can then compute the difference between the client state and the server state,
549+
The server can then compute the difference between the Client-State and the Server-State,
550550
allowing you to accept or reject the client's optimistic changes.
551551

552552
This ensures the server remains the single source of truth.
553553

554-
Server state can be accessed within Commands like so.
554+
Server-State can be accessed within Commands like so.
555555

556556
```ruby
557557
state[:key] = "value"
558558
state[:key]
559559
#=> "value"
560560
```
561561

562-
Server state is also accessible in controllers and views.
562+
Server-State is also accessible in controllers and views.
563563

564564
```ruby
565565
# controller
@@ -576,22 +576,22 @@ turbo_boost.state[:key]
576576
%>
577577
```
578578

579-
### Now State
579+
### Now-State
580580

581-
Now state is ephemeral server-side state that only exists for the current render cycle.
581+
Now-State is ephemeral server side state that only exists for the current render cycle.
582582
Similar to `flash.now` in Rails, this state is discarded after rendering.
583583

584584
It’s useful for managing temporary data that doesn’t need to persist beyond the current request.
585585

586-
Now state can be accessed within Commands like so.
586+
Now-State can be accessed within Commands like so.
587587

588588
```ruby
589589
state.now[:key] = "value"
590590
state.now[:key]
591591
#=> "value"
592592
```
593593

594-
Server state is also accessible in controllers and views.
594+
Now-State is also accessible in controllers and views.
595595

596596
```ruby
597597
# controller
@@ -608,35 +608,62 @@ turbo_boost.state.now[:key]
608608
%>
609609
```
610610

611-
### Client State
611+
### Client-State
612612

613-
Client state is a mutable version of the signed server state, wrapped in an observable JavaScript proxy.
614-
This allows for sophisticated techniques like data binding with custom JavaScript, Stimulus controllers, and web components.
613+
Client-State is a mutable version of the signed Server-State, wrapped in an observable JavaScript proxy.
614+
This allows for sophisticated techniques like data binding via custom JavaScript, Stimulus controllers, or web components.
615615

616-
Client-side state enables immediate UI updates, providing a fast and smooth user experience while the server resolves state differences whenever commands are invoked.
616+
Client-side state enables immediate UI updates, providing a fast and smooth user experience while the server
617+
[resolves state](#state-resolution) differences whenever Commands are invoked.
617618

618-
Client state can be accessed on the client like so.
619+
Client-State can be accessed on the client like so.
619620

620621
```js
621622
TurboBoost.State.current['key'] = 'value'
622623
TurboBoost.State.current['key']
623624
//=> 'value'
624625
```
625626

627+
### Page-State
628+
629+
Page-State is managed by the client and used to remember element attribute values between server renders.
630+
It’s best for tracking transient user interactions, like which elements are visible, open/closed, their position, etc.
631+
632+
This enhances the user experience by maintaining the state of UI elements between renders.
633+
When invoking commands, the client sends the Page-State to the server, allowing it to preserve element attributes when rendering.
634+
_The client also checks and restores Page-State whenever the DOM changes if needed._
635+
636+
You can opt-in to remember Page-State with Rails tag helpers via the `turbo_boost[:remember]` option.
637+
638+
```erb
639+
<%= tag.details id: "page-state-example", open: "open", turbo_boost: { remember: [:open] } do %>
640+
<summary>Page-State Example</summary>
641+
Content...
642+
<% end %>
643+
```
644+
645+
_This remembers whether the `details` element is open or closed._
646+
647+
__That's it!__ You're done.
648+
649+
> [!NOTE]
650+
> Page-State tracking works with all element attributes, including `aria` and `data`,
651+
> but elements must have a unique `id` to participate in Page-State tracking.
652+
626653
### State Resolution
627654

628655
Commands can perform state resolution by implementing the `resolve_state` method.
629656

630657
The Command has access to all forms of state, so you should use explicit access during resolution.
631658

632-
You can access both the signed server state and the optimistc client state from within the Command like so.
659+
You can access both the signed Server-State and the optimistc Client-State from within the Command like so.
633660

634661
```ruby
635662
class ExampleCommand < TurboBoost::Commands::Command
636663

637664
def resolve_state
638-
state.signed #=> the server state (from the last render)
639-
state.unsigned #=> the client optimistc state
665+
state.signed #=> the Server-State (from the last render)
666+
state.unsigned #=> the optimistic Client-State
640667
# compare and resolve the delta
641668
end
642669
end
@@ -654,32 +681,6 @@ TurboBoost::Commands.config.tap do |config|
654681
end
655682
```
656683

657-
### Page State
658-
659-
Page State is managed by the client and used to remember element attribute values between server renders.
660-
It’s best for tracking transient user interactions, like which elements are visible, open/closed, their position, etc.
661-
662-
This enhances the user experience by maintaining the state of UI elements between renders.
663-
When invoking commands, the client sends the page state to the server, allowing it to preserve element attributes when rendering.
664-
_The client also checks and restores page state whenever the DOM changes if needed._
665-
666-
You can opt-in to remember page state with Rails tag helpers via the `turbo_boost[:remember]` option.
667-
668-
```erb
669-
<%= tag.details id: "page-state-example", open: "open", turbo_boost: { remember: [:open] } do %>
670-
<summary>Page State Example</summary>
671-
Content...
672-
<% end %>
673-
```
674-
675-
_This remembers whether the `details` element is open or closed._
676-
677-
__That's it!__ You're done.
678-
679-
> [!NOTE]
680-
> Page state tracking works with all element attributes, including `aria` and `data`,
681-
> but elements must have a unique `id` to participate in page state tracking.
682-
683684
## Community
684685

685686
Come join the party with over 2200+ like-minded friendly Rails/Hotwire enthusiasts on our [Discord server](https://discord.gg/stimulus-reflex).

0 commit comments

Comments
 (0)