Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: [IOCOM-840] Preconditions bottom sheet, new DS (#5912)
## Short description This PR implements the preconditions bottom sheet, with the new DS. |iOS|Android| |-|-| |<video src="https://github.com/pagopa/io-app/assets/5150343/c0f2d650-c75b-4fb3-9d9a-bdbc939d04cf" />|<video src="https://github.com/pagopa/io-app/assets/5150343/e542305e-0979-4114-add3-fda8ca20f0bf" />| ## List of changes proposed in this pull request The preconditions bottom sheet is handled as a state-machine: ![state_preconditions](https://github.com/pagopa/io-app/assets/5150343/94104365-9a1e-4dbc-abb9-3055df747a97) The `messagePrecondition` reducer implements the state machine, using the `preconditions` actions to switch from one state to another (if allowed). - States: - `Idle`: in this status, the bottom sheet is not shown nor loaded; - `Scheduled`: in this status, some actor has requested to show the bottom sheet (but it is not visible yet). `WrappedMessageListItem` is the component that dispatches the `scheduledPreconditionStatusAction` while `Preconditions` component uses an `useEffect` hook to detect the status and request the switch to either `Update Required` or `Retrieving data`; - `Update Required`: this status is used to inform the user about an unsupported app version that needs to be updated. At the moment, it is triggered when the selected message is a SEND one. The bottom sheet is shown and the user can either dismiss it or navigate to the store to update the application; - `Retrieving Data`: in this status, the application is retrieving the precondition data from server. The bottom sheet is shown and it displays a progress skeleton; - `Loading Content`: in this status, precondition data has been retrieved and the markdown component is loading the precondition content. The bottom sheet is shown and it displays a progress skeleton; - `Shown`: in this status, the bottom sheet is shown, it displays the precondition title and markdown and the footer displays both `cancel` and `continue` button - `Error`: this status is triggered if data retrieval from server fails or if markdown loading fails. The bottom sheet is shown, it displays a generic error message. No footer is shown so the user can just dismiss the bottom sheet using its cancelling mechanism (closing button on top, swipe gesture, backdrop tap or the physical back button on Android) - Actions: - `errorPreconditionStatusAction`: switches to the `Error` status. Valid source states are `Retrieving Data` and `Loading Content`. If received in any other state, it is ignored; - `idlePreconditionStatusAction`: switches to the `Idle` status. Valid source states are all but `Scheduled` (this transition maps either an end-of-flow or a cancelling from the user); - `loadingContentPreconditionStatusAction`: switches to the `Loading Content` status. Valid source state is `Retrieving Data`. If received in any other state, it is ignored; - `retrievingDataPreconditionStatusAction`: switches to the `Retrieving Data` status. Valid source states is `Scheduled` and `Error`. If received in any other state, it is ignored. The switch from `Error` to `Retrieving Data` is supported but it is not available from the UI so at the moment it never happens; - `scheduledPreconditionStatusAction`: switches to the `Scheduled` status. Valid source state is `Idle`. If received in any other state, it is ignored; - `shownPreconditionStatusAction`: switches to the `Shown` status. Valid source state is `Loading Content`. If received in any other state, it is ignored; - `updateRequiredPreconditionStatusAction`: switches to the `Update Required` status. Valid source state is `Scheduled`. If received in any other state, it is ignored; - UI Components: - `Preconditions`: the bottom sheet wrapper entry point. It creates the bottom sheet, links other preconditions component and detects the `Scheduled`state, in order to trigger the bottom-sheet opening. - `PreconditionsTitle`: computes and displays the bottom sheet title, based on the state machine status (sometimes it displays an empty view in order for margin to be computed properly); - `PreconditionsContent`: computes and displays the bottom sheet markdown, based on the state machine status - `PreconditionsFooter`: computes and displays the bottom sheet CTAs. Apart from an empt view (used in order for margins to be computed properly), it either displays the `Cancel` + `Update` buttons (`Update Required` state) or the `Cancel` + `Continue` buttons (`Shown` state); - `PreconditionsFeedback`: common component linked inside `PreconditionsContent` to display either an error or the update required message. The main idea behind the switch from the `Idle` to the `Scheduled` state is to decouple the actor that requires the displaying from the actual displaying of the bottom sheet. Up to this PR, only a tap on a single message on the message list can open the bottom sheet but in the future, it is going to be opened from other entry points (like a push notification). ## How to test - Using the io-dev-api-server, generate a SEND message. Select it and check that the bottom sheet appears. - Using the io-dev-api-server, set the SEND minimum version to something greater that 2.63. Generate a SEND message, select it and check that the bottom sheet appears with the required update CTAs. - Using the io-dev-api-server, change the message generation code that computes the hasPreconditions flag so that it always returns true. Also change the preconditions endpoint as to return preconditions for any message. Select a non SEND message and check that the bototm sheet appears (minimum app version is checked only for SEND messages)
- Loading branch information