This commit rewrites utils.re-frame/delay-render to use hooks. The new
implementation renders significantly better than what we have today, at least on
Android.
Why not hiccup instead of a function call to delay-render? The Settings screen
is rendered slightly faster if I use delay-render as a function call instead of
hiccup. My only guess is that this is just less work to be done by Reagent,
since the wrapper function is not creating a wrapper component with its own
lifecycle.
The full analysis can be found here, but it's copied for future reference:
--------------------------------------------------------------------------------
Based on my analysis of individual frames being rendered and having investigated
3 different scenarios:
1. Scenario 1: No delay whatsoever, i.e. not using `delay-render`.
2. Scenario 2: Using `delay-render` like in `develop`, that is, a form-2
component with a local Reagent atom.
3. Scenario 3: Using `delay-render` as in this PR, using hooks.
All 3 scenarios open the Settings screen with all rendered views in the same
amount of time. In terms of raw performance, they are completely identical. The
absolute value doesn't matter, but in my recordings, on average, 10 frames of
video after the first press on the user's profile image.
So how can it be that on Android the new solution is visibly smoother? It's all
about latency and our brains are very picky about it.
Scenario 1 - Not using delay-render: the user notices a longer delay after
pressing on the profile image because all components in the Settings screen are
mounted in one go. This gives the impression to the user of being slower. In
slower Android devices, we've seen a user even press twice because the Settings
screen was taking longer to open. On newer Android devices this is not much of a
problem. There's another problem in `Scenario 1`, on Android, with too many
elements and/or too many heavy elements being mounted, the opening animation is
sometimes completely cut off or very clunky (a similar problem can happen while
opening the Activity Center).
Scenario 2 - Use delay-render with a form-2 component: The Settings items are
always rendered after the opening animation completes. Our brains perceive this
as a slight delay because we can see the empty gray background for 1-3 frames.
This is quite noticeable on my physical Android device, even with a prod build.
Scenario 3 - Use delay-render as a hook: the optimal solution from the user's
perspective, Settings items sometimes can be rendered before the animation
completes. I say sometimes because other times the items are rendered only 1
frame before or right when the animation completes, which would be almost the
same as Scenario 2.
What the hooks solution gave us is a little bit of the Scenario 1 and
Scenario 2 in one package, and because the Settings items can be sometimes
rendered before the opening animation completes, our brains see that as being
faster.
In future performance investigations, we might want to focus on manipulating
latency more aggressively to see where that leads us.
Some devs reported invalid schemas in the develop branch during app
initialization. We knew this could happen when Malli was first
introduced, but we wanted to play safe in the beginning due to the
overall inexperience of the team with Malli.
This commit removes all guardrails on instrumented vars, i.e. during app
initialization the app will crash on any invalid schema. A reminder that
instrumentation only take effect when js/goog.DEBUG is true.
* chore: add "key pairs and accounts" label
* chore: feature flag wallet-settings
* tidy: extact navigate-back function into static defn
* wip: add initial keypairs and accounts list view to wallet settings
* tweak: wire-up initial action menu for key-pairs
* tidy: extract key-pair container styles into style namespace
* tweak: fix dark background for key-pair and account settings
* tidy: refactor on-press handler for key-pair options
* fix: move feature-flag usage to settings screen instead of settings items definition
* tidy: remove unneeded key props
* tidy: clean up de-structuring and passing of props
* tidy: use keep with when expressions instead of filter and map expressions
* tidy: rename the wallet-settings feature flag
* tweak: rename and add feature-flags for mobile wallet settings
* tweak: use scrollview for feature-flags and add spacing between feature-flag groups
* tweak: adjust the way feature-flags are displayed in groups
* tidy: remove unneeded prop
* tidy: use bottom-inset for padding key-pair and accounts list
* tidy: change `filterv` to `filter`
* tidy: use subscription for building account-props
* tidy: use subscription to build the entire keypair-account
* tweak: use key-pair type to determine default key-pair
* tidy: rename component to settings-category-view
* tidy: use assoc instead of merge
* tidy: extract function from subscription
* test: add tests for formatting key-pairs and accounts for wallet settings
* tweak: use `match?` instead of `=`
* tidy: use `swap!` without anonymous functions
This commit improves in-app feature flags to persist what is currently only
stored in a Reagent atom by using RN Async Storage
https://reactnative.dev/docs/asyncstorage. This should make them more convenient
to use, which is a good thing overall for developers.
Additionally, there's now a top-right button in screen Settings > Feature Flags
that will reset the flags to the initial values obtained from environment
variables.
These in-app feature flags are exclusively available in debug builds in
Settings > Feature Flags, and only visible when flag ENABLE_QUO_PREVIEW is
enabled. There's no impact whatsoever in prod builds. A reminder that they are
not meant to be used by users (yet).
It's worth noting that RN has deprecated Async Storage and now recommends other
community solutions, but for a dev-only feature, I think it's fine.
Detailed explanation:
The schema failure is due to utils.image-server/get-initials-avatar-uri being
called with a nil profile customization color right after the user confirms
logout.
Right after logging out, the subscription :profile/profile-with-image is
recomputed. One of its signal inputs is :profile/profile. Right after logout,
the output of sub :profile/profile is always nil (this is correct, nobody is
logged in). This means that the sub :profile/profile-with-image will try to
calculate the multiaccount URI by passing a nil profile. This is wasteful
computation and is also the cause of the schema for
utils.image-server/get-initials-avatar-uri to fail, because it expects the
profile's customization-color to be present.
* tweak: refactor image-uri helpers
* fix: add `:primary` as customization color for profile images
primary is being used as the default color for accounts that were migrated without customization color to a default color
* tweak: add support for displaying channel qr codes with quo/share-qr-code component
* chore: add channel qr-code example to quo preview components
* tweak: integrate common/qr-code component for sharing community channel qr-code
* tweak: add support for showing community channel avatar in share-qr-code header
* tweak: hide wallet tabs for channel qr-code
* tweak: integrate share handler for community channel qr-code
* fix: prevent accidentally rendering the community channel qr-code with nil while closing the share-qr modal
* tidy: extract navigate-back dispatch function
* tidy: use styles namespace
* tidy: use case statement to determine which qr-code components have a header
* tweak: check for share-qr-types that support headers
* tidy: extract navigate-back into static function
* fix: prevent community qr-code from glitching when closing modal
* fix: ensure :communities/share-community-url-with-data is defined
* fix: ensure we show the share-sheet when pressing the community share-action
* fix: ensure we use the correct share-sheet title when sharing a community
* e2e: updated inviting contacts to community flow
* tweak: remove extra url message when sharing community url on android
* tweak: remove extra url message when sharing community channel url on android
* tidy: remove redundant event handler for sharing community url
---------
Co-authored-by: Yevheniia Berdnyk <ie.berdnyk@gmail.com>
