Adds USPs to liveobjects docs #3058
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
* Standardize all aside formats to use "See evidence here 🕵️" consistently * Add see-evidence aside styling with magnifying glass icon and teal color * Update Admonition component to handle see-evidence type and improve fallbacks LiveObjects pages updated: - Index: Tiered fanout architecture (removed duplicate asides) - Concepts: Fault tolerance, state integrity, regional consistency - Storage: Connection recovery guarantee - Lifecycle: Edge network failure resolution - Batch: Capacity headroom for traffic spikes - Inband objects: 37ms latency guarantee Component updates: - Added see-evidence aside styling and icon support - Improved Admonition fallback handling for undefined types 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
franrob-projects
force-pushed
the
FTF-452-write-usp-copy-for-live-objects
branch
from
4d93f61 to
da79786
Compare
GregHolmes
left a comment
GregHolmes
left a comment
There was a problem hiding this comment.
I've added a few comments. I'm not sure if you've tested this locally, but as with Spaces, the local env doesn't build due to issues with your implementation of the new Aside functionality.
|
|
||
| LiveObjects enables you to store shared data as "objects" on a channel, allowing your application data to be synchronized across multiple users and devices in realtime. This document explains the key concepts you need to know when working with objects. | ||
|
|
||
| <Aside data-type='see-evidence'> |
There was a problem hiding this comment.
I don't think the positioning of this is really great, it's just below the introducing paragraph. The user hasn't really started on the subject of objects and we're talking about other stats etc.
Also, I'm not sure MQTT is relevant to this page either. There's no mention of MQTT here.
|
|
||
| When you create or update an object, the change is expressed as an _operation_ that is sent as an [object message](/docs/metadata-stats/stats#messages) on the channel. The operation is then applied to the object instance on all clients that are subscribed to the channel. | ||
|
|
||
| <Aside data-type='see-evidence'> |
There was a problem hiding this comment.
Same as above, I'm not sure positioning of this is the best for the best developer experience.
Also, do we need to talk about disruptions under a page about operations?
|
|
||
| If there is a loss of continuity on the channel for any reason, such as the client becoming disconnected for more than two minutes and entering the [suspended state](/docs/connect/states#connection-states), the client objects will automatically be resynchronized when it reconnects. | ||
|
|
||
| <Aside data-type='see-evidence'> |
There was a problem hiding this comment.
In my opinion, adding another Aside in this section would be overkill. I'd recommend removing it. We already talk about loss of continuity in the last sentence. That's enough.
|
|
||
| Batch operations allow multiple updates to be grouped into a single channel message and applied atomically. It ensures that all operations in a batch either succeed together or are discarded entirely. Batching is essential when multiple related updates to channel objects must be applied as a single atomic unit, for example, when application logic depends on multiple objects being updated simultaneously. Batching ensures that all operations in the batch either succeed or fail together. | ||
|
|
||
| <Aside data-type='see-evidence'> |
There was a problem hiding this comment.
This is immediately above an existing Aside. Also, we have a note at the top of the page (Which in my opinion should be reconsidered) before any introduction is added and then another Aside at the bottom of the introduction. I'd recommend removing your addition.
|
|
||
| Inband objects works by delivering changes to channel objects as regular channel messages, similar to [inband occupancy](/docs/channels/options#occupancy). | ||
|
|
||
| <Aside data-type='see-evidence'> |
There was a problem hiding this comment.
We have a huge Aside above the line 38. I'm not sure adding another Aside immediately after which is just 1 sentence separating them is the best experience. Feels a bit overkill. What do you think?
| LiveObjects synchronization events do not replace [connection](/docs/connect/states) or [channel](/docs/channel/states) states. You should still monitor these states and handle [connection](/docs/connect/states#handling-failures) and [channel](/docs/channel/states#failure) failures to ensure your application behaves as expected. LiveObjects synchronization events specifically inform you about the progress of LiveObjects data synchronization and should be used alongside other state management mechanisms. | ||
| </Aside> | ||
|
|
||
| <Aside data-type='see-evidence'> |
There was a problem hiding this comment.
We're adding this immediately after an Important Aside. Is this necessary? The important talks about failures too.
|
|
||
| Ably durably stores all objects on a channel for a retention period that is configured to 90 days by default. If the data is not updated within the retention period, it automatically expires. After expiry, the channel is reset to its initial state and only includes an empty <If lang="javascript">[channel object](/docs/liveobjects/concepts/objects#channel-object)</If><If lang="swift,java">[root object](/docs/liveobjects/concepts/objects#root-object)</If>. | ||
|
|
||
| <Aside data-type='see-evidence'> |
There was a problem hiding this comment.
Immediately above another Aside (note), and also is this relevant to storage?
This PR:
Note that once the copy has been confirmed, I will then add the finished components designed by Lenker.
Checklist