1907840 - Use a dedicated state for storing the microsurvey prompt state

Status: NEW

(Fenix :: Experimentation and Telemetry, task, P3)

Description

[twhite]

See the review checker ReviewQualityCheckState.kt as an example.

Comment 1

[aorban]

Based on the research I have done, this ticket requires substantial code changes due to the fact how the MicrosurveyBottomSheetFragment is created, how it is using the data in relation to the ReviewQualityCheckFragment.
The latter is using a store which encapsulates the middlewares required and also has a state.

The review quality check feature has it's own dedicated state and action, ReviewQualityCheckState and ReviewQualityCheckAction, which need to be created for the microsurvey feature, to have the same code structure between the features.

The microsurvey MessagingMiddleware uses the AppState and AppAction, which are too generic, and with a new state class, the AppAction.MessagingAction.MicrosurveyAction would be better used, but extracting this would mean having possible regressions, as the MessagingMiddleware uses actions from AppAction too, which would need to be moved to the new MicrosurveyAction.

The new MicrosurveyState class could have a state for the scenario when the microsurvey is disabled, enabled, and it can also have states for the actual survey state, that is, if the user selected an answer, completed the survey which are going to be consumed in the MicrosurveyBottomSheet composable.

The visibility of the MicrosurveyRequestPrompt can also be part of the state, as now inside HomeFragment#listenForMicrosurveyMessage the currentMicrosurvey field indicates if there is a microsurvey to be shown, which will show the prompt composable. This logic currently is outside of the HomeFragment's scope and needs to be abstracted out.