Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating a SharedState variable does not refresh the views that are #[watch]ing it #511

Open
chriskilding opened this issue Aug 21, 2023 · 2 comments

Comments

@chriskilding
Copy link
Contributor

If a view contains an Rc<SharedState> variable (e.g. to hold persistent document state), and the variable is modified within the view update method, only the immediate view is re-rendered in response. Any child views will not be re-rendered, and continue to show the old state.

This only changes when, eventually, the user triggers a different event within the child view(s), which runs their own re-render loops. At this point you can see the new contents of the Rc<SharedState> reflected in the child views.

The expected behaviour is that modifying a SharedState variable should trigger a re-render of all the views that are #[watch]ing it.

I have created a minimal working example at https://github.com/chriskilding/relm4-tic-tac-toe to demonstrate this.

@AaronErhardt
Copy link
Member

The best approach to implement this would probably to allow components to subscribe to a SharedState and get a message when something changed, similar to Reducer. Otherwise this would require bigger changes because #[watch] relies on a component update which is only triggered by messages so far.

@chriskilding
Copy link
Contributor Author

Hmm... The best user / developer experience would probably be to update the #[watch] macro code so that it behaves as expected. With that in mind I've taken a quick look through its code in relm4-macros, but have found that quite hard to understand (probably just because macros are harder to understand than regular code).

Could you give me some pointers about where to start modifying that macro's behaviour? (Or perhaps how to trigger a Component update with something other than messages?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants