This commit is the foundational step to start using malli
(https://github.com/metosin/malli) in this project.
Take in consideration we will only be able to realize malli's full power in
future iterations.
For those without context: the mobile team watched a presentation about malli
and went through a light RFC to put everyone on the same page, among other
discussions here and there in PRs.
To keep things relatively short:
1. Unit, integration and component tests will short-circuit (fail) when
inputs/outputs don't conform to their respective function schemas (CI should
fail too).
2. Failed schema checks will not block the app from initializing, nor throw an
exception that would trigger the LogBox. Exceptions are only thrown in the
scope of automated tests.
3. There's zero performance impact in production code because we only
instrument. Instrumentation is removed from the compiled code due to the
usage of "^boolean js.goog/DEBUG".
4. We shouldn't expect any meaningful slowdown during development.
**What are we instrumenting in this PR?**
Per our team's agreement, we're only instrumenting the bare minimum to showcase 2 examples.
- Instrument a utility function utils.money/format-amount using the macro
approach.
- Instrument a quo component quo.components.counter.step.view/view using the
functional approach.
Both approaches are useful, the functional approach is powerful and allow us to
instrument anonymous functions, like the ones we pass to subscriptions or event
handlers, or the higher-order function quo.theme/with-theme. The macro approach
is perfect for functions already defined with defn.
**I evaluated the schema or function in the REPL but nothing changes**
- If you evaluate the source function, you need to evaluate schema/=> or
schema/instrument as well.
- Remember to *var quote* when using schema/instrument.
- You must call "(status-im2.setup.schema/setup!)" after any var is
re-instrumented. It's advisable to add a keybinding in your editor to send
this expression automatically to the CLJS REPL, or add the call at the end of
the namespace you are working on (similar to how some devs add "(run-tests)"
at the end of test namespaces).
**Where should schemas be defined?**
For the moment, we should focus on instrumenting quo components, so define each
function schema in the same namespace as the component's public "view" var.
To be specific:
- A schema used only to instrument a single function and not used elsewhere,
like a quo component schema, wouldn't benefit from being defined in a separate
namespace because that would force the developer to constantly open two files
instead of one to check function signatures.
- A common schema reused across the repo, like ":schema.common/theme" should be
registered in the global registry "schema.registry" so that consumers can just
refer to it by keyword, as if it was a built-in malli schema.
- A common schema describing status-go entities like message, notification,
community, etc can be stored either in the respective
"src/status_im2/contexts/*" or registered globally, or even somewhere else.
This is yet to be defined, but since I chose not to include schemas for them,
we can postpone this guideline.
* community home screen updates
* removed green border color on status indicator
* added accent color to plus button and jump-to button
* code reviews
* e2e: fix acc id new comm button
* resolved bugs
---------
Co-authored-by: pavloburykh <pavlo@status.im>
* Dont check app-state for android before routing PN
On Android devices, right after account creation and before a log out, the :app-state value in reframe db is set to background. The value becomes active after a log out and then log in which causes tapping on push notifications to do nothing.
This behaviour breaks E2E and hence in this PR, I remove the checking of this case only for Android platforms.
More work should be done to figure out why the app state event handler is behaving this way on Android but for now I would like to unblock E2E.
* e2e: remove xfailed tests
---------
Co-authored-by: Churikova Tetiana <tatiana@status.im>
- Display Activity Center unread badge with the unread counter.
- Use the new seen state stored in `status-go` to change the color of the
notification.
- Performance: split the `top-nav` component into left and right section
components and render the unread indicator in a separate component to not
trigger the re-render of the entire `top-nav` (as was before).
Fixes https://github.com/status-im/status-mobile/issues/14851
Demo: https://user-images.githubusercontent.com/46027/224299978-770dd5f1-302b-4375-af2b-3cd181ffdc9d.webm
Notes
=====
- Fix/improve: `quo/counter` displayed `NaN` to the user if the input value was
an empty string.
- In Figma, there's a border around the unread indicator. I didn't implement
this because the ideal solution IMO involves changing the `quo/counter`
component a little bit because the width of the component varies according to
the content displayed (1, 9, 99, 100, etc) and I wanted to the right thing in
a separate PR.
Design notes
============
There's an ongoing conversation with the Design team to decide what to do with
the gray indicator on top of the bell icon, since there's little contrast when
it's is in the `seen` state.
Platforms
=========
- Android
- iOS
Steps to test
=============
- Open Status
- Receive one or more notifications in the Home screen and check the unread
indicator is blue and has a counter.
- Open the AC and close it, notice the unread indicator is now in the `seen`
state. You can close the app and re-open and the state is persisted.
- Mark notifications as read/unread at will, check the unread counter is
correct.
Implements swipe actions for notifications with call to action (e.g. pending
contact requests, unverified identity verifications, etc).
Fixes https://github.com/status-im/status-mobile/issues/15118
According to the Design team, the goal is to deliver a consistent experience to
users, so whenever the user sees a notification with buttons, the same actions
can be taken via the swipe buttons.
Note: swipe buttons are using placeholder icons while the Design team works out
which ones to use
Additionally, a bunch of fixes:
- Fix: outgoing pending contact requests were not being removed from the UI when
cancelled.
- Fix: Membership tab not showing unread indicator.
- Fix: dismissed membership notification not marked as read.
- Fix: dismissed membership notification was displaying decline/accept buttons.
Regression came from changes in status-go related to soft deletion of
notifications.
- Fix: incorrect check for the pending state of a contact request.
- Fixed lots of bugs for identity verification notifications, as it was
completely broken. Unfortunately, somebody made lots of changes without
actually testing the flows.
- Add basic error handling and log if accepting, declining or canceling contact
requests fail.
The demo shows an identity verification with swipe actions to reply or decline.
[identity-verification-swipe-to-reply.webm](https://user-images.githubusercontent.com/46027/223565755-b2ca3f68-12e2-4e1e-9e52-edd52cfcc971.webm)
Out of scope: The old quo input is still in use in the identity verification
notification. This will eventually be solved by issue
https://github.com/status-im/status-mobile/issues/14364
### Steps to test
Notifications with one or more buttons (actions) are affected by this change,
because now the user can also swipe left/right to act on them.
- Membership notifications: private group chat. The following PR explains how to
generate them https://github.com/status-im/status-mobile/pull/14785
- Contact requests, and community gated requests to join (Admin tab).
- Identity verifications. I believe the only way to test identity verification
flows at the moment is to use the Desktop app, since initiating the challenge
is not implemented in Mobile yet.
- Mentions and replies don't have new swipe buttons because they don't have call
to action buttons throughout their lifecycle.
Steps to test identity verification flows:
#### Identity verification flow 1
- `A` and `B` are mutual contacts.
- `A` sends a verification request to `B`.
- `A` should not see any notification yet.
- `B` should receive an identity verification notification. `B` can either
decline or reply.
- `B` declines and the status `Declined` is shown instead of buttons.
- `B` can now either swipe to toggle read/unread or swipe delete the
notification.
- `A` should not receive any notification after `A` declined.
#### Identity verification flow 2
- `A` and `B` are mutual contacts.
- `A` sends a verification request to `B`.
- `A` should not see any notification yet.
- `B` should receive an identity verification notification. `B` can either
decline or reply.
- `B` press `Reply` and a bottom sheet is displayed with a text input.
- `B` sends the reply/answer message and the status `Replied` is shown instead
of buttons.
- `B` can now either swipe to toggle read/unread or swipe to delete the
notification.
- `A` should receive a notification with the reply from `B`.
- `A` can either mark the answer as untrustworthy or accept it (trust it) via
the normal buttons, as well as via the swipe left/right buttons.
- If `A` accepts the answer, then the status `Confirmed` is shown instead of
buttons. On the other hand, if `A` marks as untrustworthy, then the status
`Untrustworthy` is shown instead of buttons.
- `B` should receive no further notifications due to `A`s actions.
- `A` can now either swipe to toggle read/unread or swipe delete the
notification.
BalogunofAfrica
Yevheniia Berdnyk
Icaro Motta
Jamie Caprani
Jakub Sokołowski
Dmitri Akatov
yqrashawn
Nikolay
diana
Churikova Tetiana
Lungu Cristian
Tetiana Churikova
flexsurfer
Brian Sztamfater
Omar Basem
Rahul Pratap
John Ngei
Siddarth Kumar
Mohamed Javid
pavloburykh
Alexander
Ajay Sivan