* Fix schema error
* Implement feature to edit shared addresses
* fix: show tokens when sharing all future addresses toggled
* fix: eligibility not checked when toggling all addresses
* Revert "fix: show tokens when sharing all future addresses toggled"
This reverts commit 8443a3432e.
* fix: don't fetch balances on mount if toggled share all
---------
Co-authored-by: Cristian Lungu <lungucristian95@gmail.com>
chore: create profile-picture schema with profile-picture-fn field
fix: update context-tag schema to allow for profile-picture-fn
tidy: move profile-picture schema into the common schema namespaces
tidy: revise docs for user-avatar-internal component to mainly warn about `profile-picture-fn` usage
tidy: rename `profile-picture` schema to `profile-picture-source`
tidy: use profile-picture-source schema in user-avatar schema
Show "relevant tokens" in account selection step. Related status-go PR
https://github.com/status-im/status-go/pull/4631.
- Balances are fetched on the account selection screen. Assuming most users
won't care about selecting addresses, this eliminates unnecessary calls to get
balances, at the expense of refetching them every time the component is
mounted. I think for now this is acceptable.
- Relevant tokens is a terminology used in Figma, but more specifically, it
means "balances for all assets that have at least one Token Criteria
associated, and for a given address". Or, as I tried to give it a more
distinct name, "permissioned balances".
Areas that may be impacted: None because all affected code is behind a disabled
feature flag.
Fixes https://github.com/status-im/status-mobile/issues/18126
* fix: generate_profile_url.cljs$core$IFn$_invoke$arity$2 crash when login
'status_im.common.universal_links.generate_profile_url.cljs$core$IFn$_invoke$arity$2' is undefined
update the function to a fixed arity function
* fix: schema/=> macro for :function schema
Signed-off-by: yqrashawn <namy.19@gmail.com>
---------
Signed-off-by: yqrashawn <namy.19@gmail.com>
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.
yqrashawn
Icaro Motta
Lungu Cristian
Sean Hagstrom
mmilad75
Ajay Sivan