Allow Lustre applications to subscribe to context changes.#472
Merged
Conversation
yoshi-monster
approved these changes
May 3, 2026
Contributor
yoshi-monster
left a comment
yoshi-monster
left a comment
There was a problem hiding this comment.
Hello! Sorry this took a while.
I think it's worth documenting that you need to subscribe/unsubscribe using the connect and disconnect events in components, which means you can't properly subscribe to context changes when using the application constructor combined with register (or server components).
otherwise this looks great thank you!!
yoshi-monster
requested changes
May 3, 2026
Contributor
There was a problem hiding this comment.
This should be a Map I think?
| /// | ||
| /// Once a value for the given key has been provided, children can [`subscribe`](#subscribe) | ||
| /// to changes and receive updates any subsequent times `provide` is called with | ||
| /// the same key. This facilities parent-child communication even in cases where |
Contributor
There was a problem hiding this comment.
Suggested change
| /// the same key. This facilities parent-child communication even in cases where | |
| /// the same key. This facilitates parent-child communication even in cases where |
| /// DOM. This effect will decode the context value from the first parent element | ||
| /// that has _already provided_ a context for this key at least once. Once a | ||
| /// subscription is set up, any changes to the context value will trigger additional | ||
| /// messages to be dispatch with the new decoded value. |
Contributor
There was a problem hiding this comment.
Suggested change
| /// messages to be dispatch with the new decoded value. | |
| /// messages to be dispatched with the new decoded value. |
| Effect(..empty, synchronous: constants.singleton_list(task)) | ||
| } | ||
|
|
||
| /// Unsubscribe to a context [`subscription`](#subscribe) that was previously set |
Contributor
There was a problem hiding this comment.
Suggested change
| /// Unsubscribe to a context [`subscription`](#subscribe) that was previously set | |
| /// Unsubscribe from a context [`subscription`](#subscribe) that was previously set |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A few versions back we implemented the WCCG Context Protocol by adding the
effect.provideeffect and acomponent.on_context_changecomponent option. This allowed any Lustre application to provide context values under a specific key, and for any Lustre component (server or client) to subscribe to changes to those values and dispatch messages.Because this is a web component protocol we overlooked the fact that applications might want to subscribe to context values too! The most-compelling scenario for this is when a client SPA is rendered in a server component
<slot>, enabling a "store pattern" that let's the app subscribe to backend data without the need for an explicit API.This PR deprecates
component.on_context_changeentirely in favour of two new effects:effect.subscribeeffect.unsubscribeAs context unsubscription is new behaviour, we needed to decide what should happen to existing component context subscriptions are unsubscribed from and then the component is subsequently unmounted and remounted to the DOM. We decided that removed subscriptions should not be re-added when the component reconnects.