feat(state): New state system

[Flemmli97]

What this PR does 📖

• This is the PR for a new state system utilising a local subscription dioxus signals.
• For now it implements this system for the message struct in chats.
• Goal is to have a system that allows one to update only a selected set of components without updating the whole state.
• Something to note is that since this only implements it for messages the actual impact will probably not be noticed much since in a lot of places components still subscribe to the generic State in uplink. We will likely only notice it if the whole State uses this system.
  - TODO:
  - [x] Local Subscription system
  - [ ] Wrap needed uplink state fields in LocalSubscription
  - [ ] Change methods in state so they properly subscribe to their correct local subs

Signals are used here just as a wrapper around the actual value. Writing to/Reading from it is simply done via the simple read and write functions. Dioxus will handle updating the correct components

[github-actions]

⚠️ The title of this PR is invalid.
Please make the title match the regex (?:add|update|task|chore|feat|fix)\([a-z-A-Z]+\):\s.+.
e.g.) add(cli): enable --verbose flag, fix(api): avoid unexpected error in handler

[github-actions]

⚠️ The title of this PR is invalid.
Please make the title match the regex (?:add|update|task|chore|feat|fix)\([a-z-A-Z]+\):\s.+.
e.g.) add(cli): enable --verbose flag, fix(api): avoid unexpected error in handler

[github-actions]

⚠️ The title of this PR is invalid.
Please make the title match the regex (?:add|update|task|chore|feat|fix)\([a-z-A-Z]+\):\s.+.
e.g.) add(cli): enable --verbose flag, fix(api): avoid unexpected error in handler

[github-actions]

⚠️ The title of this PR is invalid.
Please make the title match the regex (?:add|update|task|chore|feat|fix)\([a-z-A-Z]+\):\s.+.
e.g.) add(cli): enable --verbose flag, fix(api): avoid unexpected error in handler

[github-actions]

UI Automated Test Results Summary for MacOS/Windows

466 tests   242 ✔️  1h 14m 47s ⏱️
  39 suites  224 💤
    3 files        0 ❌

Results for commit f14a3d9.

♻️ This comment has been updated with latest results.

[github-actions]

UI Automated Tests execution is complete! You can find the test results report here

[sdwoodbury]

this looks almost the same as the implementation of UseSharedState - calling cx.scope_id() and adding that to a list of consumers. How is the new state system different?

[Flemmli97]

this looks almost the same as the implementation of UseSharedState - calling cx.scope_id() and adding that to a list of consumers. How is the new state system different?

The thing with use_stared_state is that it does not support sub components.
If you use use_stared_state you will subscribe to the whole State and any changes in State will cause a rerender for the subscribed component regardless of what was updated.

We can circumvent it by simply splitting State into multiple independent structs and register each of them with use_stared_state but that is hard to manage.

With this we can still mostly keep our current structure.

At the end we would have instead of

State {
  chat: Chats,
  some_other_field: String
}

State {
  chat: LocalSubscription<Chats>,
  some_other_field: String
}

and accessing the local subscription will automatically listen to changes in chat only. If now some_other_field is updated it will not cause a rerender for the component listening to chat

[sdwoodbury]

This looks cool but I'm not sure how much it will help at the moment.

If a message is updated, the messages still need to be grouped and I believe that would still cause a re-render. Fortunately the chats page has been refactored to not store so many messages in memory.

I wonder if this could help in other parts of the codebase. For example - if a friend comes online, it might be nice to not re-render stuff that doesn't include that friend. Still, for stuff like that I have a theory that it may be easier to have a top level element that pulls everything it needs from State and passes it to a child Element via props. That way if State is updated, in theory the child elements may have the same props and if props don't change, the element doesn't get re-rendered. (this is easier said than done because State gets used everywhere).

[Flemmli97]

unless we do it across the whole app (and not just messages) the gain atm isn't really big.
but e.g. editing messages should only update that one message component and not the whole chat

[tooshel]

Closing this for now and we will revisit after the next release of Dioxus.