DanyaSWorlD
commented
4 months ago It's an interesting pattern, but as everything in our non perfect world has it's own weakneses. From my understanding of UDF and how it's usually implemented in kotlin, it also have possibility to became a mess. The main point I see is state storage and state to state logic. Bad architecture decisions can сross out all the advantages UDF affords. Also state-to-state logic tetst can easily contain couple of different states, which will make it extreme hard to test.
On other hands, there are still decomposition advantages, and it's defenitely worth a try. But keep in mind, that sometimes it better to not use pattern if it will make a life harder.
I recently experimented with Unidirectional Data Flow (UDF) in a project and was impressed by the resulting code clarity and maintainability. Testing individual composable was much easier and I could preview entire screens. Logic follow was clear and centralized.
Current implementation suffers from scattered logic and difficulty previewing screens. I propose migrating the application to UDF to address these issues.
This would improve code maintainability, simplify testing , preview and provide clearer separation of concerns.