* Add background color to collectibles
* Fix header text animation in unsupported collectibles
* Fix header height and animation color
* Fix image not showing when it's `nil` or `""`
* Add missing border to expanded-collectible
* Fix extra `0` in create/edit account title input
* Validate name, color and emoji in account creation/edition screen
* Refactor sub
* Fix button disabled condition and placeholder
This is a byproduct of the investigation on issue
https://github.com/status-im/status-mobile/issues/20203, more specifically, to
double-check if v1 users have their display names shown correctly.
Closes https://github.com/status-im/status-mobile/issues/20203
This is the scenario used to reproduce the bugs this PR is solving:
1. Alice creates an account in v1 (branch release/1.20.x).
2. Alice had 1 friend to chat with, Carol.
3. Alice sends and receives at least one message from Carol.
4. Alice installs the new app (latest develop branch suffices).
5. Alice login and try to edit her profile, but her 3-word name is not displayed
in the Settings > Edit Profile screen, nor in the Settings > Edit profile >
Name input field.
6. Alice also opens her chat with Carol, but her name appears as a public key
instead of her 3-word name she identifies herself with.
The solution presented here is to just fallback to Alice's 3-word name (name
field in the profile/contact app-db instance).
Areas that may be impacted
- Edit profile name.
- Name displayed in chats from the perspective of the sender who migrated from
v1.
Steps to test
In order to test this PR, it's necessary to migrate from v1 to v2 using two
separate builds. The v1 build can be obtained in PR
https://github.com/status-im/status-mobile/pull/20123. v2 build can be any one
from develop from today, for example.
This commit:
- fixes addresses are displayed without truncation
- fixes network preference (advanced icon) shown for ENS
- fixes navigation on adding a new saved address
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
Introduces a new macro deftest-event to facilitate writing tests for event
handlers. Motivation came from the _problem of having to always extract event
handlers as vars in order to test them_.
Although the implementation of deftest-sub and deftest-event are similar,
deftest-sub is critically important because it guarantees changes in one
subscription can be caught by tests from all other related subscriptions in the
graph (reference: PR https://github.com/status-im/status-mobile/pull/14472).
This is not the case for the new deftest-event macro. deftest-event is
essentially a way of make testing events less ceremonial by not requiring event
handlers to be extracted to vars. But there are a few other small benefits:
- The macro uses re-frame and "finds" the event handler by computing the
interceptor chain (except :do-fx), so in a way, the tests are covering a bit
more ground.
- Slightly easier way to find event tests in the repo since you can just find
references to deftest-event.
- Possibly slightly easier to maintain by devs because now event tests and sub
tests are written in a similar fashion.
- Less code diff. Whether an event has a test or not, there's no var to
add/remove.
- The dispatch function provided by the macro makes reading the tests easier
over time. For example, when we read subscription tests, the Act section of
the test is always the same (rf/sub [sub-name]). Similarly for events, the
Act section is always (dispatch [event-id arg1 arg2]).
- Makes the re-frame code look more idiomatic because it's more common to define
handlers as anonymous functions.
Downside: deftest-sub and deftest-event are relatively complicated macros.
Note: The test suite runs just as fast and clj-kondo can lint code within the
macro just as well.
Before:
```clojure
(deftest process-account-from-signal-test
(testing "process account from signal"
(let [cofx {:db {:wallet {:accounts {}}}}
effects (events/process-account-from-signal cofx [raw-account])
expected-effects {:db {:wallet {:accounts {address account}}}
:fx [[:dispatch [:wallet/get-wallet-token-for-account address]]
[:dispatch
[:wallet/request-new-collectibles-for-account-from-signal address]]
[:dispatch [:wallet/check-recent-history-for-account address]]]}]
(is (match? expected-effects effects)))))
```
After
```clojure
(h/deftest-event :wallet/process-account-from-signal
[event-id dispatch]
(let [expected-effects
{:db {:wallet {:accounts {address account}}}
:fx [[:dispatch [:wallet/get-wallet-token-for-account address]]
[:dispatch [:wallet/request-new-collectibles-for-account-from-signal address]]
[:dispatch [:wallet/check-recent-history-for-account address]]]}]
(reset! rf-db/app-db {:wallet {:accounts {}}})
(is (match? expected-effects (dispatch [event-id raw-account])))))
```
* Fix "Bridge to" screen not showing
* Fix "Unkown flow" alert in bridge flow
* Fix warnings in transaction confirmation page
* Fix missing images and strings while bridging in transaction confirmation page
* Fix stale data shown for an instant in the suggested routes component
* Add support for bridge flow started in the wallet home screen
* Fix fetch-activities event
This commit adds a feature to search through the saved addresses list by name, address, ENS and chain names.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
* Add missing circle in wallet-activity component
* Move activity calculations to subscription and fix wrong data
* Fetch activities when visiting an account
Fixes the slow login when users have joined large communities, such as the
Status one. Related status-go PR
https://github.com/status-im/status-go/pull/5229.
What we mean by "slow" is that the user was getting stuck on the login screen
for almost 20s in some devices (even on iOS things were bad). And this entire
process was happening in status-go, hence most changes come from there.
By "login" we mean the process to authenticate and initialize vital data in
status-go. Setting up message filters can be slow with large communities, and
that's exactly this part we moved out of the login phase in status-go. This step
now happens implicitly when the client calls wakuext_startMessenger.
In a way, the solution makes sense because setting up filters isn't essential
for the user to access other parts of the app, such as the Wallet, Settings,
Profile, and Activity Center.
How can we magically eliminate the login delay? In reality, the time we used to
spent during login, blocking the user, still happens, but it happens in the
background and after the user is redirected to the home screen. This also means
that, until the filters are established, all chats are still in their "loading
skeleton state".
In terms of UX, this is probably fine as long as it doesn't take too long for
this setup to finish in status-go. In the future, we have room to further
optimize how filters are set up in status-go.
Fixes https://github.com/status-im/status-mobile/issues/20059
Shivek Khurana
Jakub Sokołowski
Ulises Manuel
John Ngei
Jamie Caprani
yqrashawn
Volodymyr Kozieiev
Icaro Motta
Alexander
Yevheniia Berdnyk
Omar Basem
Mohamed Javid
Mohsen
Parvesh Monu
flexsurfer
Sean Hagstrom
mmilad75
Siddarth Kumar
Ajay Sivan