add articles folder

Update doc/ui-guidelines.md
Co-authored-by: Siddarth Kumar <siddarthkay@gmail.com>
2024-04-12 15:56:28 +01:00 · 2024-04-12 15:56:28 +01:00 · 2024-04-12 15:56:28 +01:00 · 2024-04-12 15:56:28 +01:00 · 2024-04-12 15:56:28 +01:00 · 2024-04-12 15:56:28 +01:00
1554 changed files with 25374 additions and 46896 deletions
@@ -1,5 +1,4 @@
 {:config-paths ["status-im"]
- :output       {:exclude-files ["src/user.cljs" "src/dev/user.cljs"]}
 :lint-as      {legacy.status-im.utils.views/defview clojure.core/defn
                legacy.status-im.utils.views/letsubs clojure.core/let
                reagent.core/with-let                clojure.core/let
@@ -10,16 +9,12 @@
                legacy.status-im.utils.styles/def    clojure.core/def
                legacy.status-im.utils.styles/defn   clojure.core/defn
                test-helpers.unit/deftest-sub        clojure.core/defn
-                test-helpers.unit/deftest-event      clojure.core/defn
-
                taoensso.tufte/defnp                 clojure.core/defn}
 :linters      {:case-duplicate-test           {:level :error}
                :case-quoted-test              {:level :error}
                :case-symbol-test              {:level :error}
                :clj-kondo-config              {:level :error}
                :cond-else                     {:level :error}
-                :condition-always-true         {:level :error}
-                :conflicting-alias             {:level :error}
                :consistent-alias              {:level   :error
                                                :aliases {clojure.set             set
                                                          clojure.string          string
@@ -47,13 +42,11 @@
                :missing-body-in-when          {:level :error}
                :missing-clause-in-try         {:level :error}
                :missing-else-branch           {:level :error}
-                :multiple-async-in-deftest     {:level :error}
                :not-empty?                    {:level :error}
                :plus-one                      {:level :error}
                :redundant-do                  {:level :error}
                :redundant-let                 {:level :error}
                :refer-all                     {:level :error}
-                :shadowed-fn-param             {:level :error}
                :shadowed-var                  {:level   :error
                                                ;; We temporarily use :include to define an
                                                ;; allowlist of core Clojure vars. In the
@@ -61,11 +54,9 @@
                                                ;; vars, we should be able to delete this
                                                ;; option and lint all vars.
                                                :exclude [type name]}
-                :self-requiring-namespace      {:level :error}
                :single-operand-comparison     {:level :error}
                :syntax                        {:level :error}
                :unbound-destructuring-default {:level :error}
-                :underscore-in-namespace       {:level :error}
                :uninitialized-var             {:level :error}
                :unknown-require-option        {:level :error}
                :unreachable-code              {:level :error}
@@ -74,8 +65,7 @@
                ;; https://github.com/borkdude/clj-kondo/issues/867
                :unresolved-symbol             {:exclude [PersistentPriorityMap.EMPTY
                                                          number
-                                                          legacy.status-im.test-helpers/restore-app-db
-                                                          (cljs.test/is [match-strict?])]}
+                                                          legacy.status-im.test-helpers/restore-app-db]}
                :unresolved-var                {:level :error}
                :unsorted-required-namespaces  {:level :error}
                :unused-alias                  {:level :warning}
@@ -1,21 +0,0 @@
-(ns cljs.test
-  (:require [clj-kondo.hooks-api :as hooks]))
-
-(defn deftest
-  "Verify test name passed to `cljs.test/deftest` is suffixed with -test and not
-  prefixed with test-."
-  [{:keys [node]}]
-  (let [[_ test-name-node & _] (:children node)
-        test-name              (str (hooks/sexpr test-name-node))]
-    (when (and (hooks/token-node? test-name-node)
-               (or (not (re-find #"^.*-test$" test-name))
-                   (re-find #"^test-.*$" test-name)))
-      (hooks/reg-finding! (assoc (meta test-name-node)
-                                 :message "Test name should be suffixed with -test"
-                                 :type    :status-im.linter/inconsistent-test-name)))))
-
-(comment
-  ;; Invalid
-  (deftest {:node (hooks/parse-string "(deftest foo-tes (println :hello))")})
-  (deftest {:node (hooks/parse-string "(deftest test-foo-test (println :hello))")})
-)
@@ -4,8 +4,5 @@
   test-helpers.component/get-all-by-translation-text   utils.i18n/label
   test-helpers.component/get-by-translation-text       utils.i18n/label
   test-helpers.component/query-all-by-translation-text utils.i18n/label
-   test-helpers.component/query-by-translation-text     utils.i18n/label
-
-   cljs.test/deftest                                    cljs.test/deftest}}
- :linters {:status-im.linter/invalid-translation-keyword {:level :error}
-           :status-im.linter/inconsistent-test-name      {:level :error}}}
+   test-helpers.component/query-by-translation-text     utils.i18n/label}}
+ :linters {:status-im.linter/invalid-translation-keyword {:level :error}}}
@@ -4,6 +4,7 @@ DEFAULT_NETWORK=mainnet_rpc
 DEV_BUILD=1
 ETHEREUM_DEV_CLUSTER=1
 EXTENSIONS=0
+FLEET=status.prod
 GROUP_CHATS_ENABLED=1
 LOG_LEVEL=info
 MAILSERVER_CONFIRMATIONS_ENABLED=1
@@ -25,6 +26,7 @@ APN_TOPIC=im.status.ethereum.pr
 COMMUNITIES_ENABLED=1
 DATABASE_MANAGEMENT_ENABLED=1
 DELETE_MESSAGE_ENABLED=1
+COLLECTIBLES_ENABLED=1
 COMMANDS_ENABLED=1
 TWO_MINUTES_SYNCING=1
 SWAP_ENABLED=1
@@ -33,6 +35,4 @@ LOCAL_PAIRING_ENABLED=1
 TEST_STATEOFUS=1
 FAST_CREATE_COMMUNITY_ENABLED=1
 TEST_NETWORKS_ENABLED=1
-SHOW_NOT_IMPLEMENTED_FEATURES=0
-ENABLE_ALERT_BANNER=0
-FLAG_WALLET_CONNECT_ENABLED=1
+SHOW_NOT_IMPLEMENTED_FEATURES=1
@@ -2,7 +2,7 @@ DEBUG_WEBVIEW=1
 DEFAULT_NETWORK=goerli_rpc
 ETHEREUM_DEV_CLUSTER=1
 EXTENSIONS=0
-FLEET=status.staging
+FLEET=status.prod
 GROUP_CHATS_ENABLED=1
 LOG_LEVEL=debug
 MAILSERVER_CONFIRMATIONS_ENABLED=0
@@ -35,8 +35,3 @@ LOCAL_PAIRING_ENABLED=1
 FAST_CREATE_COMMUNITY_ENABLED=1
 TEST_NETWORKS_ENABLED=1
 SHOW_NOT_IMPLEMENTED_FEATURES=1
-DELETE_MESSAGE_FOR_ME_UNDO_TIME_LIMIT=10000
-DELETE_MESSAGE_UNDO_TIME_LIMIT=10000
-ENABLE_ALERT_BANNER=0
-FLAG_WALLET_CONNECT_ENABLED=1
-MOBILE_DATA_SYNCING_TOGGLE_ENABLE=0
@@ -3,6 +3,7 @@ DEBUG_WEBVIEW=1
 DEFAULT_NETWORK=goerli_rpc
 ETHEREUM_DEV_CLUSTER=1
 EXTENSIONS=0
+FLEET=status.prod
 GROUP_CHATS_ENABLED=1
 LOG_LEVEL=debug
 MAILSERVER_CONFIRMATIONS_ENABLED=1
@@ -35,5 +36,4 @@ STICKERS_TEST_ENABLED=1
 LOCAL_PAIRING_ENABLED=1
 FAST_CREATE_COMMUNITY_ENABLED=1
 TEST_NETWORKS_ENABLED=1
-ENABLE_ALERT_BANNER=1
-FLAG_WALLET_CONNECT_ENABLED=1
+SHOW_NOT_IMPLEMENTED_FEATURES=1
@@ -2,6 +2,7 @@ DEBUG_WEBVIEW=1
 DEFAULT_NETWORK=mainnet_rpc
 ETHEREUM_DEV_CLUSTER=1
 EXTENSIONS=0
+FLEET=status.prod
 GROUP_CHATS_ENABLED=1
 LOG_LEVEL=info
 MAILSERVER_CONFIRMATIONS_ENABLED=1
@@ -22,5 +23,3 @@ DATABASE_MANAGEMENT_ENABLED=1
 DELETE_MESSAGE_ENABLED=1
 FAST_CREATE_COMMUNITY_ENABLED=0
 TEST_NETWORKS_ENABLED=0
-ENABLE_ALERT_BANNER=1
-FLAG_WALLET_CONNECT_ENABLED=1
@@ -2,6 +2,7 @@ DEBUG_WEBVIEW=0
 DEFAULT_NETWORK=mainnet_rpc
 ETHEREUM_DEV_CLUSTER=0
 EXTENSIONS=0
+FLEET=status.prod
 GROUP_CHATS_ENABLED=1
 LOG_LEVEL=
 MAILSERVER_CONFIRMATIONS_ENABLED=1
@@ -17,7 +18,6 @@ PARTITIONED_TOPIC=0
 ENABLE_ROOT_ALERT=1
 MAX_IMAGES_BATCH=1
 DELETE_MESSAGE_ENABLED=1
+COLLECTIBLES_ENABLED=1
 FAST_CREATE_COMMUNITY_ENABLED=0
 TEST_NETWORKS_ENABLED=0
-STATUS_PROXY_STAGE_NAME=prod
-FLAG_WALLET_CONNECT_ENABLED=1
@@ -1,8 +1,8 @@
 ---
-name: Bug Report
-about: Bug Report
+name: MVPBug Report
+about: MVPBug Report
 title: ''
-labels: ['bug', ':1234: low prio']
+labels: 'E:Mobile Bug MVP'
 assignees: ''

 ---
@@ -70,19 +70,3 @@ Documentation change PR (review please): https://github.com/status-im/status.im/
 | Please embed Image/Video here of the before and after.  | Please embed Image/Video here of the before and after.  | Please embed Image/Video here of the before and after. |

 status: ready <!-- Can be ready or wip -->
-
-<!-- Uncomment this section for status-go upgrade/dogfooding pull requests
-
- Specify potentially impacted user flows in _Areas that maybe impacted*.
- Ensure that _Steps to test_ is filled in.
-
-### Risk
-
-Described potential risks and worst case scenarios.
-
-Tick **one**:
- [ ] Low risk: 2 devs MUST perform testing as specified above and attach their results as comments to this PR **before** merging.
- [ ] High risk: QA team MUST perform additional testing in the specified affected areas **before** merging.
-
-
-->
@@ -83,9 +83,6 @@ shim.js
 figwheel_server.log
 .nrepl-port

-# FlowStorm (Clojure debugger)
-repl-client-debug
-
 # Lein
 #
 .lein-failures
@@ -130,8 +127,6 @@ fastlane/README.md
 # Clj

 .cpcache/
-src/user.cljs
-src/dev/user.cljs

 # emacs
 .dir-locals.el
@@ -1,15 +1,10 @@
-/*
-
-# Format top-level js files.
+*
 !*.js
-
-# Ignore all except src/js/**/*.js
-!/src/
-/src/*
-!/src/js
-!/src/js/**/*.js
-
-# Ignore all except translations/en.json
-!/translations/
-/translations/*
-!/translations/en.json
+!*/
+*.clj-kondo
+*.shadow-cljs
+modules
+result
+target
+component-spec
+/app
@@ -6,8 +6,4 @@ module.exports = {
  tabWidth: 2,
  trailingComma: 'all',
  useTabs: false,
-
-  // JSON sorting
-  jsonSortOrder: '{ "/.*/": "caseInsensitiveLexical" } ',
-  plugins: ['prettier-plugin-sort-json'],
 };
@@ -41,7 +41,6 @@
  "reg-fx"            :arg1-pair
  "testing"           :arg1-body
  "deftest-sub"       :arg1-body
-  "deftest-event"     :arg1-body
  "test-async"        :arg1-body
  "wait-for"          :arg1-body
  "with-deps-check"   :arg1-body
@@ -32,7 +32,7 @@ ifndef BUILD_TAG
 export BUILD_TAG := $(shell git rev-parse --short HEAD)
 endif

-# We don't want to use /run/user/$UID because it runs out of space too easily.
+# We don't want to use /run/user/$UID because it runs out of space too easilly.
 export TMPDIR = /tmp/tmp-status-mobile-$(BUILD_TAG)
 # This has to be specified for both the Node.JS server process and the Qt process.
 export REACT_SERVER_PORT ?= 5001
@@ -139,7 +139,7 @@ _install-hooks: ##@prepare Create prepare-commit-msg git hook symlink

 # Remove directories and ignored files
 clean: SHELL := /bin/sh
-clean: _fix-node-perms _tmpdir-rm ios-clean android-clean ##@prepare Remove all output folders
+clean: _fix-node-perms _tmpdir-rm ##@prepare Remove all output folders
 	git clean -dXf

 # Remove directories, ignored and non-ignored files
@@ -196,10 +196,6 @@ xcode-clean: XCODE_HOME := $(HOME)/Library/Developer/Xcode
 xcode-clean: ##@prepare Clean XCode derived data and archives
 	rm -fr $(XCODE_HOME)/DerivedData/StatusIm-* $(XCODE_HOME)/Archives/*/StatusIm*

-ios-simulator-cache-clean: SHELL := /bin/sh
-ios-simulator-cache-clean: ##@prepare Clean iOS Simulator Caches
-	rm -rf ~/Library/Developer/CoreSimulator/Cache
-
 #----------------
 # Release builds
 #----------------
@@ -215,13 +211,15 @@ build-fdroid: ##@build Build release for F-Droid
 build-android: export BUILD_ENV ?= prod
 build-android: export BUILD_TYPE ?= nightly
 build-android: export ORG_GRADLE_PROJECT_versionCode ?= $(TMP_BUILD_NUMBER)
+build-android: export ANDROID_ABI_SPLIT ?= false
+build-android: export ANDROID_ABI_INCLUDE ?= armeabi-v7a;arm64-v8a;x86
 build-android: ##@build Build unsigned Android APK
 	@scripts/build-android.sh

 release-android: export TARGET := keytool
 release-android: export KEYSTORE_PATH ?= $(HOME)/.gradle/status-im.keystore
 release-android: keystore build-android ##@build Build signed Android APK
-	@scripts/sign-android.sh result/app-arm64-v8a-release-unsigned.apk
+	@scripts/sign-android.sh result/app-release-unsigned.apk

 release-ios: export TARGET := ios
 release-ios: export IOS_STATUS_GO_TARGETS := ios/arm64
@@ -315,7 +313,7 @@ lint: ##@test Run code style checks
 	scripts/lint/translations.clj && \
 	zprint '{:search-config? true}' -sfc $$ALL_CLOJURE_FILES && \
 	sh scripts/lint/trailing-newline.sh && \
-	node_modules/.bin/prettier --check .
+	node_modules/.bin/prettier --write .

 # NOTE: We run the linter twice because of https://github.com/kkinnear/zprint/issues/271
 lint-fix: export TARGET := clojure
@@ -351,17 +349,15 @@ test: export SHADOW_NS_REGEXP := .*-test$$
 test: ##@test Run all Clojure tests
 test: _test-clojure

-# Note: we need to override the :output-to and :ns-regexp options because
-# shadow-cljs has a bug where it will not read from the env vars to expand the
-# configuration when the shadow-cljs mobile target is already running.
-test-watch-for-repl: export TARGET := default
 test-watch-for-repl: export SHADOW_OUTPUT_TO := target/test/test.js
 test-watch-for-repl: export SHADOW_NS_REGEXP := .*-test$$
+test-watch-for-repl: status-go-library
 test-watch-for-repl: ##@test Watch all Clojure tests and support REPL connections
-	rm -f "$$SHADOW_OUTPUT_TO" && \
-	yarn install && shadow-cljs compile mocks && \
+	yarn node-pre-gyp rebuild
+	rm -f target/test/test.js
+	yarn shadow-cljs compile mocks && \
 	concurrently --kill-others --prefix-colors 'auto' --names 'build,repl' \
-		"yarn shadow-cljs watch test --verbose --config-merge '{:output-to \"$(SHADOW_OUTPUT_TO)\" :ns-regexp \"$(SHADOW_NS_REGEXP)\"}'" \
+		'yarn shadow-cljs watch test --verbose' \
 		"until [ -f $$SHADOW_OUTPUT_TO ] ; do sleep 1 ; done ; node --require ./test-resources/override.js $$SHADOW_OUTPUT_TO --repl"

 test-unit: export SHADOW_OUTPUT_TO := target/unit_test/test.js
@@ -403,17 +399,6 @@ test-component: ##@test Run component tests once in NodeJS
 	yarn shadow-cljs compile component-test && \
 	jest --clearCache && jest --config=test/jest/jest.config.js --testEnvironment node

-# Reference: https://flow-storm.github.io/flow-storm-debugger/user_guide.html#_debugging_react_native_applications
-run-flow-storm: export SHADOW_CLJS_BUILD_ID := :mobile
-run-flow-storm: export TARGET := clojure
-run-flow-storm: export GDK_DPI_SCALE := 1.0
-run-flow-storm: ##@run Start FlowStorm debugger
-	clj -Sforce -Sdeps '{:deps {com.github.jpmonettas/flow-storm-dbg {:mvn/version "3.7.5"}}}' \
-		-X flow-storm.debugger.main/start-debugger \
-		:port 7888 \
-		:repl-type :shadow \
-		:build-id $(SHADOW_CLJS_BUILD_ID)
-
 #--------------
 # Other
 #--------------
@@ -424,48 +409,25 @@ geth-connect: ##@other Connect to Geth on the device
 	build/bin/geth attach http://localhost:8545

 ios-clean: SHELL := /bin/sh
-ios-clean: ios-simulator-cache-clean
 ios-clean: ##@prepare Clean iOS build artifacts
 	git clean -dxf -f target/ios

-android-clean: SHELL := /bin/sh
+android-clean: export TARGET := gradle
 android-clean: ##@prepare Clean Gradle state
 	git clean -dxf -f ./android/app/build; \
-	rm -rf android/.gradle \
-	rm -rf android/build \
-	rm -rf ~/.gradle
+	[[ -d android/.gradle ]] && cd android && ./gradlew clean

-
-android-ports: export FLOWSTORM_PORT ?= 7722
 android-ports: export TARGET := android-sdk
-android-ports: export RCT_METRO_PORT ?= 8081
 android-ports: ##@other Add proxies to Android Device/Simulator
-	adb reverse tcp:$(RCT_METRO_PORT) tcp:$(RCT_METRO_PORT) && \
+	adb reverse tcp:8081 tcp:8081 && \
 	adb reverse tcp:3449 tcp:3449 && \
 	adb reverse tcp:4567 tcp:4567 && \
-	adb reverse tcp:$(FLOWSTORM_PORT) tcp:$(FLOWSTORM_PORT) && \
 	adb forward tcp:5561 tcp:5561

 android-devices: export TARGET := android-sdk
 android-devices: ##@other Invoke adb devices
 	adb devices

-android-pull-geth: export TARGET := android-sdk
-android-pull-geth: export VERSION ?= debug
-android-pull-geth:
-	adb pull "/storage/emulated/0/Android/data/im.status.ethereum$$( [ "$(VERSION)" = "release" ] || echo ".$(VERSION)" )/files/Download/geth.log"
-
-android-tail-geth: export TARGET := android-sdk
-android-tail-geth: export VERSION ?= debug
-android-tail-geth:
-	adb shell 'while true; do cat; sleep 1; done < /storage/emulated/0/Android/data/im.status.ethereum$$( [ "$(VERSION)" = "release" ] || echo ".$(VERSION)" )/files/Download/geth.log'
-
-android-clean-geth: export TARGET := android-sdk
-android-clean-geth: export VERSION ?= debug
-android-clean-geth:
-	adb shell 'rm /storage/emulated/0/Android/data/im.status.ethereum$$( [ "$(VERSION)" = "release" ] || echo ".$(VERSION)" )/files/Download/geth.log'
-
-
 android-logcat: export TARGET := android-sdk
 android-logcat: ##@other Read status-mobile logs from Android phone using adb
 	adb logcat | grep -e RNBootstrap -e ReactNativeJS -e ReactNative -e StatusModule -e StatusNativeLogs -e 'F DEBUG   :' -e 'Go      :' -e 'GoLog   :' -e 'libc    :'
@@ -1 +1 @@
-2.29.0
+2.27.0
@@ -59,7 +59,7 @@ react {
 /**
 * Set this to true to Run Proguard on Release builds to minify the Java bytecode.
 */
-def enableProguardInReleaseBuilds = true
+def enableProguardInReleaseBuilds = false

 /**
 * The preferred build flavor of JavaScriptCore (JSC)
@@ -83,6 +83,7 @@ def jscFlavor = 'org.webkit:android-jsc:+'
 */
 def enableHermes = hermesEnabled.toBoolean();

+
 def getCommitHash = { ->
    if (project.hasProperty("commitHash")) {
        return project.commitHash
@@ -144,14 +145,6 @@ android {
        jvmTarget = JavaVersion.VERSION_17
    }

-    // https://developer.android.com/studio/projects/install-ndk#vanilla_cmake
-    externalNativeBuild {
-        cmake {
-            // This version must match cmakeVersions inside nix/pkgs/android-sdk/compose.nix
-            version "3.22.1"
-        }
-    }
-
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_17
        targetCompatibility JavaVersion.VERSION_17
@@ -211,7 +204,7 @@ android {
            reset()
            enable getEnvOrConfig('ANDROID_ABI_SPLIT').toBoolean()
            include getEnvOrConfig('ANDROID_ABI_INCLUDE').split(";")
-            universalApk false
+            universalApk true
        }
    }
    signingConfigs {
@@ -232,7 +225,6 @@ android {
        }
        release {
            minifyEnabled enableProguardInReleaseBuilds
-            shrinkResources enableProguardInReleaseBuilds
            proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
            signingConfig null
        }
@@ -240,10 +232,10 @@ android {
            initWith release
            applicationIdSuffix ".pr"
            versionNameSuffix   ".pr"
-            debuggable false
+            debuggable          false
            matchingFallbacks = ["release"]
-            // necessary to make react-native-config's code generation work
-            resValue "string", "build_config_package", "im.status.ethereum"
+             // necessary to make react-native-config's code generation work
+             resValue "string", "build_config_package", "im.status.ethereum"
        }
    }

@@ -277,14 +269,11 @@ dependencies {
    // The version of react-native is set by the React Native Gradle Plugin
    implementation("com.facebook.react:react-android")
    implementation("androidx.core:core-splashscreen:1.0.0")
-
-    if (enableHermes) {
-        implementation("com.facebook.react:hermes-android")
-    } else {
-        // https://github.com/status-im/status-mobile/issues/18493
-        // we don't use hermes for debug builds because it crashes too often
-        implementation(jscFlavor)
-    }
+    // we don't use hermes for debug but we need its pom file for release builds
+    // https://github.com/status-im/status-mobile/pull/18675
+    implementation("com.facebook.react:hermes-android")
+    // FIXME: implementing both hermes & JSC increases bundle size by ~ 2MB
+    implementation(jscFlavor)

    // react-native-screens
    implementation("androidx.appcompat:appcompat:1.1.0-rc01")
@@ -296,7 +285,7 @@ dependencies {
    implementation("com.github.status-im:function:0.0.1")
    implementation("com.facebook.fresco:fresco:2.5.0")
    implementation("com.facebook.fresco:animated-gif:2.5.0")
-    implementation("com.squareup.okhttp3:okhttp-tls:4.11.0")
+    implementation("com.squareup.okhttp3:okhttp-tls:4.9.2")
    implementation("com.google.prefab:cli:2.0.0")
    implementation("com.android.tools.build:aapt2:8.1.1-10154469")
 }
@@ -58,9 +58,6 @@
 -keep interface okhttp3.** { *; }
 -dontwarn okhttp3.**

-# to fix : java.security.KeyStoreException: BKS not found
-keep class org.bouncycastle.** { *; }
-
 # okio

 -keep class sun.misc.Unsafe { *; }
@@ -78,13 +75,4 @@
 -keep public enum com.bumptech.glide.load.ImageHeaderParser$** {
  **[] $VALUES;
  public *;
-}
-
-# react-native-config
-# https://github.com/lugg/react-native-config?tab=readme-ov-file#problems-with-proguard
-keep class im.status.ethereum.BuildConfig {*;}
-
-# react-native-navigation
-# to fix : java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.reflect.ParameterizedType
-# at com.reactnativenavigation.views.element.animators.PropertyAnimatorCreator.getChildClass(Unknown Source:13)
-keep class com.reactnativenavigation.** {*;}
+}
@@ -3,7 +3,7 @@
          xmlns:tools="http://schemas.android.com/tools">

    <!-- These are added by React Native for debug mode, but actually aren't needed in release mode -->
-    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/>
+    <uses-permission tools:node="remove" android:name="android.permission.SYSTEM_ALERT_WINDOW"/>
    <!-- Remove licensing permission since we don't license our app and it blocks F-Droid submissions. -->
    <uses-permission tools:node="remove" android:name="com.android.vending.CHECK_LICENSE"/>

@@ -2,13 +2,6 @@
          xmlns:tools="http://schemas.android.com/tools"
          android:installLocation="auto">

-    <queries>
-        <intent>
-            <action android:name="android.intent.action.SEND_MULTIPLE" />
-            <data android:mimeType="*/*" />
-        </intent>
-    </queries>
-
    <!-- non-dangerous permissions -->
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE_SPECIAL_USE"/>
@@ -36,7 +29,6 @@
            android:allowBackup="false"
            android:label="@string/app_name"
            android:icon="@mipmap/ic_launcher"
-            android:roundIcon="@mipmap/ic_launcher_round"
            android:theme="@style/Theme.AppSplash"
            android:name=".MainApplication"
            android:largeHeap="true"
@@ -71,30 +63,8 @@
                <action android:name="android.intent.action.VIEW" />
                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.BROWSABLE" />
-                <!-- Handles http and https URLs for status.app -->
                <data android:scheme="http" android:host="status.app" />
                <data android:scheme="https" android:host="status.app" />
-                <!-- Community paths -->
-                <data android:pathPattern="/c/.*" android:host="status.app" android:scheme="http" />
-                <data android:pathPattern="/c/.*" android:host="status.app" android:scheme="https" />
-                <!-- Community channel paths -->
-                <data android:pathPattern="/cc/.*" android:host="status.app" android:scheme="http" />
-                <data android:pathPattern="/cc/.*" android:host="status.app" android:scheme="https" />
-                <!-- User paths -->
-                <data android:pathPattern="/u/.*" android:host="status.app" android:scheme="http" />
-                <data android:pathPattern="/u/.*" android:host="status.app" android:scheme="https" />
-                <!-- Private chat paths -->
-                <data android:pathPattern="/p/.*" android:host="status.app" android:scheme="http" />
-                <data android:pathPattern="/p/.*" android:host="status.app" android:scheme="https" />
-                <!-- Community request paths -->
-                <data android:pathPattern="/cr/.*" android:host="status.app" android:scheme="http" />
-                <data android:pathPattern="/cr/.*" android:host="status.app" android:scheme="https" />
-                <!-- Group chat paths -->
-                <data android:pathPattern="/g/.*" android:host="status.app" android:scheme="http" />
-                <data android:pathPattern="/g/.*" android:host="status.app" android:scheme="https" />
-                <!-- Wallet paths -->
-                <data android:pathPattern="/wallet/.*" android:host="status.app" android:scheme="http" />
-                <data android:pathPattern="/wallet/.*" android:host="status.app" android:scheme="https" />
            </intent-filter>
            <intent-filter android:autoVerify="true">
                <action android:name="android.intent.action.VIEW" />
@@ -2,5 +2,4 @@
 <adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
    <background android:drawable="@mipmap/ic_background"/>
    <foreground android:drawable="@mipmap/ic_foreground"/>
-    <monochrome android:drawable="@mipmap/ic_launcher_monochrome" />
-</adaptive-icon>
+</adaptive-icon>
@@ -2,5 +2,4 @@
 <adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
    <background android:drawable="@mipmap/ic_background"/>
    <foreground android:drawable="@mipmap/ic_foreground"/>
-    <monochrome android:drawable="@mipmap/ic_launcher_monochrome" />
-</adaptive-icon>
+</adaptive-icon>
@@ -38,10 +38,10 @@ KEYSTORE_PASSWORD=password
 KEYSTORE_ALIAS=status
 KEYSTORE_KEY_PASSWORD=password

-# Splitting by CPU Architecture produces smaller APKs.
-ANDROID_ABI_SPLIT=true
-# By default its better to only build apk for most recent devices.
-ANDROID_ABI_INCLUDE=arm64-v8a
+# By default we build a mostly universal APK
+ANDROID_ABI_SPLIT=false
+# Some platforms are excluded though
+ANDROID_ABI_INCLUDE=armeabi-v7a;arm64-v8a;x86;x86_64

 org.gradle.jvmargs=-Xmx8704M -XX:+UseParallelGC

@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.8'
+library 'status-jenkins-lib@v1.8.12'

 /* Options section can't access functions in objects. */
 def isPRBuild = utils.isPRBuild()
@@ -71,8 +71,12 @@ pipeline {
        }
        stage('Upload') {
          steps { script {
-            def urls = apks.collect { s5cmd.upload(it) }
-            env.PKG_URL = urls.first()
+            def urls = apks.collect { s3.uploadArtifact(it) }
+            if (urls.size() > 1) { /* Return only the universal APK. */
+              env.PKG_URL = urls.find { it.contains('universal') }
+            } else { /* If no universal is available pick first. */
+              env.PKG_URL = urls.first()
+            }
            jenkins.setBuildDesc(APK: env.PKG_URL)
          } }
        }
@@ -1,7 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.8'
-
-import groovy.json.JsonBuilder
+library 'status-jenkins-lib@v1.8.12'

 pipeline {
  agent { label 'linux' }
@@ -74,7 +72,7 @@ pipeline {
          iOS: utils.pkgUrl(ios),
          Diawi: utils.getEnv(ios, 'DIAWI_URL'),
          /* upload the sha256 checksums file too */
-          SHA: s5cmd.upload(sha),
+          SHA: s3.uploadArtifact(sha),
        ]
        /* add URLs to the build description */
        jenkins.setBuildDesc(urls)
@@ -85,7 +83,7 @@ pipeline {
      steps { script {
        switch (utils.getBuildType()) {
          case 'nightly': /* Create JSON file with newest build URLs */
-            updateBucketJSON(urls, 'latest.json');
+            s3.updateBucketJSON(urls, 'latest.json');
            break;
          case 'release':
            github.publishReleaseFiles(repo: 'status-mobile');
@@ -116,22 +114,3 @@ def Boolean getPublishDefault(Boolean previousValue) {
  if (previousValue != null) { return previousValue }
  return false
 }
-
-/* Helper for updating JSON with newest builds. */
-def updateBucketJSON(urls, fileName) {
-  /* latest.json has slightly different key names */
-  def content = [
-    DIAWI: urls.Diawi,
-    APK: urls.Apk, IOS: urls.iOS,
-    APP: urls.App, MAC: urls.Mac,
-    WIN: urls.Win, SHA: urls.SHA
-  ]
-  def filePath = "${pwd()}/pkg/${fileName}"
-  /* it might not exist */
-  sh "mkdir -p ${pwd()}/pkg"
-  def contentJson = new JsonBuilder(content).toPrettyString()
-  println "${filePath}:\n${contentJson}"
-  writeFile(file: filePath, text: contentJson)
-  return s5cmd.upload(filePath)
-}
-
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.8'
+library 'status-jenkins-lib@v1.8.12'

 pipeline {
  agent { label 'linux' }
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.8'
+library 'status-jenkins-lib@v1.8.12'

 /* Options section can't access functions in objects. */
 def isPRBuild = utils.isPRBuild()
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.8'
+library 'status-jenkins-lib@v1.8.12'

 /* Options section can't access functions in objects. */
 def isPRBuild = utils.isPRBuild()
@@ -75,7 +75,7 @@ pipeline {
    stage('Upload') {
      steps {
        script {
-          env.PKG_URL = s5cmd.upload(LOG_FILE)
+          env.PKG_URL = s3.uploadArtifact(LOG_FILE)
        }
      }
    }
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.8'
+library 'status-jenkins-lib@v1.8.12'

 pipeline {

@@ -36,12 +36,6 @@ pipeline {
    ))
  }

-  environment {
-    /* Avoid race conditions with other builds using virtualenv. */
-    VIRTUAL_ENV = "${WORKSPACE_TMP}/venv"
-    PATH = "${VIRTUAL_ENV}/bin:${PATH}"
-  }
-
  stages {
    stage('Fetch') {
      steps { script {
@@ -58,8 +52,7 @@ pipeline {
    stage('Setup') {
      steps { script {
        dir('test/appium') {
-          sh "python3 -m venv ${VIRTUAL_ENV}"
-          sh 'pip3 install -r requirements.txt'
+          sh 'pip3 install --user -r requirements.txt'
        }
      } }
    }
@@ -99,7 +92,7 @@ pipeline {
                --rerun_count=2 \
                --testrail_report=True \
                -m testrail_id \
-                -m \"nightly\" \
+                -m \"new_ui_critical or new_ui_medium\" \
                -k \"${params.KEYWORD_EXPRESSION}\" \
                --apk=${params.APK_URL ?: apk_path}
            """
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.8'
+library 'status-jenkins-lib@v1.8.12'

 pipeline {

@@ -35,11 +35,13 @@ pipeline {
      description: 'OBSOLETE ARGUMENT TO BE REMOVED',
      defaultValue: 'DUMMY',
    )
+    /* Commented to use TEST_MARKERS values from job params
    string(
      name: 'TEST_MARKERS',
      description: 'Marker expression for matching tests to run.',
-      defaultValue: 'smoke',
+      defaultValue: 'new_ui_critical',
    )
+    */
  }

  options {
@@ -52,12 +54,6 @@ pipeline {
    ))
  }

-  environment {
-    /* Avoid race conditions with other builds using virtualenv. */
-    VIRTUAL_ENV = "${WORKSPACE_TMP}/venv"
-    PATH = "${VIRTUAL_ENV}/bin:${PATH}"
-  }
-
  stages {
    stage('Prep') {
      steps { script {
@@ -83,8 +79,7 @@ pipeline {
    stage('Setup') {
      steps { script {
        dir('test/appium') {
-          sh "python3 -m venv ${VIRTUAL_ENV}"
-          sh 'pip3 install -r requirements.txt'
+          sh 'pip3 install --user -r requirements.txt'
        }
      } }
    }
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.8'
+library 'status-jenkins-lib@v1.8.12'

 pipeline {

@@ -35,11 +35,6 @@ pipeline {
    ))
  }

-  environment {
-    /* Avoid race conditions with other builds using virtualenv. */
-    VIRTUAL_ENV = "${WORKSPACE_TMP}/venv"
-    PATH = "${VIRTUAL_ENV}/bin:${PATH}"
-  }

  stages {
    stage('Prep') {
@@ -56,8 +51,7 @@ pipeline {
    stage('Setup') {
      steps { script {
        dir('test/appium') {
-          sh "python3 -m venv ${VIRTUAL_ENV}"
-          sh 'pip3 install -r requirements.txt'
+          sh 'pip3 install --user -r requirements.txt'
        }
      } }
    }
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.8'
+library 'status-jenkins-lib@v1.8.12'

 pipeline {
  agent { label 'macos' }
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.8'
+library 'status-jenkins-lib@v1.8.12'

 pipeline {
  agent { label params.AGENT_LABEL }
@@ -123,6 +123,7 @@ pipeline {
  post {
    always { script {
      nix.shell('nix-store --optimize', pure: false)
+      nix.shell('nix/scripts/clean.sh', pure: false)
    } }
  }
 }
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.8'
+library 'status-jenkins-lib@v1.8.12'

 pipeline {
  agent { label 'linux' }
@@ -1,5 +1,5 @@
 #!/usr/bin/env groovy
-library 'status-jenkins-lib@v1.9.8'
+library 'status-jenkins-lib@v1.8.12'

 pipeline {
  agent {
@@ -1,43 +1,70 @@
-## Getting Started
+## Getting Started 
+
+[Starting Guide](starting-guide.md)
+
+[IDE Setup](ide-setup.md)
+

- [Starting Guide](starting-guide.md)
- [IDE Setup](ide-setup.md)

 ## Development Process

- [Coding guidelines](new-guidelines.md)
- [UI components coding guidelines](ui-guidelines.md)
- [Release Checklist](release-checklist.md)
- [Release Guide](release-guide.md)
- [Merging PR process](merging-pr-process.md)
- [PR Review Policy](pr-review-policy.md)
- [Working on PR together with QA team](pipeline_process.md)
- [Debugging](debugging.md)
- [Patching](patching.md)
- [Creating a pixel perfect UI](pixel-perfection.md)
- [Contributing to status-go](status-go-changes.md)
- [Malli schemas (recorded demo)](https://www.youtube.com/watch?v=SlRio70aYVI) ([slides](files/forging-code-with-schemas-sep-2023-slides.pdf))
+[Coding guidelines](new-guidelines.md)
+
+[UI components coding guidelines](ui-guidelines.md)
+
+[Release Checklist](release-checklist.md)
+
+[Release Guide](release-guide.md)
+
+[Merging PR process](merging-pr-process.md)
+
+[PR Review Policy](pr-review-policy.md)
+
+[Working on PR together with QA team](pipeline_process.md)
+
+[Debugging](debugging.md)
+
+[Patching](patching.md)
+
+[Creating a pixel perfect UI](pixel-perfection.md)
+
+[Contributing to status-go](status-go-changes.md)
+
+[Malli schemas (recorded demo)](https://www.youtube.com/watch?v=SlRio70aYVI) ([slides](files/forging-code-with-schemas-sep-2023-slides.pdf))

 ## Testing

- [Overview](tests/tests-overview.md)
- [How to run local tests](tests/how-to-run-local-tests.md)
- [End-to-end tests (e2e) overview](tests/how-to-launch-e2e.md)
- [Component tests (jest) overview](tests/component-tests-overview.md)
+[How to run local tests](testing.md)
+
+[End-to-end tests (e2e) overview](how-to-launch-e2e.md)
+
+[Component tests (jest) overview](component-tests-overview.md)
+

 ## Project details

- [status-go introduction (recorded meeting)](https://drive.google.com/file/d/1B7TljmTZ8fHkqJH8ChU1Cp4FGDFM03gq/view)
- [re-frame usage (recorded meeting)](https://drive.google.com/file/d/1qv_E0CEGzQpu_zGXD0gCTU5EvhC2k8Jy/view)
- [status app functionality demo](https://drive.google.com/file/u/0/d/1PmwsMLTLDNNIdv5_6wvMOwoj2PfT50c6/view)
+[status-go introduction (recorded meeting)](https://drive.google.com/file/d/1B7TljmTZ8fHkqJH8ChU1Cp4FGDFM03gq/view)
+
+[re-frame usage (recorded meeting)](https://drive.google.com/file/d/1qv_E0CEGzQpu_zGXD0gCTU5EvhC2k8Jy/view)
+
+[status app functionality demo](https://drive.google.com/file/u/0/d/1PmwsMLTLDNNIdv5_6wvMOwoj2PfT50c6/view)

 ## Misc

- [Importing icons from Figma into project](export-icons.md)
- [Updating Status APK builds for the F-Droid Android application catalogue](fdroid.md)
- [Troubleshooting for known errors](troubleshooting.md)
+[Importing icons from Figma into project](export-icons.md)
+
+[Updating Status APK builds for the F-Droid Android application catalogue](fdroid.md)
+
+[Troubleshooting for known errors](troubleshooting.md)
+
+## Articles
+
+[Notes on memoization](./articles/notes-on-memoization.md) 
+

 ## Outdated:

- [Old guidelines](codebase-structure-and-guidelines.md)
- [Post mortem analysis](post-mortem.md)
+[Old guidelines](codebase-structure-and-guidelines.md)
+
+[Post mortem analysis](post-mortem.md)
+
@@ -0,0 +1,155 @@
+# Notes on Memoization
+
+## Content
+- [Intro](#intro)
+- [Understanding Object.is for Effective Memoization](#understanding-objectis-for-effective-memoization)
+- [Strategies for Creating Stable References](#strategies-for-creating-stable-references)
+- [Key Takeaways](#key-takeaways)
+- [Further Readings](#further-readings)
+
+## Intro
+
+Memoization is an optimization technique used to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again. It is a specific form of caching where results of function calls are stored based on their input arguments. However, it's important to note that this technique introduces memory overhead, as it requires additional space to store the results of function calls. While it is a powerful tool for improving performance, we must balance its benefits against the increased memory usage, especially in resource-constrained environments.
+
+Memoization in React is used to ensure that a component or a computation does not re-render or re-calculate `unnecessarily` when its input props or dependencies have not changed. This technique can significantly improve the performance of React applications, especially for `expensive`, `computation-heavy` operations or components that `render frequently`.
+
+In React, we generally have three util functions for memoizing :
+- React.memo (or `rn/memo` in the case of our codebase):
+Memoizes a component's render output based on its props. It can optionally take a comparison function to customize how changes in props are detected.
+ e.g:
+  ```clojure
+  (def pure-component
+    (rn/memo (fn [props]
+              [view props])
+            (fn [prev-props next-props]
+              (= (:value prev-props) (:value next-props)))))
+  ```
+
+- React.useMemo (or `rn/use-memo` in the case of our codebase):  Memoizes a computed value so that it does not need to be re-calculated on every render, given that its dependencies haven't changed. e.g:
+  ```clojure
+  (defn component [{:keys [something] :as props}]
+    (let [memoized-value (rn/use-memo (fn [] 
+                                      (compute-expensive-value something)) 
+                                    [something])]
+    [view {:value memoized-value}]))
+  ```
+- React.useCallback (or `rn/use-callback` in the case of our codebase): Similar to React.useMemo, but for callback functions, ensuring that a function's reference remains stable between renders unless its dependencies change. e.g:
+  ```clojure
+  (defn component [{:keys [something] :as props}]
+    (let [on-done (rn/use-callback (fn [] 
+                                      (do-some-thing something)) 
+                                    [something])]
+    [view {:on-done on-done}]))
+  ```
+
+Based on the example for the 3 util functions above, we generally see that they take a second argument which is a function in the case of `React.memo` and is a dependency array (vector) for `React.useMemo` and `React.useCallback` respectively. 
+
+In the case of `React.memo`, the second argument been a function is essentially a predicate which we as the consumer use to determine (or tell React) if the previous prop used to render a component is equal to the next prop it would receive. If this results to `true` we get to skip re-rendering, otherwise we re-render with the new props. The argument is also optional, and if not provided React would use Javascript's [Object.is](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is) to compare each individual prop (previous prop against next prop) for equality. 
+
+## Understanding Object.is for Effective Memoization
+
+For `React.useMemo` and `React.useCallback` the second argument is a required array (vector) of dependencies which we as the consumer do not have any control of telling React how to compare the value of the previous prop to the next prop. It also uses [Object.is](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is) for comparisons of each of the dependencies.
+
+Since, we do not have a way of telling React of how to compare the previous prop to the next prop in the case of `React.useMemo` and `React.useCallback`, it would benefit us to understand how `Object.is` compares values. 
+
+There are two types of values in Javascript (Javascript is used here because our Clojurescript code essentially compiles to Javascript when we are using pure React):
+- Primitive Values: e.g string, number, boolean, BigInt, null, undefined and Symbol
+- Reference (non primitive) values: These are all other values asides the ones stated above. e.g objects (map), arrays (vectors), sets, functions etc...
+
+For primitive values, `Object.is` can simply compare them by their actual values e.g `Object.is(2, 2)` or `Object.is("John Snow", "John Snow")` would always return `true` because the values are essentially the same.
+
+For reference values, `Object.is` compares them based on the reference (which for simplicity are like pointers to values stored in a variable). For example:
+```js
+const a = {}
+const b = {}
+
+Object.is(a, b)
+```
+
+`Object.is(a, b)` would return `false` even though the values are actually equal. This is because the reference to `a` and `b` are essentially different and they been non-primitive (reference values), `Object.is` compares them with their references rather than their values. The same holds true if we inline the variables like so `Object.is({}, {})`.
+
+Now that we understand this, let us see how this relates to React. In React functional component we essentially create a function which can have some variables bound to its scope and return some UI. e.g:
+
+```clojure
+(defn component [props]
+   (let [some-state (rn/use-state {:name "John Snow"
+                                   :knowledge 0})
+         some-vector [1 2 3]]
+    [rn/view props]))
+```
+
+When the `props` or the bound `"reactive" state` of this component changes, React would re-render this component by executing the function body and by doing so all variables bound to this function's scope are re-initialized meaning they get a new reference if they are reference (non primitive) values. This "re-initialization" and changing of reference happens anytime there is a re-render even if the actual value(s) did not change between renders. This means that any non primitive value in the scope of the function component would by default have an `unstable reference` between every render cycle.
+
+By having an unstable reference, `Object.is` would always return `false` for reference values when comparing them between cycles. The implication of this is that when you pass a reference value with an unstable reference as a prop to a component that is memoized via `React.memo` (without a custom compare function), React would always see that prop as new value when comparing hence re-rendering the component because the reference to the prop changed even when the value hasn't essentially changed. The same is also true for `React.useMemo` and `React.useCallback`, if an unstable reference is passed as a dependency to them, the function they would recompute their function body and return a new reference to the memoized `value` or `callback`. By passing an unstable value (reference value) to these util functions, we essentially defeat the purpose of memoization in the first place.
+
+## Strategies for Creating Stable References
+
+How then do we create stable references? Well there are a number of ways, and there is no one size fits all way of doing it. But here are a few ways we could do it:
+### Using global variables: 
+We can get stable references by declaring variables in a more global scope relative to the function's local scope. This essentially means if we can, we should declare the variables outside the functions scope. e.g:
+  ```clojure
+  (def some-map {:name "John Snow"
+                :knowledge 0})
+
+  (defn comp []
+    [rn/view {:some-map some-map}])
+  ```
+
+- Trade-offs: While global variables ensure reference stability, they can introduce side effects or global state management complexities. Overuse can make components harder to understand and test due to implicit dependencies.
+
+- Best Scenarios: Use for constants or configuration data that truly does not change over the application's lifetime and does not belong to any component's state.
+  
+### Using `React.useRef`: 
+Provides a mutable ref object that remains constant throughout the component's lifecycle. Ideal for holding onto a value that does not trigger re-renders.. e.g
+  ```clojure
+  (defn comp []
+    (let [ref (rn/use-ref-atom {:name "John Snow"
+                                :knowledge 0})]
+    [rn/view {:some-map @ref}]))
+  ```
+- Trade-offs: It is not "reactive", meaning changes to its content do not cause the component to re-render. It's best used for values that are incidental to rendering.
+
+- Best Scenarios: Storing references to DOM elements, keeping track of previous props or state for comparison, or holding values that interact with imperative APIs.
+
+### Using `React.useState`: 
+Returns a stable reference to a stateful value, with an updater function to change its value. The reference only changes when explicitly updated via the updater. e.g
+  ```clojure
+  (defn comp []
+    (let [[state set-state] (rn/use-state {:name "John Snow"
+                                           :knowledge 0})]
+    [rn/view {:some-map state}]))
+  ```
+
+- Trade-offs: It triggers a component re-render when the state changes, which might not be necessary for all types of stored values. Managing large sets of stateful data here can make the component less efficient.
+
+- Best Scenarios: Managing local component state that directly influences the render output. Ideal for values that change over time and need to trigger updates.
+
+### Using `React.useMemo` and `React.useCallback`: 
+They both return stable references, but the catch here is that they also require stable references themselves as dependencies. e.g
+  ```clojure
+  (defn comp []
+    (let [[knowledge set-knowledge] (rn/use-state 0)
+          derived-state             (rn/use-memo (fn []
+                                                    {:name      "John Snow"
+                                                    :knowledge knowledge}) 
+                                                  [knowledge])]
+    [rn/view {:some-map derived-state}]))
+  ```
+
+- Trade-offs: They depend on the stability of their dependency lists, which can lead to unnecessary recalculations if dependencies have unstable references. Overuse can lead to increased memory usage and complexity.
+
+- Best Scenarios: `React.useMemo` is best for expensive calculations that depend on specific props or state and do not change on every render. `React.useCallback` is ideal when passing callback functions to deeply nested child components that need stable references to prevent unnecessary renders.
+
+The list is not exhaustive, but these are the most common ways to get stable references to non-primitive values.
+
+It might be worthy to note that most of these would be abstracted away in React 19 with the introduction of a [compiler that helps you memo when needed](https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024#react-compiler).
+
+## Key Takeaways
+- Before you memo, profile to identify performance bottlenecks
+- When you do want to memo, ensure you pass non primitive values with stable references as a dependency to your memo function.
+- You do not need to worry about primitive values that much as they are easily comparable
+- Memoization introduces its own complexity and memory overhead. Use it judiciously.
+
+## Further Readings
+- [Thinking in React](https://react.dev/learn/thinking-in-react)
+- [Mastering React’s Stable Values](https://shopify.engineering/master-reacts-stable-values)
@@ -20,39 +20,6 @@ A server will be started at http://localhost:4567. It might show "not connected"

 More details about re-frisk are on the [project page](https://github.com/flexsurfer/re-frisk).

-## Debugging with FlowStorm
-
-[FlowStorm](http://www.flow-storm.org/) is a free and open-source time-travel
-debugger for Clojure and ClojureScript. It is capable of recording almost any
-code execution path in the Status' mobile app.
-
-FlowStorm is independent of editor/IDE, but a tighter [integration with
-Emacs](https://github.com/jpmonettas/cider-storm) is available.
-
-If you are developing with Android, run `make android-ports` first. If you are
-behind a firewall, allow TCP traffic on port `7722`, then:
-
-```bash
-make run-flow-storm
-```
-
-You will know FlowStorm is correctly running if you see the status bar with
-green `REPL` and `RUNTIME` indicators.
-
-With FlowStorm running, you can now add `#trace` on any top-level form, reload
-the code, or evaluate the traced form in the REPL, and FlowStorm will start
-recording data. Avoid `#rtrace` (with `r`) because it can cause massive spikes
-in CPU which will make the app hang and you might need to forcefully kill
-processes.
-
-```clojure
-#trace ; => Add this line to tell FlowStorm to instrument the function.
-(defn say-hello []
-  (str "Hello world"))
-```
-
-There are other ways to debug, but this is a good start.
-
 ## Enabling debug logs
 Calls to `log/debug` will not be printed to the console by default. It can be enabled under "Advanced settings" in the app:

@@ -8,7 +8,7 @@ As a part of CI for Status mobile app and in order to ensure there are no regres
 - Automated tests written on Python 3.9 and pytest.
 - Appium (server) and Selenium WebDriver (protocol) are the base of test automation framework.

-TestRail is a test case management system tool where we have test cases.
+TestRail is a test case management system tool where we have test cases. 


 Each of the test case gets a priority (Critical/High/Medium)
@@ -20,21 +20,21 @@ For now we support e2e for Android only.
 Whenever we need to push set of test scripts we create 16 parallel sessions (max, but depending on amount of cases that are included in job) and each thread: 1) uploads Android .apk file to SauceLabs -> 2) runs through the test steps -> 3) receives results whether test failed on particular step or succeeded with no errors -> 3) Parse test results and push them as a Github comment (if the suite ran against respective PR) and into TestRail.

 We push **whole automation test suite (currently 155, amount is changing)** against each nightly build (if the nightly builds job succeeded). Results of the test run are saved in TestRail.
-And also we push set of autotests whenever PR with successful builds got moved in to `E2E Tests` column from [Pipeline for QA dashboard ](https://github.com/status-im/status-react/projects/7).
+And also we push set of autotests whenever PR with successful builds got moved in to `E2E Tests` column from [Pipeline for QA dashboard ](https://github.com/status-im/status-react/projects/7). 
 In that case we save results in TestRail as well and push a comment with test results in a respective PR.

 For example: https://github.com/status-im/status-react/pull/9147#issuecomment-540008770

-![](../images/how-to-launch-e2e/how-to-launch-e2e-1.png)
+![](images/how-to-launch-e2e/how-to-launch-e2e-1.png)


 The test_send_stt_from_wallet opens link in TestRail https://ethstatus.testrail.net/index.php?/tests/view/890885 where performed steps could be found
-List of all runs performed by test jobs could be found here https://ethstatus.testrail.net/index.php?/runs/overview/14
+List of all runs performed by test jobs could be found here https://ethstatus.testrail.net/index.php?/runs/overview/14 

 **For credentials for TestRail to see results ping Chu in DM**:

 Opening any test run navigates you to list of test cases with results:
-![](../images/how-to-launch-e2e/how-to-launch-e2e-2.png)
+![](images/how-to-launch-e2e/how-to-launch-e2e-2.png)


 ## What about launching e2e manually
@@ -53,12 +53,12 @@ Params to specify:
 - test_marks: tests by priorities (by default: `critical or high or medium`, which corresponds the whole suite; to launch the same suite as in PRs, use `critical or high`)
 - testrail_case_id: here is the list of test cases which you may find in test rail (4-digit value)

-For easier access you can hit `Rerun tests` in GH comment and testrail_case_id/ apk_name/ pr_id  will be filled automatically. For making sure that tests are being rerun on most recent e2e build it is recommended to paste link to the last e2e build in apk_name field. The list of PR builds can be found in Jenkins Builds block on PR page.
-![](../images/how-to-launch-e2e/how-to-launch-e2e-3.png)
+For easier access you can hit `Rerun tests` in GH comment and testrail_case_id/ apk_name/ pr_id  will be filled automatically. For making sure that tests are being rerun on most recent e2e build it is recommended to paste link to the last e2e build in apk_name field. The list of PR builds can be found in Jenkins Builds block on PR page. 
+![](images/how-to-launch-e2e/how-to-launch-e2e-3.png) 
 And then hit ‘Build’.
 Once the job starts it picks up specified tests, runs them against provided apk and sends results to pull request.

-Even we have 16 parallel sessions for testing it’s a time consuming operation (whole test suite we have automated at the moment takes ~140 minutes to finish).
+Even we have 16 parallel sessions for testing it’s a time consuming operation (whole test suite we have automated at the moment takes ~140 minutes to finish). 
 So for PRs we pick only set of `critical or high` (you can also use this in TEST_MARKS param for job)
 tests (otherwise some PRs could wait their turn of the scheduled Jenkins job till the next day).

@@ -78,9 +78,9 @@ Several examples of when test fails to succeed:

 - **Valid issue in the automated test scripts** - that's what we're looking for

-Example: here is the test results https://github.com/status-im/status-react/pull/13015#issuecomment-1016495043 where one test failed.
+Example: here is the test results https://github.com/status-im/status-react/pull/13015#issuecomment-1016495043 where one test failed. 
    1. Open the test in TestRail and open session recorded for this test in SauceLabs
-![](../images/how-to-launch-e2e/how-to-launch-e2e-4.png)
+![](images/how-to-launch-e2e/how-to-launch-e2e-4.png)


 In TestRail you may find all the steps performed by the test.
@@ -98,6 +98,6 @@ Not all features of the app could be covered by e2e at the moment:
 ## Brief flow for test to be automated

 Whenever there is a need to have a new test:
-1) Create a test scenario in TestRail.
+1) Create a test scenario in TestRail. 
 2) If certain item could be checked in scope of existing test case we update existing one (otherwise we may have thousands of test cases which is overkill to manage in TestRail as well as in automated test scripts). And also complex autotests increase probability to not catch regressions by stopping test execution (due to valid bug or changed feature) keeping the rest test steps uncovered. So here we need to balance when it makes sense to update existing test case with more checks.
 3) Then we create test script based on the test case, ensure test passes for the build and pushing the changes to repo.
@@ -32,16 +32,14 @@ status-mobile code that makes it to the `develop` branch, should always point to
 In practice, this means that sometimes they need to be merged in lockstep.
 1) Create a PR in status-go and status-mobile. Update the status-go version to the PR revision `scripts/update-status-go.sh $git_revision`.
 2) Get both PRs reviewed and approved. Once status-mobile PR has been approved, go through manual QA testing if necessary. Don't merge status-mobile PR just yet.
-3) Now that you know the integration between client & server is working, merge the status-go PR first.
-4) Once merged, tag the merged commit with the new version and push the tag:
+3) Now that you know the integration between client & server is working, bump the `VERSION` in status-go and merge it.
+4) Once merged, tag the version with the new version and push the tag:
 ```
  git checkout develop
  git pull develop
-  make tag-version
+  git tag vx.y.z
  git push origin vx.y.z
 ```
-:warning: If a specific commit need to tagged in status-go, use `make tag-version TARGET_COMMIT={hash}`. More info about tagging in [status-go](https://github.com/status-im/status-go/blob/develop/RELEASING.md#tagging-versions).
-
 5) Update status-mobile with the new status-go version, using the new tag `scripts/update-status-go.sh "vx.y.z"`
 6) If you had to rebase status-go to include new changes, e2e test MUST be re-run. If there's any issue you will
   have to fix in status-go with another PR and follow the same process.
@@ -8,7 +8,7 @@ The generally accepted requirements for its use are described below:
 - Once a PR is created, it moves to the ```REVIEW``` column where a review will be requested automatically.
 - You can also request a review inside the PR from a particular person if needed.
 - When creating a PR, do not forget to assign it to yourself.
- Also in case the PR adds new functionality, a description **MUST** be added.
+- Also in case the PR adds new functionality, a short description would be appreciated.

 ### What if the work is still in progress?

@@ -28,13 +28,28 @@ Ready for testing, a PR should meet the following criteria:
 4. Has the label: `request-manual-qa` or `skip-manual-qa`.
 5. PRs **MUST** identify what area is affected and should have a description.

+**NOTE:** Make sure that QAs are OK with that
+
+### Adding `skip-manual-qa`
+
+- Please ask another team member before adding the `skip-manual-qa` label (PR/Status community/DMs) so that there's a second opinion.
+- The PR MUST have a proper reasoning why manual QA is skipped.
+- The PR MUST include the steps of testing that has been done by the developer prior to moving it forward.
+**From the perspective of a developer it means that once work on PR is finished:**
+
+1. It should be rebased to the latest `develop`. If there are conflicts - they should be resolved if possible.
+2. If the PR was in the `Contributor` column - it should be moved to `Review` column.
+3. Wait for the review.
+4. Make sure that after review and before requesting manual QA your PR is rebased to current develop.
+5. The PR **MUST** be moved to the E2E column when it is ready for testing (**mandatory for all PRs**).
+That will also trigger e2e tests run. QAs are monitoring PRs from E2E column and take it into test. 
+
+6. After that - PR will be taken into manual testing by the QA team.

 ### E2E tests and analyzing the results

-The PR **MUST** be moved to the E2E column when it is ready for testing (**mandatory for all PRs**).
-That will also trigger e2e tests run. QAs are monitoring PRs from E2E column and take it into test.
 This step cannot be skipped. So, at least one comment from the `status-im-auto` bot with results is a prerequisite for moving forward.
-Information on how to analyze tests can be found [here](https://github.com/status-im/status-mobile/blob/develop/doc/tests/how-to-launch-e2e.md).
+Information on how to analyze tests can be found [here](https://github.com/status-im/status-mobile/blob/develop/doc/how-to-launch-e2e.md).
 Tests might be flaky, as they depend on infrastructure - SauceLabs and Waku.

 If there are `Failed tests` and you are not sure about the reason, you can always ping the mobile QAs for help (preferably in PRs by `@status-im/mobile-qa`).
@@ -44,20 +59,6 @@ Please, respect this rule.**

 ## Testing PR

-### Adding `skip-manual-qa`
-
-**Do not hesitate to use a `skip-manual-qa`** if you're sure that it is a simple flow and you checked it.
- Please ask another team member before adding the `skip-manual-qa` label (PR/Status community/DMs) so that there's a second opinion.
- The PR MUST have a proper reasoning why manual QA is skipped.
- The PR MUST include the steps of testing that has been done by the developer prior to moving it forward.
-
-**NOTE:** Make sure that QAs are OK with that;
-
-Before merging PRs, please make sure that information is added about how you tested the PRs, that e2s have been passed and their results have been reviewed.
-
-The QA team appreciates your help!
-
-
 ### Manual testing

 #### Prerequisites for manual testing
@@ -72,7 +73,7 @@ The QA team appreciates your help!
 - QA engineer picks up one of PRs with the ```request-manual-qa``` label, drags the item to the ```IN TESTING``` column and assigns it to themselves.
 - During testing, QA will add comments describing the issues found, and also review automation tests results.
 Usually found issues are numbered as "Issue 1, Issue 2", etc.
-When the first round of testing is completed and all issues for this stage are found, the QA can add the ```Tested - Issues``` label and drag the card to the ```CONTRIBUTOR``` column. These two actions are optional.
+When the first round of testing is completed and all issues for this stage are found, the QA can add the ```Tested - Issues``` label and drag the card to the ```CONTRIBUTOR``` column. These two actions are optional. 

 **IMPORTANT NOTE:** when the issues are fixed, developer **MUST** notify the QA that it is ready to be re-tested again by mention them in the PR.

@@ -86,7 +87,7 @@ After that the developer merges PR into develop.
 _**How do I know if a design review is needed?**_

 There are three cases here depending on the changes in the PR:
-1. **Functional PRs with UI changes:** after the ```Tested - OK``` label is added, the QA moves the PR to the ```Design review``` column + mentions ```@Francesca-G``` in comments.
+1. **Functional PRs with UI changes:** after the ```Tested - OK``` label is added, the QA moves the PR to the ```Design review``` column + mentions ```@Francesca-G``` in comments. 
 2. **Component PRs:** once the PR has received a review from developers and e2e tests results, it can be moved directly to the ```Design review``` column by the developer (manual testing step can be skipped) + the developer mentions ```@Francesca-G``` in comments.
 3. **Functional PRs changes in which are not related to UI (e.g. a crash fix):** skip the ```Design review``` step (the PR should only be manually tested by QA).

@@ -98,8 +99,8 @@ There are three possible scenarios when the design review is completed:
 ---
 **Notes:**
 - If your PR has a long story and started from `develop` branch several days ago, please rebase it to current develop before adding label
- if PR can be tested by developer (in case of small changes) and/or developer is sure that the changes made cannot introduce a regression, then PR can be merged without manual testing. Also, currently, PRs are not manually tested if the changes relate only the design (creation of components, etc.) and do not affect the functionality (see `skip-manual-qa` label)
---
+- if PR can be tested by developer (in case of small changes) and/or developer is sure that the changes made cannot introduce a regression, then PR can be merged without manual testing. Also, currently, PRs are not manually tested if the changes relate only the design (creation of components, etc.) and do not affect the functionality.
+---        

 #### Why my PR is in `Contributor` column?
 PR can be moved to this column by the ```status-github-bot``` or by QA engineer with label `Tested-issues` or if one of the requirements for manual QA was not met.
@@ -120,6 +121,6 @@ In the second case - after fixing of all found issues, the developer should ping
 6. In case of manual testing - the label ```Tested - OK``` from QA
 7. In case of design review - the approval from the designer

-You can merge your PR into develop - some useful clues you can find [here](https://notes.status.im/setup-e2e#3-Merging-PR)
+You can merge your PR into develop - some useful clues you can find [here](https://notes.status.im/setup-e2e#3-Merging-PR) 

-HAPPY DEVELOPMENT! :tada:
+HAPPY DEVELOPMENT! :tada: 
@@ -51,8 +51,6 @@ Jenkins will automatically build this branch and create release candidates.
 Those will go through the QA process and the QA team will let us know when
 tested successfully.

-You can see the state at https://ci.infra.status.im/ -> status-mobile -> release -> pick the right version number
-
 ## Bugfixes before an app is released

 Because both `status-mobile` and `status-go` might have newer commits that we don't want to include, bug fixes should be applied separately to develop and the release branch.
@@ -1,167 +0,0 @@
-# Tests
-
-## Introduction
-
-This document provides a general overview of the types of tests we use and when
-to use them. It is not meant to be a tutorial or a detailed documentation about
-testing in software development.
-
-## Types of tests
-
-Tests in `status-mobile` are comprised of:
-
- Unit tests
-  - Subscription tests
-  - Event tests
-  - Tests for various utilities
- [Component tests](./component-tests-overview.md)
- Integration/contract tests
- [End-to-end tests](./how-to-launch-e2e.md)
-
-We apply the [test
-pyramid](https://en.wikipedia.org/wiki/Test_automation#Testing_at_different_levels)
-strategy, which means we want the majority of tests at the bottom of the
-pyramid. Those should be fast and deterministic and support REPL-Driven
-development (RDD). Slightly above them, we have component tests, then
-integration/contract tests and finally end-to-end tests. The closer to the top
-of the pyramid, the more valuable a test can be, but also more difficult to
-pinpoint why it failed and harder to make it dependable.
-
-*Note*: there are literally dozens of [types of
-tests](https://en.wikipedia.org/wiki/Software_testing), each with its strengths
-and weaknesses.
-
-We tend not to stub or mock implementations in our tests, which means our tests
-are [sociable](https://martinfowler.com/bliki/UnitTest.html).
-
-## What to test?
-
-The UI is driven by global & local state changes caused by events. Global state
-is managed by re-frame and local state by Reagent atoms or React hooks. Except
-for component and end-to-end tests, we test only non-UI code in `status-mobile`.
-Given that the UI is greatly derived from global state, by guaranteeing the
-state is correct we can prevent bugs and, more importantly, reduce the [cost of
-change](https://www.pmi.org/disciplined-agile/agile/costofchange).
-
-We strive to minimize the amount of _business logic_ in views (UI code). We
-achieve this by moving capabilities to status-go and also by adhering to
-re-frame's architecture.
-
-Whenever appropriate (see section `When to test?`), we _may_ test:
-
- Re-frame events.
- Re-frame subscriptions.
- Utility functions.
- User journeys through integration/contract tests.
-
-Interestingly, we don't test re-frame _effects_ in isolation.
-
-### What are status-mobile integration and contract tests?
-
-The mobile _integration tests_ can be used to "simulate" user interactions and
-make actual calls to status-go via the RPC layer and actually receive signals.
-We can also use these tests to verify the app-db and multiple subscriptions are
-correct. We use the word _simulate_ because there is no UI. Basically, any flow
-that can be driven by re-frame events is possible to automatically test. There
-is no way to change or inspect local state managed by React.
-
-A _contract test_ has the same capabilities as an integration test, but we want
-to draw the line that they should focus more on a particupar RPC endpoint or
-signal, and not on a user journey (e.g. create a wallet account). In the future,
-we may consider running them automatically in status-go.
-
-**Note:** integration tests and contract tests are currently overlapping in
-their responsibilities and still require a clearer distinction.
-
-## When to test?
-
-(Automated) tests basically exist to support rapid software changes, but not
-every piece of code should be tested. The following are general recommendations,
-not rules.
-
- What would be the consequences to the user of a bug in the implementation you
-  are working on?
- Can a QA exercise all the branches in the code you changed? Not surprisingly,
-  usually QAs can't test many code paths (it may be nearly impossible), and
-  because PRs are not often tested by reviewers, many PRs can get into `develop`
-  without the necessary quality assurance.
- How costly was it for you to verify a function/event/etc was correct? Now
-  consider that this cost will be dispersed to every developer who needs to
-  change the implementation if there are no tests.
- Check the number of conditionals, and if they nest as well. Every conditional
-  may require two different assertions, and the number of assertions can grow
-  exponentially.
- How complicated are the arguments to the function? If they contain nested maps
-  or data that went through a few transformations, it may be tricky to decipher
-  what they are, unless you are familiar with the code. A test would be able to
-  capture the data, however complex they are.
-
-### When to unit-test subscriptions?
-
-Only test [layer-3
-subscriptions](https://day8.github.io/re-frame/subscriptions/#the-four-layers),
-i.e. don't bother testing extractor subscriptions (check the related
-[guideline](https://github.com/status-im/status-mobile/blob/7774c4eac16fdee950a17bf5d07630c45a980f41/doc/new-guidelines.md#subscription-tests)).
-Some layer-3 subscriptions can still be straightforward and may not be worth
-testing.
-
- Check the number of _inputs_ to the sub (from the graph). The higher this
-  number, the greater the chance the subscription can break if any of the
-  input's implementation changes.
-
-**Note**: if a tested subscription changes inadvertently, even if its own tests
-still pass, other subscriptions that depend on it and have tests may still fail.
-This is why we don't directly test the subscription handler, but instead, use
-the macro `test-helpers.unit/deftest-sub`.
-
-### When to unit-test events?
-
-A good hint is to ask if you and other CCs need to rely on re-frisk, UI, REPL,
-or FlowStorm to understand the event. If the answer is yes or probably, then a
-test would be prudent.
-
- Many events only receive arguments and pass them along without much or any
-  transformation to an RPC call. These are straightforward and usually don't
-  need tests ([example](https://github.com/status-im/status-mobile/blob/7774c4eac16fdee950a17bf5d07630c45a980f41/src/status_im/contexts/contact/blocking/events.cljs#L79-L85)).
- Overall, every event basically returns two effects at most, `:fx` and/or
-  `:db`. Usually, the complicated part lies in the computation to return the new
-  app-db. If the event doesn't perform transformations in the app-db or just
-  does a trivial `assoc`, for example, it may not be worth testing.
-
-For reference, the re-frame author particularly [suggests testing events and
-subscriptions](https://github.com/day8/re-frame/blob/09e2d7132c479aa43f2a64164e54e42bf8511902/docs/Testing.md#what-to-test).
-
-### When to unit-test utility functions?
-
-Most utility functions in `status-mobile` are pure and can be readily and
-cheaply tested.
-
- If the utility is used in an event/subscription and if the event/subscription
-  has tests, you may prefer to test the event/subscription and not the utility,
-  or the other way around sometimes.
- If the utility is tricky to verify, such as functions manipulating time, write
-  tests ([example](https://github.com/status-im/status-mobile/blob/7774c4eac16fdee950a17bf5d07630c45a980f41/src/utils/datetime.cljs#L1)).
- Utilities can be particularly hard to verify by QAs because they can be lower
-  level and require very particular inputs. In such cases, consider writing
-  tests.
-
-### When to write integration/contract tests?
-
- You want to make real calls to status-go because you think the unit tests are
-  not enough (test pyramid strategy).
- You constantly need to retest the same things on the UI, sometimes over
-  multiple screens.
- The flow is too important to rely only on manual QA, which can't always be
-  done due to resource limits, so an integration/contract test fills this gap.
- You want to rely less on end-to-end tests, which can be more unreliable and
-  slower to change.
- You want automatic verifications for some area of the mobile app whenever
-  status-go is upgraded.
-
-**Note**: the feedback cycle to write integration tests is longer than unit
-tests because they are slower and harder to debug. Using the REPL with them is
-difficult due to their stateful nature.
-
-### When to test Quo components?
-
-This is covered in [quo/README.md#component-tests](https://github.com/status-im/status-mobile/blob/7774c4eac16fdee950a17bf5d07630c45a980f41/src/quo/README.md#component-tests).
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
balogunofafrica	457767f167	add articles folder	2024-04-12 15:56:28 +01:00
BalogunofAfricaandSiddarth Kumar	bab8208de2	Update doc/ui-guidelines.md Co-authored-by: Siddarth Kumar <siddarthkay@gmail.com>	2024-04-12 15:56:28 +01:00
balogunofafrica	434e75e669	add articles section in readme	2024-04-12 15:56:28 +01:00
balogunofafrica	d3a3f04488	update guidelines	2024-04-12 15:56:28 +01:00
balogunofafrica	eb3f2cb132	fix: use ref example	2024-04-12 15:56:28 +01:00
balogunofafrica	84eba2dd55	fix section levels	2024-04-12 15:56:28 +01:00
balogunofafrica	6793aa2994	fix example of useMemo and useCallback	2024-04-12 15:56:28 +01:00
balogunofafrica	043ae742df	add tradeoffs and best scenarios	2024-04-12 15:56:28 +01:00
balogunofafrica	fb2c86b3c8	fix: ui guideline (add notes on meoization)	2024-04-12 15:56:28 +01:00
@@ -1 +1 @@
 .29.0
 .27.0