You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Like many new people here, I have been looking for privacy-respecting alternatives to avoid giving away my data to large corporations and hosting my own matrix server seems like the way to go. Commet caught my eye because of its similarity to Discord, which will make migration much easier for my friends.
That being said, I have been playing around with the app and looked through the code on GitHub a bit. I happen to also be a Flutter dev myself, and it got me wondering... Why use Provider instead of Riverpod?
I realized there are a few quirks with the current state management. For example, leaving channels or updating a server image requires a full client restart (especially if two clients are running simultaneously on two devices) for the UI to actually reflect the new state (at least on Android, I haven't had the chance to test the Linux client yet but I don't see why it would behave any differently). I remember when our team used Provider a few years ago now, we’d spend more time trying to work around its limitations than actually solving problems. I’d be interested to find out why it was chosen over Riverpod, especially given Riverpod's ability to natively watch asynchronous streams and dynamically update the UI without these sync issues.
I know migrating to Riverpod would be a major refactor. However, I wanted to gauge the interest first to see how the maintainers feel about it. I haven't actually cloned the repo yet to see if the current providers are flat or deeply entangled anyway, only browsed it on GitHub. I also wanted to ask if Riverpod was considered previously and if the team concluded that it just didn't fit the architecture.
Since Riverpod was created by the same developer as Provider specifically with large codebase transitions in mind, the migration could be done gradually alongside the existing setup as they do not conflict. I would be more than happy to help over the long term by starting off with some low-risk, leaf-node providers to test the waters.
This project is much bigger than what I am used to (I mainly work on direct live database data type mobile apps rather than instant messaging across platforms), but it sounds like a fun challenge. Unfortunately I wouldn't be able to help full time due to work and studies but hey. Looking forward to hearing your thoughts!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Hey all,
Like many new people here, I have been looking for privacy-respecting alternatives to avoid giving away my data to large corporations and hosting my own matrix server seems like the way to go. Commet caught my eye because of its similarity to Discord, which will make migration much easier for my friends.
That being said, I have been playing around with the app and looked through the code on GitHub a bit. I happen to also be a Flutter dev myself, and it got me wondering... Why use Provider instead of Riverpod?
I realized there are a few quirks with the current state management. For example, leaving channels or updating a server image requires a full client restart (especially if two clients are running simultaneously on two devices) for the UI to actually reflect the new state (at least on Android, I haven't had the chance to test the Linux client yet but I don't see why it would behave any differently). I remember when our team used Provider a few years ago now, we’d spend more time trying to work around its limitations than actually solving problems. I’d be interested to find out why it was chosen over Riverpod, especially given Riverpod's ability to natively watch asynchronous streams and dynamically update the UI without these sync issues.
I know migrating to Riverpod would be a major refactor. However, I wanted to gauge the interest first to see how the maintainers feel about it. I haven't actually cloned the repo yet to see if the current providers are flat or deeply entangled anyway, only browsed it on GitHub. I also wanted to ask if Riverpod was considered previously and if the team concluded that it just didn't fit the architecture.
Since Riverpod was created by the same developer as Provider specifically with large codebase transitions in mind, the migration could be done gradually alongside the existing setup as they do not conflict. I would be more than happy to help over the long term by starting off with some low-risk, leaf-node providers to test the waters.
This project is much bigger than what I am used to (I mainly work on direct live database data type mobile apps rather than instant messaging across platforms), but it sounds like a fun challenge. Unfortunately I wouldn't be able to help full time due to work and studies but hey. Looking forward to hearing your thoughts!
All reactions