Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: [IOCOM-840] Preconditions bottom sheet, new DS #5912

Merged
merged 27 commits into from
Jul 8, 2024

Conversation

Vangaorth
Copy link
Contributor

@Vangaorth Vangaorth commented Jun 27, 2024

Short description

This PR implements the preconditions bottom sheet, with the new DS.

iOS Android
Simulator.Screen.Recording.-.iPhone.15.-.2024-06-27.at.17.30.24.mp4
Screen.Recording.2024-06-27.at.15.37.31.mov

List of changes proposed in this pull request

The preconditions bottom sheet is handled as a state-machine:
state_preconditions
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 Scheduledstate, 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)

@pagopa-github-bot pagopa-github-bot changed the title [IOCOM-840] Preconditions bottom sheet, new DS feat: [IOCOM-840] Preconditions bottom sheet, new DS Jun 27, 2024
@pagopa-github-bot
Copy link
Collaborator

pagopa-github-bot commented Jun 27, 2024

Affected stories

  • 🌟 IOCOM-840: [App] Adattare il bottom sheet delle precondizioni (sia Inbox che Archiviati)
    subtask of
    • IOCOM-810: Adottare il nuovo design system nella Home dei messaggi

Generated by 🚫 dangerJS against af814ae

Copy link

codecov bot commented Jun 27, 2024

Codecov Report

Attention: Patch coverage is 93.37176% with 23 lines in your changes missing coverage. Please review.

Project coverage is 49.64%. Comparing base (4f204b4) to head (af814ae).
Report is 250 commits behind head on master.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #5912      +/-   ##
==========================================
+ Coverage   48.42%   49.64%   +1.21%     
==========================================
  Files        1488     1733     +245     
  Lines       31617    34552    +2935     
  Branches     7669     8378     +709     
==========================================
+ Hits        15311    17152    +1841     
- Misses      16238    17338    +1100     
+ Partials       68       62       -6     
Files Coverage Δ
...eatures/messages/components/Home/Preconditions.tsx 100.00% <100.00%> (ø)
.../messages/components/Home/PreconditionsContent.tsx 100.00% <100.00%> (ø)
...messages/components/Home/PreconditionsFeedback.tsx 100.00% <100.00%> (ø)
...s/messages/components/Home/PreconditionsFooter.tsx 100.00% <100.00%> (ø)
...es/messages/components/Home/PreconditionsTitle.tsx 100.00% <100.00%> (ø)
...essages/components/Home/WrappedMessageListItem.tsx 97.14% <100.00%> (ø)
...econditionBottomSheet/LegacyPreconditionHeader.tsx 60.00% <100.00%> (ø)
ts/features/messages/saga/index.ts 0.00% <ø> (ø)
...s/features/messages/screens/MessagesHomeScreen.tsx 100.00% <ø> (+46.34%) ⬆️
...ssages/screens/legacy/LegacyMessagesHomeScreen.tsx 53.65% <100.00%> (ø)
... and 13 more

... and 845 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bb96fd2...af814ae. Read the comment docs.

@Vangaorth Vangaorth marked this pull request as ready for review July 1, 2024 13:44
@Vangaorth Vangaorth requested a review from a team as a code owner July 1, 2024 13:44
# Conflicts:
#	ts/features/messages/screens/MessagesHomeScreen.tsx
Copy link
Contributor

@forrest57 forrest57 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, tested on both Android and iOS

@Vangaorth Vangaorth merged commit 153b621 into master Jul 8, 2024
13 checks passed
@Vangaorth Vangaorth deleted the IOCOM-840_preconditions branch July 8, 2024 09:34
Vangaorth added a commit that referenced this pull request Jul 9, 2024
… Home (#5935)

⚠️ This PR depends on #5912 ⚠️

## Short description
This PR adds the support for archiving and restoring of user messages,
in the new messages home.

|iOS|Android|
|-|-|
|<video
src="https://github.com/pagopa/io-app/assets/5150343/a5f7a2a9-3c20-4ea6-9f34-ce18f22b7ee9"
/>|<video
src="https://github.com/pagopa/io-app/assets/5150343/025fcc9f-3123-44bf-b45a-b5d4d36cfa4d"
/>|

**_Please note_** that the toast showing "Annullato" has been removed.

## List of changes proposed in this pull request
New archiving/restoring UI and UX. In order to both fix previous
problems and not change a complex business logic, this PR builds above
the latter, keeping the compatibility with the old system (the algorithm
is explained in
`ts/features/messages/saga/handleUpsertMessageStatusAttributes.ts`)

- actions and reducer. The feature is implemented with three states:
- "disabled" | "enabled": the latter displays the bottom CTAs and allows
to select messages for archiving/restoring
- "processing": the system is busy processing the asynchronous
archiving/restoring of messages

Messages are enqueued by Id while in the "enabled" state and processed
one at a time while in "processing" state, in order to properly handle
whatever failure may happen. It also supports cancellation by the user.
If at any moment an error or a cancellation happens, the processing is
suspended, the user is notified but she can later resume it.

- `ArchiveRestoreBar` is the component that displays the bottom CTAs for
archiving/restoring

Since the bottom bar is hidden while picking messages or processing
them, there are some application entry points that have been disabled,
in order not to trigger a flow that may later bring back to another main
screen without the bottom bar. Such flows are deep link following, push
notification tapping, message reloading and next page loading during
processing, first message page loading and message search.

## How to test
Using the io-dev-api-server, make sure to enable both DS and new
messages home. Long tap (and later tap) on some messages and try the
archiving/restoring/cancelling.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants