#high-interest-tech-debt The following [discussion from !120770](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120770#note_1402038455) should be addressed: > I think we should come up with an idea on how to handle these state components in an issue though rather than in a merge request that is trying to use it :sweat_smile: Like there is also the state machine that could also have a `preparing` state right? This issue is to discuss potential architectural decisions, which will likely need to be approached over the course of an epic / multiple issues. Some things to consider: - Not all of the states are based on an actual MR "status" - `preparing` - for example - is a meta-state when the MR doesn't yet **have** a state. - A new architecture should incorporate states that aren't driven by a MR state value - When in various states, the MR widget shows _multiple_ "sub-widgets": like mergeability, pipelines, approvals, etc. - Should these be flattened so the stateful logic has fewer branches, and fewer "super states" that toggle sub-states?