Fixes the bug by explicitly passing all available addresses to be revealed
to wakuext_requestToJoinCommunity and picking up the first available address
as the airdrop address. This is a temporary solution while we work on the
feature to allow users to choose which addresses to expose.
Fixes https://github.com/status-im/status-mobile/issues/17861
*Areas that may be impacted*: join community flows.
----------------------------------------------------------------------
Community "Request to join" option is enabled.
User holds more than X ETH.
Anyone who holds <X> ETH is allowed to Become member in <COMMUNITY>.
Expected: request to join is received by desktop client and accepted,
mobile user joins the community.
----------------------------------------------------------------------
----------------------------------------------------------------------
Community "Request to join" option is enabled.
User holds less than X ETH.
Anyone who holds <X> ETH is allowed to View and post in <CHANNEL>.
Expected: request to join is received by desktop client and accepted, mobile
user joins the community, but can't post in <CHANNEL>.
----------------------------------------------------------------------
----------------------------------------------------------------------
Community "Request to join" option is enabled.
No token permissions.
Expected: request to join is received by desktop client and accepted,
mobile user joins the community.
----------------------------------------------------------------------
We get these 2 files auto generated locally as part of make lint-fix
`.clj-kondo/taoensso/encore/config.edn`
`.clj-kondo/taoensso/encore/taoensso/encore.clj`
We don't need them checked in its fine if they're ignored.
This commit adds these folders to `.gitIgnore`
- `.clj-kondo/taoensso/`
- `.clj-kondo/babashka/`
- Fix: when there are only channel token permissions, don't show the text "You
hold 0 of these:" because there are no requirements to show.
- Fix: do not show channel token permissions when the user wants to join a
community. In other words: only "become admin", "become member", "become token
master", and "become token owner" are taken in consideration.
- Fix: render correct channel lock icon in 3 states (no permission, with
permissions and locked and with permissions and unlocked).
- Fix: Previously, before having joined a community, all channels had a lock
icon closed, now the lock icon is only closed when there's a permission set,
otherwise no icon is shown (the lock is never open before the user joins the
community).
- Fix: small UI spacing fix, only display community tags component when there's
at least one tag.
- Bonus fix: community Overview and Discover screens top bar had a regression,
see the screenshots.
Fixes https://github.com/status-im/status-mobile/issues/17267
### Areas that may be impacted
- Community overview, before and after joining a community.
### Steps to test
Code tested using the Goerli network and with the testnet flag enabled in the
Desktop client. Out of scope: minted tokens.
This commit moves the emoji categories selector height from the "showcase-nav" component to the "emoji-picker" as we should not use any "quo" ns (except "quo.core") inside the "status-im2" ns.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
This commit updates the following:
- Allow users to create new wallet accounts without having to re-login (latest account data is fetched immediately)
- Updates the max length of the wallet account name to 20
- Updates the account cards in the wallet home screen to render the actual account colour
- Updates the (individual) account screen to show the correct color, emoji, name and address
- Allows users to edit account name, colour and emoji
- The rest of the wallet screens would see the updated account information immediately
- Fixes the color (uses profile color) of the context tag and button color in the authentication (enter password) bottom sheet
- Fixes the overflowing of the "+" card in the wallet home when there are two or more accounts.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
Add account creation screen
remove icons
remove extra utility and create a new one that would use conventional way of getting an emoji
fix lint
Use button component instead of bottom-actions
Provide global customization color to buttons
Use conventional approach to extract account name
Move to another address
Move to another namespace
Refactor bottom-actions to have button props in maps
Update doc with new icon location
Add spaces between styles
Work on pr comments
Use :on-change-text instead of :on-change for input component
Subscribe to :profile/customization-color directly
Use bottom button from the create-or-edit-account wrapper
Remove extra code
Sort requires
Move ns to proper fileˆ
Fix styles
The design team has now decided to keep iPhone 13 as the baseline standard instead of iPhone 11 Pro.
This commit updates the docs on pixel perfection and starting guide.
We also update the default simulator to iPhone 13 for `make run-ios`
This commit updates the following in the selectors component:
- Introduces the "type" prop (Figma 1-1 property) to the selectors component for easy switching between the selector types while using it on lists.
- Updates the component styles to use the "resolve-color" function as the "custom-color" function is deprecated
- Updates the component usage across the codebase
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
Fix the unreliable swipe behavior of link previews in the chat composer. In many
occasions, we noticed the horizontal scroll wasn't being triggered properly or
not at all. In other occasions, the swipe gesture would incorrectly register a
press on the parent `Touchable` component.
Fixes https://github.com/status-im/status-mobile/issues/16599
fix: improving UI and gestures
fix: expanding on press now works reliably
fix: center text and disable gestures for short messages
feat: added styling for one-lined messages
fix: small opacity fix
ref: small condition change
fix: horizontal swiping being unreliable with vertical scrolling
ref: reusing shared value from lightbox animations
fix: text-sheet bottom gradient not visible on android
fix: addressed qa issues 1,2,4
fix: zoomable-image stuck if moved vertically when full screen
clean: removed unused var
chore: removed unused require
fix: don't allow returning text-sheet down and up in one move
fix: text-sheet bar styling was wrong
fix: adjusted gradient animation with designs
fix: text-sheet bar opacity
* Align docstring
* Create share-qr-code component
* Remove empty style file
* Implement common.share-qr-code including call to media server
* Add share-qr-code preview screen
* Use share-qr-code component in shell's share screen
* Add tests and some fixes
* feat: debug/show components from the REPL
* ref: some renames and cleanup
* chore: removed comments/imports
* feat: added remount on every eval & small changes
* doc: added tip to debugging doc
* doc: formatting
* doc: more formatting
* fix: fixed docs and other review comments
* fix: moved & renamed into the dev.component-preview ns
* style: adjusted debugging readme spacing
* fix: removed trailing line
Many times devs run
`make component-test` or `make component-test-watch` when there is already a metro or clojure terminal running on their system.
This causes weird behaviour and it is advised to not run these commands together.
This commit prevents that and shows a warning.
Document how a VSCode user can configure their editor to auto-format
Clojure(Script) files that respect all the formatter (zprint) settings specified
in status-mobile/.zprintrc.
The result should be that on every file save, the file should be identically
formatted as if you used make lint-fix, at least the part about zprint. If
lint-fix does other things now or in the future that are outside the scope of
zprint, those won't be covered by the VSCode extension.
Upgrades and cleans up all production Clojure dependencies and 1 dev-only
dependency (com.taoensso/tufte).
- Remove warning "WARNING: update-keys already refers to:
#'clojure.core/update-keys in namespace: io.aviso.exception"
- Remove hickory and mvxcvi/alphabase dependencies they are not used.
- Upgrade com.taoensso/tufte from 2.1.0 to 2.6.3
- Upgrade transit-cljs from 0.8.248 to 0.8.280
- Upgrade cljs-bean from 1.3.0 to 1.9.0
- Remove workaround for com.taoensso/timbre in shadow-cljs.edn
- Upgrade com.taoensso/timbre from 4.10 (Status fork) to 6.3.1
This commit
- Adds the base Screen base for the Create/Edit Account/Address
- Adds the Wallet Edit Account screen
- Adds the gradient in the account options bottom sheet
- Adds a new key/prop "right-icon" in the data-item component to prevent overlapping with the icon used in the description and updates its usage.
- Updates the "section-label" component to receive "container-style" (this will prevent adding a wrapping view in the screens)
---------
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
We've often seen cases of devs attempting to change dependencies outside a nix-shell and run into weird side effects
This commit stops them from :
- updating pods outside a nix shell
- updating node deps outside a nix shell
This commit also cleanup unused scripts in package.json and adds a fake comment script.
Since the `default` shell doesn't have Ruby, the `nix-update-gems`
target would incorrectly use the system Ruby instead of the one from Nix.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Adapt the JSON RPC response to the new shape returned by `wakuext_unfurlURLs` on
v0.170.0. The changes were introduced PR
https://github.com/status-im/status-go/pull/4033. There are no behavioral
changes in the API as far as mobile is concerned at the moment.
Clojure dependencies require only JARs to work. Downloading POMs is both
a waste of time, space, and bandwidth. In addition POMs create edge
cases that we would have to handle, an would rather avoid.
For example, the `guice` package which shows up in the classpath
includes a JAR named `guice-4.2.2-no_aop.jar`. The issue with that is
that there is no corresponding POM in the directory:
https://repo1.maven.org/maven2/com/google/inject/guice/4.2.2/
Either we have to make a special case for such packages, or we can just
skip POMs entirely and avoid the mess.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This commit adds a custom linter to verify i18n/label is called with a qualified
keyword, like :t/foo. More sophisticated linters are possible too.
We also set the stage for other developers to consider more lint automation
instead of manually reviewing conventions in PRs.
If you want to understand how to write custom linters, check out
https://github.com/clj-kondo/clj-kondo/blob/master/doc/hooks.md. You can fire
the Clojure JVM REPL in status-mobile and play with the clj-kondo hook too, it
works beautifully.
Why do we care? By making sure all translation keywords are qualified with "t",
it is trivial to grep or replace them because they're unique in the repo, and
can't be confused with other words if you search by ":t/<something>".
Note: It's a best practice to commit clj-kondo configuration from external
libraries in the .clj-kondo directory. The directory .clj-kondo/babashka is
auto-generated, that's why it was added.
This commit fixes the following issues in the bottom sheet:
- the sheet is cut off at the bottom in the shell (dark blur) theme (the drawers in the onboarding/login flow)
- the incorrect background in the shell (dark blur) theme (the drawers in the onboarding/login flow)
Bug
- the spacing at the bottom is doubled
- the gradient cover is not shown in the bottom sheet
- the spacing between the selected item and the bottom sheet
- the bottom sheet type in "Create Profile" and "Activity Center" screens
---------
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
* Rename wallet-user-avatar's `:color` prop to `:customization-color`
* Refactor QR code component and implement all variants
- Improve preview screen
* Update QR code usages
* Remove `status-im2.common.qr-code-viewer.view/qr-code-view` component
to keep only one implementation.
* Remove the node dependency:
"qrcode": "^1.4.1"
This commit fixes the "X" mark in the clear icon displayed in inputs and URL preview components by updating the props for "svg-icon" to add the "color" and "color-2" keys only if it's present and valid.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
This commit shows how to move away from rf/defn
https://github.com/status-im/status-mobile/blob/f12c7401d167d7adb81f97bdf9c0902b39ee37bc/src/utils/re_frame.clj#L1-L90
& rf/merge
https://github.com/status-im/status-mobile/blob/f12c7401d167d7adb81f97bdf9c0902b39ee37bc/src/utils/re_frame.cljs#L39-L85
and why we should do it.
## Problems
Before jumping to solutions, let's understand the problems first, in no order of
importance.
### Problem 1: Cyclic dependencies
If you ever tried to move event handlers or the functions used inside them to
different files in status-mobile, you probably stumbled in cyclic dependency
errors.
When an event is registered in re-frame, it is globally available for any other
place to dispatch. The dispatch mechanism relies on globally unique keywords,
the so called event IDs, e.g. :chat/mute-successfully. This means that event
namespaces don't need to require other event namespaces, just like you don't
need to require subscription namespaces in views.
rf/merge increases the likelihood of cyclic dependencies because they force
event namespaces to require each other. Although not as common, this happened a
few times with devs in the team and it can be a big hassle to fix if you are
unlucky. It is a problem we should not have in the first place (at least not as
easily).
### Problem 2: We are not linting thousands of lines of code
The linter (clj-kondo) is incapable of understanding the rf/defn macro. In
theory, we could teach clj-kondo what the macro produces. I tried this, but gave
up after a few tries.
This is a big deal, clj-kondo can catch many issues and will continue to catch
more as it continue to evolve. It's hard to precisely count how many lines are
affected, but `find src/ -type f -name 'events.cljs' -exec wc -l {} +` gives us
more than 4k LOC.
### Problem 3: Blocking RN's UI thread for too long
Re-frame has a routing mechanism to manage events. When an event is dispatched,
it is enqueued and scheduled to run some time later (very soon). This process is
asynchronous and is optimized in such a way as to balance responsiveness vs the
time to empty the queue.
>[...] when processing events, one after the other, do ALL the currently queued
>events. Don't stop. Don't yield to the browser. Hog that CPU.
>
>[...] but if any new events are dispatched during this cycle of processing,
>don't do them immediately. Leave them queued.
>
>-- https://github.com/day8/re-frame/blob/master/src/re_frame/router.cljc#L8-L60
Decisions were made (way back in 2017) to reduce the number of registered
re-frame events and, more importantly, to coalesce events into bigger ones with
the rf/merge pattern. I tried to find evidence of real problems that were trying
to be solved, but my understanding is that decisions were largely based on
personal architectural preferences.
Fast-forward to 2023, and we are in a situation where we have many heavy events
that process a LOT of stuff in one go using rf/merge, thus blocking the UI
thread longer than we should. See, for example,
[status-im2.contexts.profile.login.events/login-existing-profile](https://github.com/status-im/status-mobile/blob/3082605d1e9897da1b1784588aa22fdc65c84823/src/status_im2/contexts/profile/login/events.cljs#L69),
[status-im2.contexts.profile.login.events/get-chats-callback](https://github.com/status-im/status-mobile/blob/3082605d1e9897da1b1784588aa22fdc65c84823/src/status_im2/contexts/profile/login/events.cljs#L98),
and many others.
The following excerpt was generally used to justify the idea that coalescing
events would make the app perform better.
> We will reduce the the amount of subscription re-computations, as for each
> distinct action, :db effect will be produced and swapped into app-db only once
>
> -- https://github.com/status-im/swarms/issues/31#issuecomment-346345981
This is in fact incorrect. Re-frame, ever since 2015 (so before the original
discussions in 2017) uses a concept of batching to process events, which means
subscriptions won't re-run after every dispatched event, and thus components
won't re-render either. Re-frame is smarter than that.
> groups of events queued up will be handled in a batch, one after the other,
> without yielding to the browser (previously re-frame yielded to the browser
> before every single event).
>
> -- https://github.com/day8/re-frame/blob/39adca93673f334dc751ee2d99d340b51a9cc6db/docs/releases/2015.md#050--2015-11-5
Here's a practical example you can try in a shadow-cljs :mobile REPL to see the
batching behavior in practice.
```clojure
;; A dummy event that toggles between DEBUG and INFO levels.
(re-frame/reg-event-fx :dummy-event
(fn [{:keys [db]}]
{:db (update-in db
[:profile/profile :log-level]
(fn [level]
(if (= "DEBUG" level)
"INFO"
"DEBUG")))}))
(def timer
(js/setInterval #(re-frame/dispatch [:dummy-event])
50))
;; 1. In component status-im.ui.screens.advanced-settings.views/advanced-settings,
;; add a print call to see when it's re-rendered by Reagent because the
;; subscription :log-level/current-log-level will be affected by our dummy event.
;;
;; 2. Also add a print call to the subscription :log-level/current-log-level to
;; see that the subscription does NOT re-run on every dispatch.
;; Remember to eval this expression to cancel the timer.
(js/clearInterval timer)
```
If you run the above timer with 50ms interval, you'll see a fair amount of
batching happening. You can infer that's the case because you'll see way less
than 20 print statements per second (so way less than 20 recomputations of the
subscription, which is the max theoretical limit).
When the interval is reduced even more, to say 10ms (to simulate lots of
dispatches in a row), sometimes you don't see a single recomputation in a 5s
window because re-frame is too busy processing events.
This shows just how critical it is to have event handlers finishing as soon as
possible to relinquish control back to the UI thread, otherwise responsiveness
is affected. It also shows that too many dispatches in a row can be bad, just as
big event handlers would block the batch for too long. You see here that
dispatching events in succession does NOT cause needless re-computations.
Of course there's an overhead of using re-frame.core/dispatch instead of calling
a Clojure function, but the trade-off is clearly documented: the more we
process in a single event, the less responsive the app may be because re-frame
won't be able to relinquish control back to the UI thread. The total time to
process the batch increases, but re-frame can't stop in the middle compared to
when different dispatches are used.
Thus, I believe this rf/merge pattern is harmful as a default practice in an
environment such as ours, where it's desirable end-users feel a snappy RN app. I
actually firmly believe we can improve the app's responsiveness by not
coalescing events by default. We're also preventing status-mobile from taking
the most advantage from future improvements in re-frame's scheduler. I can
totally see us experimenting with other algorithms in the scheduler to best fit
our needs. We should not blindly reduce the number of events as stated here
https://github.com/status-im/status-mobile/pull/2634#discussion_r155243127.
Solution: only coalesce events into one pile when it's strictly desirable to
atomically update the app db to avoid inconsistencies, otherwise, let the
re-frame scheduler do its job by using fx, not rf/merge. When needed, embrace
*eventual app db consistency* as a way to achieve lower UI latency, i.e. write
fast and short events, intentionally use :dispatch-later or other timing effects
to bend the re-frame's scheduler to your will.
There's another argument in favor of using something like rf/merge which I would
like to deconstruct. rf/merge gives us a way to reuse computations from
different events, which is nice. The thing here is that we don't need rf/merge
or re-frame to reuse functions across namespaces. rf/merge complects re-frame
with the need to reuse transformations.
Instead, the solution is as trivial as it gets, reuse app db "transformers"
across events by extracting the logic to data store namespaces
(src/status_im/data_store). This solution has the added benefit of not causing
cyclic dependency errors.
### Problem 4: Clojure's language server doesn't understand code under rf/defn
Nowadays, many (if not most) Clojure devs rely on the Clojure Language Server
https://github.com/clojure-lsp/clojure-lsp to be more effective. It is an
invaluable tool, but it doesn't work well with the macro rf/defn, and it's a
constant source of frustration when working in event namespaces. Renaming
symbols inside the macro don't work, finding references, jumping to local
bindings, etc.
Solution: don't use rf/defn, instead use re-frame's reg-event-fx function and
clojure-lsp will understand all the code inside event handlers.
### Problem 5: Unit tests for events need to "test the world"
Re-frame's author strongly recommends testing events that contain non-trivial
data transformations, and we do have many in status-mobile (note: let's not
confuse with integration tests in status_im/integration_test.cljs). That, and
non-trivial layer-3 subscriptions should be covered too. The reasoning is that
if we have a well developed and tested state layer, many UI bugs can be
prevented as the software evolves, since the UI is partially or greatly derived
from the global state. See re-frame: What to Test?
https://github.com/day8/re-frame/blob/39adca93673f334dc751ee2d99d340b51a9cc6db/docs/Testing.md#what-to-test.
See PR Introduce subscription tests
https://github.com/status-im/status-mobile/pull/14472, where I share more
details about re-frame's testing practices.
When we use rf/merge, we make unit testing events a perennial source of
frustration because too many responsibilities are aggregated in a single event.
Unfortunately, we don't have many devs in the team that attempted to write unit
tests for events to confirm my claim, but no worries, let's dive into a real
example.
In a unit test for an event, we want to test that, given a cofx and args, the
event handler returns the expected map of effects with the correct values
(usually db transformations).
Let's assume we need to test the following event. The code is still using the
combo rf/defn & rf/merge.
```clojure
(rf/defn accept-notification-success
{:events [:activity-center.notifications/accept-success]}
[{:keys [db] :as cofx} notification-id {:keys [chats]}]
(when-let [notification (get-notification db notification-id)]
(rf/merge cofx
(chat.events/ensure-chats (map data-store.chats/<-rpc chats))
(notifications-reconcile [(assoc notification :read true :accepted true)]))))
```
As you can see, we're "rf/merging" two other functions, namely ensure-chats and
notifications-reconcile. In fact, ensure-chats is not registered in re-frame,
but it's 99% defined as if it's one because it needs to be "mergeable" according
to the rules of rf/merge. Both of these "events" are quite complicated under the
hood and should be unit tested on their own.
Now here goes the unit test. Don't worry about the details, except for the expected output.
```clojure
(deftest accept-notification-success-test
(testing "marks notification as accepted and read, then reconciles"
(let [notif-1 {:id "0x1" :type types/private-group-chat}
notif-2 {:id "0x2" :type types/private-group-chat}
notif-2-accepted (assoc notif-2 :accepted true :read true)
cofx {:db {:activity-center {:filter {:type types/no-type :status :all}
:notifications [notif-2 notif-1]}}}
expected {:db {:activity-center {:filter {:type 0 :status :all}
:notifications [notif-2-accepted notif-1]}
:chats {}
:chats-home-list nil}
;; *** HERE ***
:dispatch-n [[:activity-center.notifications/fetch-unread-count]
[:activity-center.notifications/fetch-pending-contact-requests]]}
actual (events/accept-notification-success cofx (:id notif-2) nil)]
(is (= expected actual)))))
```
Notice the map has a :dispatch-n effect and other stuff inside of it that are
not the responsibility of the event under test to care about. This happens
because rf/merge forces the event handler to compute/call everything in one go.
And things get MUCH worse when you want to test an event A that uses rf/merge,
but A calls other events B and C that also use rf/merge (e.g. event
:profile.login/get-chats-callback). At that point you flip the table in horror
😱, but testing events and maintaining them should be trivial.
Solution: Use re-frame's `fx` effect.
Here's the improved implementation and its accompanying test.
```clojure
(defn accept-notification-success
[{:keys [db]} [notification-id {:keys [chats]}]]
(when-let [notification (get-notification db notification-id)]
(let [new-notifications [(assoc notification :read true :accepted true)]]
{:fx [[:dispatch [:chat/ensure-chats (map data-store.chats/<-rpc chats)]]
[:dispatch [:activity-center.notifications/reconcile new-notifications]]]})))
(re-frame/reg-event-fx :activity-center.notifications/accept-success accept-notification-success)
(deftest accept-notification-success-test
(testing "marks notification as accepted and read, then reconciles"
(let [notif-1 {:id "0x1" :type types/private-group-chat}
notif-2 {:id "0x2" :type types/private-group-chat}
notif-2-accepted (assoc notif-2 :accepted true :read true)
cofx {:db {:activity-center {:filter {:type types/no-type :status :all}
:notifications [notif-2 notif-1]}}}
;; *** HERE ***
expected {:fx [[:dispatch [:chat/ensure-chats []]]
[:dispatch [:activity-center.notifications/reconcile [notif-2-accepted]]]]}
actual (events/accept-notification-success cofx [(:id notif-2) nil])]
(is (= expected actual)))))
```
Notice how the test expectation is NOT verifying what other events do (it's
actually "impossible" now). Using fx completely decouples events and makes
testing them a joy again.
### Problem 6: Unordered effects
status-mobile still uses the legacy way to describe the effects map, which has
the problem that their order is unpredictable.
> Prior to v1.1.0, the answer is: no guarantees were provided about ordering.
> Actual order is an implementation detail upon which you should not rely.
>
> -- https://github.com/day8/re-frame/blob/39adca93673f334dc751ee2d99d340b51a9cc6db/docs/Effects.md#order-of-effects
> In fact, with v1.1.0 best practice changed to event handlers should only
> return two effects :db and :fx, in which case :db was always done first and
> then :fx, and within :fx the ordering is sequential. This new approach is more
> about making it easier to compose event handlers from many smaller functions,
> but more specificity around ordering was a consequence.
>
> -- https://github.com/day8/re-frame/blob/39adca93673f334dc751ee2d99d340b51a9cc6db/docs/Effects.md#order-of-effects
### Problem 7: Usage of deprecated effect dispatch-n
We have 35 usages, the majority in new code using dispatch-n, which has been
officially deprecated in favor of multiple dispatch tuples in fx. See
https://github.com/day8/re-frame/blob/39adca93673f334dc751ee2d99d340b51a9cc6db/docs/api-builtin-effects.md#L114
### Problem 8: Complexity 🧙♂️
Have you ever tried to understand and/or explain how rf/merge and rf/defn work?
They have their fare share of complexity and have tripped up many contributors.
This is not ideal if we want to create a project where contributors can learn
re-frame as quickly as possible. Re-frame is already complicated enough to grasp
for many, the added abstractions should be valuable enough to justify.
Interestingly, rf/merge is a stateful function, and although this is not a
problem in practice, it is partially violating re-frame's spirit of only using
pure functions inside event handlers.
### Problem 9: Using a wrapping macro rf/defn instead of global interceptors
When rf/defn was created inside status-mobile, re-frame didn't have global
interceptors yet (which were introduced 3+ years ago). We no longer have this
limitation after we upgraded our old re-frame version in PR
https://github.com/status-im/status-mobile/pull/15997.
Global interceptors are a simple and functional abstraction to specify functions
that should run on every event, for example, for debugging during development,
logging, etc. This PR already shows this is possible by removing the wrapping
function utils.re-frame/register-handler-fx without causing any breakage.
## Conclusion
By embracing re-frame's best practices for describing effects
https://github.com/day8/re-frame/blob/39adca93673f334dc751ee2d99d340b51a9cc6db/docs/FAQs/BestPractice.md#use-the-fx-effect,
we can solve long standing issues that affect every contributor at different
levels and bring the following benefits:
- Simplify the codebase.
- Bring back the DX we all deserve, i.e. Clojure Language Server and clj-kondo
fully working in event namespaces.
- Greatly facilitate the testability of events.
- Give devs more flexibility to make the app more responsive, because the new
default would not coalesce events, which in turn, would block the UI thread
for shorter periods of time. At least that's the theory, but exceptions will
be found.
The actions to achieve those benefits are:
- Don't use the macro approach, replace rf/defn with
re-frame.core/reg-event-fx.
- Don't use rf/merge, simply use re-frame's built-in effect :fx.
- Don't call event handlers as normal functions, just as we don't directly call
subscription handlers. Use re-frame's built-in effect :fx.
## How do we refactor the remainder of the code?
Some numbers first:
- There are 228 events defined with rf/defn in src/status-im2/.
- There are 34 usages of rf/merge in src/status_im2/.
## Resources
- Release notes where fx was introduced in re-frame:
https://github.com/day8/re-frame/blob/39adca93673f334dc751ee2d99d340b51a9cc6db/docs/releases/2020.md#110-2020-08-24
Change the make "lint" target default behavior to NOT show clj-kondo warnings.
In the CI, I kept the same behavior, i.e. show all warnings and errors
simultaneously.
Motivation:
When devs run make lint, most of the time, they don't want to see a long list of
warnings. Their focus is on the errors. Additionally, the majority of devs in
the mobile team see clj-kondo warnings in their editors of choice already.
We (some of us) believe the editor feedback/warnings are sufficiently noisy.
Add the following somewhere in your config files if you want to see
warnings.
export CLJ_LINTER_PRINT_WARNINGS=true
This commit:
- Removes the existing dropdown component which uses the old button component under the hood
- Implements the Dropdown component
- Updates the usage in the page-nav component for types dropdown, token and wallet-networks
- Updates the usage in the photo selector bottom sheet
- Updates the usage in the Quo2 preview main screen
---------
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
to accomplish #17288
migrated :
notifications
Issue Opened: A bug has been identified within the activity-logs component and is currently under investigation.
This commit updates
- the preview-list component to use "number-tag" for overflow items in the list as a follow-up of the PR Update "Preview list" component.
- the usage of the preview-list component in the context-tag (multiuser and multinetwork type) is updated as it was broken.
- the size APIs of preview-list and number-tag and their usage across the codebase to respect the new guidelines.
---------
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
* chore: update guidelines for sizes
* chore: update to size uses in codebase to follow new convention
---------
Co-authored-by: Ulises M <ulises.ssb@hotmail.com>
After upgrading to Xcode 15 make run-ios would fail with
```
❌ /Users/siddarthkumar/code/status-im/PR/status-mobile/ios/Pods/boost/boost/container_hash/hash.hpp:131:33: no template named 'unary_function' in namespace 'std'; did you mean '__unary_function'?
struct hash_base : std::unary_function<T, std::size_t> {};
```
This commit fixes the issue and makes existing codebase compatible with newer Xcode.
reference issue in react-native repo : facebook/react-native#37748
* use new API for ens name registration
https://github.com/status-im/status-go/compare/4cc53630...223d215e
* update status-go-version.json
* update status-go-version.json
* fix Error:Field validation for 'KeycardPairingDataFile' failed on the 'required' tag
* update status-go-version.json
* fix lint issue
Recently, we changed clj-kondo default fail-level from "warning" to "error", but
we missed the fact that we needed to raise the default level for all linters set
to "warning".
Every keypress on an input field of the preview descriptor re-rendered the whole
functional component and the input focus was lost.
As we know from past issues, we should never use this pattern:
(defn component
[]
[:f>
(fn []
...)])
Force re-frame to stop warning about subscriptions in non-reactive contexts
while executing subscription tests (i.e. unit tests using the macro
test-helpers.unit/deftest-sub).
The net result? No more hundreds of useless warnings in the output of make test.
re-frame: Subscribe was called outside of a reactive context.
See: https://day8.github.io/re-frame/FAQs/UseASubscriptionInAJsEvent/
The warning is actually useful in production code, but in a subscription test we
already know we're never inside a reactive context.
This PR resolves the issue where Composer becomes detached from the footer during the chat history loading phase, specifically when the skeleton screen is displayed. Fixes#17237.
### Commit Summary
This pull request updates our coding guidelines to include a process for marking deprecated functions using metadata in ClojureScript.
fixes#17103
### Follow up from #16865
This commit focuses on enhancing the user experience by replacing our legacy skeleton loaders with the latest version. Additionally, it introduces a refined approach for deprecating outdated components and functions to maintain a cleaner codebase.
### Key Changes
Replace existing skeleton loaders with the latest skeleton-list component for improved performance and usability.
Implement a standardized deprecation method, using either naming conventions or metadata annotations, for phasing out old components and functions.
Disable :fn-deprecated warnings from the Closure compiler for the mobile
shadow-cljs target during development. The compiler warnings are no longer
necessary, because we're managing deprecation via clj-kondo.
Without the compiler setting's change, every code reload will generate warnings
for each and every deprecated call in the repo, which can quickly grow to the
hundreds or more, thus making the terminal output horrendous to understand.
Also set clj-kondo's "fail-level" to "error" (the default is "warning").
This commit removes the dependency of the IOS Target for `show-ios-devices` command.
We no longer need the IOS target because the default shell contains the `ios-deploy` library, which is used by this command already.
Unshadows all remaining vars in status-mobile, including non
cljs.core/clojure.core ones. The only exceptions are cljs.core/type and
cljs.core/name (which happen quite often, so I'm not sure if it's worth
unshadowing them).
Fixes: #16123
This commit changes the behavior when joining communities:
1) If the user hasn't joined a community, they will see the
non-collapsed header.
2) If the user has already joined the community, they will see a
collapsed version of the header, in order to have quicker access to
the chats of the community without having to scroll a lot.
One edge case that is taken care of is the following:
1) User visits a community that has not joined, requests to join.
2) The user is on the community page when the state changes from
not-joined -> joined.
In this case the user won't see the collapsed header until they leave
the community view (go back to home say and back to communities).
This is done in order to avoid some janky transition between the non
collapsed & collapsed version of the header.
This is slightly different from as mentioned in the issue "visiting the
page for the 2nd time", as that will require larger changes but it
should be an acceptable behavior, since most of the times they will have
to visit the overview to request access.
Add icon-name to group avatar
Add missing context-tags variants and fix the API to match figma
Updates context-tag previous uses
Update use of group-avatar api
* Refactor page-nav and fix API
* Update and fix page-nav in scroll-page component
* Update page-nav uses in quo-preview
* Update page-nav uses in syncing
* Update page-nav uses in communities
* Update page-nav uses in wallet
* Update page-nav uses in onboarding
This commit updates the "Preview list" component to support the following types (according to Figma):
- collectibles
- dapps
- accounts
- network
- tokens
Additionally, imports the images for wallet networks and dApps.
---------
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
Fixes partially #15595
In order to build less targets, when not needed we introduce this
mapping logic.
If only specific ABI is required - status-go will have the same
arhitecuture.
This commit adds Gradient Background in the bottom sheet which will be used in Wallet Account Actions, and Switcher bottom sheet.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
Improvements to quo previews:
- Change quo-preview.preview code to be more aligned with our guidelines.
- Remove duplication when setting up preview screens in quo-preview.main. Now we
only need to specify the :name and :component keys and fallback to a good
default for "{:options {:topBar {:visible true}}".
- Auto-generate descriptor labels based on the key.
- Fix form field colors for dark & light, especially for Android.
- Redesigned form fields to look nicer 💄
- Create component that abstracts away the code for rendering the form fields
and the preview area. This will aid us in creating more consistent looking
preview screens and keep things DRY.
How do we use the new code?
Just as before, define a state binding and use it to build up the arguments of
the component. Then, use the preview/preview-container to wrap the component.
You can use certain props to control how the preview is styled, etc, but that's
about it.
(def descriptor
[{:type :text :key :label}
{:key :chevron-position
:type :select
:options [{:key :left}
{:key :right}]}])
(defn view
[]
(let [state (reagent/atom {:chevron-position :left
:label "Welcome"})]
(fn []
[preview/preview-container {:state state :descriptor descriptor}
[quo/divider-label @state]])))
* Inherit custom colour for unread notification dots
* Code style update; notification-dot as a separate component
* Code style update; notification-dot as a separate component
* Removed leftovers
* Updates
* Lint fix
* chore: update quo2 group avatar to best practices
* chore: update quo2 browser-input to best practices
* chore: update quo2 dynamic-button to best practices
* chore: update quo2 tabs to best practices
* chore: cleanup quo2 core file
* chore: use best practices in quo2 banner
* chore: use best practices in quo2 step
This pr. add blur background on continue button on create profile screen should the button container cover the profile color picker when the keyboard is shown
* show button background on scroll
* fix show button on scroll different platforms
* fix: button container loading
* fix: button container background delay
* Add bind-component function to `react-native.navigation`
* Create helper function to use react-native-navigation lifecycle methods
* Fix sync QR code not recognized after trying again & refactor
* Add atom to manage callbacks when qr code scan fails
This commit implements the "Progress bar" component which is needed for wallet screen development.
Additionally, this commit adds a new test helper method "render-with-theme-provider" to test components in different themes.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
* Small typo fix
* Move header-spacing & empty-state to common.home namespace
* Create common animated banner component for chats and communities
* Add animated banner to chats tab
This commit adds two new entry points (button on the top right corner in the navigation bar) for the Quo2 preview screen without having to log in to the app:
- "New to Status"
- "login"
Additionally, this commit updates the theme switcher to be sticky at the top of the Quo2 preview screen to quickly change the theme without having to scroll all the way top.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
This commit adds the "on-press" prop to the "collectible" component which is required for navigating to other screens, such as the details screen when we will start building the wallet.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
This commit implements the "gradient cover" component which is needed for wallet screen development, and upgrades the "react-native-linear-gradient" library to "v2.8.0".
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
* Small refactor & add customization color to `info-count` component
* Fix notification mark in group chats for no mentions, also notification alignment styles in the component
* Code style: `change > 0` for `pos?`
* Simplifies community banner and adds style property
* Add animation for communities banner card
* Moves value-in-range to `utils.number` and removes `bounded-val`
* Moves animated values to view namespace
* Make `community.banner` component themeable
This commit upgrades Shadow CLJS from 2.11.16 (released on Feb/21) to latest
2.25.0 (Jul/23), so ~1.5 years worth of upgrades. By upgrading shadow we
can finally use the latest major Clojure version 1.11.x.
Why upgrade shadow?
- Shadow CLJS controls the ClojureScript version we can use. In order to use the
latest major Clojure version we must upgrade Shadow CLJS.
- Shadow CLJS releases new versions very frequently, and if you take a look at
its changelog https://github.com/thheller/shadow-cljs/blob/master/CHANGELOG.md, you'll see
it had tons and tons of bug fixes over the years. I hope some of them help
improve the DX for certain contributors who recently reported issues with
it.
- Clojure 1.11 brings new features, bug fixes and even performance improvements
(although I think the performance mostly impacts Clojure on the JVM). See the
changelog https://github.com/clojure/clojure/blob/master/changes.md#changes-to-clojure-in-version-1110
Things that can be beneficial to us, or are interesting nonetheless:
- New :as-alias to be used in require, which is like :as but does not require
the namespace to load. This means namespaced keywords using :as-alias can't
cause circular dependency errors. This feature would very useful if we used
namespaced keywords, but we don't, so...
https://github.com/clojure/clojure/blob/master/changes.md#22-as-alias-in-require
- New macros run-test and run-test-var to run single test with fixtures and
report.
- New iteration function, useful for processing paginated data.
https://www.abhinavomprakash.com/posts/clojure-iteration/
- New update-keys function: applies a function to every key in a map.
- New update-vals function: applies a function to every value in a map.
Examples for update-vals and update-keys. They should perform better than the
common reduce-kv approach since they use a transient data structure.
(let [m {:a 1 :b 2}]
(update-vals m inc)) ; => {:a 2, :b 3}
(let [m {:a 1 :b 2}]
(update-keys m name)) ; => {"a" 1, "b" 2}
Why change namespaces within __tests__ directories?
Any namespace with the word --tests-- throws an error, like the one below. I
didn't bother investigating why, so I changed the guidelines to reflect the new
convention. It's probably related to the double dashes in the name.
Namespace quo2.components.dividers.--tests--.divider-label-component-spec has a
segment starting with an invalid JavaScript identifier at line 1
This commit initialises the status-go method `startSearchForLocalPairingPeers` which in turn will produce logs that are important for peer discovery while local pairing and will produce logs important to detect local pairing crashes.
This is a continuation of https://github.com/status-im/status-mobile/pull/16500 (Lint
& fix some shadowed core Clojure(Script) vars).
Notes: As a reminder, the goal is to eventually disallow shadowing core Clojure
vars entirely, but to get there and avoid rebase hell and regressions, we need
to do in smaller steps, especially because we can't safely automate the process
of unshadowing vars.
We are already down from ~500 shadowed core vars to 350 in total.
Why is this PR is using names such as "s", "v" or "sym"? Names such as s or v
are the so called idiomatic names, and are listed in the Clojure Style Guide
https://guide.clojure.style/#idiomatic-names. I used them whenever I felt
appropriate. For the var cljs.core/symbol I opted to use sym, even though the
symbol in question is not necessarily a Clojure symbol, I think the alias
conveys the meaning well enough
(https://www.clojure.org/guides/learn/syntax#_symbols_and_idents).
New vars linted:
- comparator
- identity
- str
- symbol
- val
Outstanding shadowed vars include type, name, hash, comp.
This commit refactors the "Toast" component to use theme context for consistency across the codebase.
Each toast will have its theme provider, which will help the children to use the context properly without interfering with other toast's context.
The following components are refactored to use with-theme / theme-context as it is used in the "Toast":
- "text" component
- "user-avatar" component
- "icon" component
- "circle-timer" component
This commit also updates the icon keyword used in the ":toasts/upsert" event dispatch to respect icon guidelines.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
* chore: refactor button and add use for community colors
* chore: update color in button to work with community color
* chore: correct uses of button across app
This commit updates "Bottom Sheet" to use the theme (for theme provider) provided on the bottom sheet args when dispatching. This will ensure the theme is passed down to its child components where it can consume and render based on the theme.
Changes done:
In Bottom Sheet:
- Fix Bottom Sheet to use the correct background colour (neutral-95) for dark mode (as per Figma)
- Fix the Icon colour for danger in light mode
- Updated Quo2 Preview to provide an option for the bottom sheet theme
In Action Drawer:
- Refactor the Action Drawer component to consume theme context
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
This commit fixes (by skipping) the scroll to the bottom of messages when the user edits a message and sends it.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
Rewrite the shadows foundation API:
- Fix (implementation & usages): theme changes were not causing shadows to be
reevaluated.
- Optimization: define all possible shadow values at compile time. Good to
reduce cycles on garbage collection since recreating the shadow map all the
time is unnecessary and also to save cycles on computing colors since calls to
colors/alpha are not memoized.
- API redesign: unify access to Design System shadows in a single function.
None of the actual shadow values changed.
Fixes https://github.com/status-im/status-mobile/issues/16526
API rationale
=============
The quo2.foundations.shadows namespace reflects what's in the Design System >
Foundations > Shadows https://www.figma.com/file/v98g9ZiaSHYUdKWrbFg9eM/Foundations?type=design&node-id=624-965&mode=design&t=CvIotdjbHKHcHjpd-0).
Figma users see these shadows in other components as "Shadow/Normal/Light/03".
Notice the shadow's weight is shown as a number (not the semantic name in Figma,
e.g. "intense", "strong"):
So to make things as easy as possible, I opted for exposing a single public
function named "get", which receives arguments in order of frequency of usage
and which expects shadow weights as numbers so that devs don't need to mentally
translate 1 to "soft", or 3 to "intense".
Re-implements the component Community List according to guidelines
and, most importantly, fixes a bunch of issues and tries to achieve 100%
compatibility with Figma.
The new implementation is trying to mirror Figma properties as much as possible.
Fixes https://github.com/status-im/status-mobile/issues/16447
Changelog:
- Refactor to guidelines.
- Fix: original implementation in money/format-amounts had a bug caught by new
unit tests ("1000000" was formatted incorrectly).
- Fix: Community permission tag correct background when theme is overridden and
when blur is enabled.
- Fix: Notification dot uses correct colors for dark mode and blur variants.
- Fix: Community stats background when blur is enabled.
- Fix: Community stats icon color when blur is enabled.
- Add: The component's Quo preview screen is smarter and will only show form
fields (aka descriptors) that are relevant for each component type (engage,
discover or share).
- Add: replace hardcoded community statistics with an implementation that
actually accepts real numbers and which are correctly formatted.
- Add: New Quo descriptor type number.
- Add: Component uses correct shadows according to foundations/shadows.
This commit fixes the seen state of notifications, if the user is in the Activity Center screen while receiving a new notification.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
This commit fixes the profile colour in the following screens:
- "View Profile" button on the "Add a contact" page
- "Jump to" button inside the chat
- "Jump to" button in the "Community Overview" screen
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
- Community channels may not have an emoji, and in such cases, it should fall
back to a single letter. The component was recently updated in Figma after
this concern was brought up to designers.
- The default (fallback) color to be used in the list of community channels
should be the community color, not a default "primary-50" as was before. It's
a subtle change because the colors are rendered at 10% transparency.
- Rewrote the channel-avatar component to follow guidelines.
Fixes:
- https://github.com/status-im/status-mobile/issues/16332
- https://github.com/status-im/status-mobile/issues/16327
This commit gets rid of the app-state check which is buggy,
The app-state becomes `active` after the universal link code has executed always resulting in the redirect not happening.
This commit does the following:
- Moves `get-abbreviated-profile-url` from shell share view into `utils.address` and update its usage.
- Adds `get-shortened-compressed-key` to `utils.address` and update the code using `get-shortened-key` to now use `get-shortened-compressed-key` instead.
- Adds test for newly introduced utils.
It's well known that shadowing core Clojure vars can lead to unexpected bugs. In
fact, it's a common source of bugs in other languages too. In the status-mobile
repository there are, in total, 562 shadowed vars, ~500 are core vars. Excluding
the "old code" we still have 285 offenders.
In status-mobile I've already seen two bugs caused by shadowed vars, both with
the shadowed var "name". But probably other problems happened in the past, and
others will happen in the future if we don't do something about this. This PR is
also my response to my frustration trying to review PRs and checking for
shadowed vars, humans were not meant for that!
In this commit we are enabling ":shadowed-var" to lint certain (not all) core
vars as errors (not warnings). In future PRs we can gradually unshadow more
vars. For the record, name is shadowed 40 times in the new code and 130 in
total, and type is shadowed 93 times in the new code and 124 in total!
What about non-core vars, should we allow shadowing? There are ~70 non-core
shadowed vars. In my opinion, we should also lint and disallow shadowing
non-core vars, since it may cause the same kind of bugs of shadowing core vars.
But this decision can be left for another moment/issue, after we have fixed the
most prominent problem of shadowing core vars.
Which vars are unshadowed in this PR? I fixed 62 errors and unshadowed
cljs.core/iter, cljs.core/time, cljs.core/count, cljs.core/key,
clojure.core/key.
Resources:
- [clj-kondo linter: shadowed-var](https://github.com/clj-kondo/clj-kondo/blob/master/doc/linters.md#shadowed-var)
* Refactor: Remove use of f-component
* Fix documentation drawer styles
* Refactor: move title styles to style ns
* Fix StaticSafeAreaInsets not being defined on component tests
* Fix bottom sheet height on Android
* Makes `divider-label` styles more lenient
* Small refactor to `list-items.channel` component
* Fix styles for `channel-list-component`
- Refactor `channel-list-component`
- Add some missing `:style` keys in `status-im2.contexts.communities.overview.view`
- Fix a warning related to using a `deref` in a `lazy-seq`
* Changes icon keyword namespace from `:main-icons` to `:i`
This commit updates the `bottom-sheet-screen` component (which used `override-theme` from `screen-params` subs) to use the theme from the context provider.
The bottom sheet screen will pick the theme specified in the screen options (to override) as expected. If it's not specified, then it will fall back to the user's theme.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
watchman was upgraded significantly during the last #14944 (4.9.0 (Aug 16, 2017) to 2023.01.30.00 - 6 years between):
status-im/nixpkgs@4e9c02b
Probably causing developers to have "too many files open" issue #16341
This PR is an attempt to fix the issue by downgrading the watchman
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Otherwise if in Nix context we can accidentally use GNU stat which
results in a different output due to different command line flags:
```
[nix-shell:~/status-mobile]$ stat -Lf "%Sg" "/nix/store"
stat: cannot read file system information for '%Sg': No such file or directory
File: "/nix/store"
ID: 10000110000001a Namelen: ? Type: apfs
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 242837545 Free: 199242283 Available: 199242283
Inodes: Total: 7971454780 Free: 7969691320
```
And it should be just owner group name or ID. Which in turn results in:
```
Unknown Nix installtion type!
```
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Android SDK in nixpkg doesn't support `aarch64-darwin`, for details see
https://github.com/status-im/status-mobile/issues/12794
The workaround was to run terminal application with Rosetta or make with `aarch` tool.
This PR overrides system architecture to always be `x86_64` for Android shell and build targets ran by make.
CI is not affected as it runs `nix` directly.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This commit updates the broken link of `Status development` in the `Start and connect the REPL` section of `ide-setup.md`.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
| 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. |
[<img src="https://play.google.com/intl/en_us/badges/images/generic/en-play-badge.png" alt="Get it on Google Play" height="80"/>](https://play.google.com/store/apps/details?id=im.status.ethereum)
[<img src="https://fdroid.gitlab.io/artwork/badge/get-it-on.png" alt="Get it on F-Droid" height="80"/>](https://f-droid.org/packages/im.status.ethereum/)
[<img src="doc/github_badge.png" alt="Get it on Github" height="80"/>](https://github.com/status-im/status-mobile/releases)
Join us in creating a browser, messenger, and gateway to a decentralized world. Status is a free (libre) open source mobile client targeting Android & iOS built entirely on [Ethereum](https://ethereum.org/) technologies. That's right, no middle men and `go-ethereum` running directly on your device.
[Get it on Github](https://github.com/status-im/status-mobile/releases)
Join us in creating a browser, messenger, and gateway to a decentralized world. Status is a free (libre) open source mobile client targeting Android & iOS built entirely on [Ethereum](https://ethereum.org/) technologies. That's right, no middlemen and `go-ethereum` running directly on your device.
[](https://www.youtube.com/watch?v=oDCSEmS9c3o "Getting started with Status")
@@ -12,52 +14,49 @@ Join us in creating a browser, messenger, and gateway to a decentralized world.
We believe in a medium of pure free trade, economies with fair, permission-less access and a world without intermediaries. We want to create policies that can exist between friends or scale globally, we want to communicate securely and be uninhibited by legacy systems.
We want to take responsibility for our data, the way we conduct ourselves privately and promote this way of life to a mass audience.
We want to take responsibility for our data, and the way we conduct ourselves privately and promote this way of life to a mass audience.
We want deep insights into our own economies so we can make informed, data-driven decisions on how to make our lives better. The Ethereum blockchain, Smart Contracts, Swarm and Whisper provides us a path forward.
We want deep insights into our own economies so we can make informed, data-driven decisions on how to make our lives better. The Ethereum blockchain, Smart Contracts, Swarm and Whisper provide us with a path forward.
If this interests you, **help us make Status a reality** - anyone can contribute and we need everyone at any skill level to participate.
## How to Contribute?
Go straight to the [docs](https://status.im/docs) or [join our chat](https://join.status.im/chat/public/status) and choose what interests you:
Go straight to the [docs](doc/) and choose what interests you:
- **Developer** Developers are the heart of software and to keep Status beating
we need all the help we can get! If you're looking to code in ClojureScript or
Golang then Status is the project for you! We use React Native and there is even
some Java/Objective-C too! Want to learn more about it? Start by reading our
[Developer Introduction](https://status.im/developer_tools/) which guides you
[Developer Introduction](doc/starting-guide.md) which guides you
through the technology stack and start browsing [beginner
Status](https://status.im/technical/build_status/), which talks about managing
project dependencies, coding guidelines and testing procedures. The [doc/](doc/)
directory also has valuable information for contributors.
Status](doc/starting-guide.md), which talks about managing
project dependencies, coding guidelines and testing procedures.
Check out our [coding guidelines](doc/new-guidelines.md).
- **Community Management**
Metcalfe's law states that the value of a network is proportional to the square of the number of connected users of the system - without community Status is meaningless. We're looking to create a positive, fun environment to explore new ideas, experiment and grow the Status community. Building a community takes a lot of work but the people you'll meet and longlasting relationships you form will be well worth it, check out our [Mission and Community Principles](https://status.im/about)
Metcalfe's law states that the value of a network is proportional to the square of the number of connected users of the system - without community Status is meaningless. We're looking to create a positive, fun environment to explore new ideas, experiment and grow the Status community. Building a community takes a lot of work but the people you'll meet and the long-lasting relationships you form will be well worth it, check out our [Mission and Community Principles](https://status.im/about)
- **Specification / Documentation**
John Dewey once said "Education is not preparation for life; education is life *itself* ". Developers & Designers need guidance and it all starts from documentation and specifications. Our software is only as good as its documentation, head over to our [docs](https://status.im/docs) and see how you can improve what we have.
John Dewey once said, "Education is not preparation for life; education is life *itself* ". Developers and Designers need guidance and it all starts from documentation and specifications. Our software is only as good as its documentation, check out our [docs](doc/) and see how you can improve what we have.
- **Blog Writing**
Content is King, keeping our blog up to date and informing the community of news helps keep everyone on the same page. [Jump into our chat](https://join.status.im/chat/public/status) and discuss with the team how you can contribute!
Content is King, keeping our blog up to date and informing the community of news helps keep everyone on the same page.
- **Testers**
It's bughunting season! Status is currently under active development and there is sure to be a bunch of learning, [build status from scratch](https://status.im/technical/build_status/) or if an android user check out our [nightly builds](https://status.im/nightly). You can shake your phone to submit bug reports, or start browsing our [Github Issues](https://github.com/status-im/status-mobile/issues). Every bug you find brings Status closer to stable, usable software for everyone to enjoy!
It's bug-hunting season! Status is currently under active development and there is sure to be a bunch of learning, [build status from scratch](doc/starting-guide.md) or if an android user checks out our [nightly builds](https://status.im/nightly). You can shake your phone to submit bug reports, or start browsing our [Github Issues](https://github.com/status-im/status-mobile/issues). Every bug you find brings Status closer to stable, usable software for everyone to enjoy!
- **Security**
Status is a visual interface to make permanent changes on the Blockchain, it handles crypto-tokens that have real value and allows 3rd party code execution. Security is paramount to its success. You are given permission to break Status as hard as you can, as long as you share your findings with the community!
- **Evangelism**
Help us spread the word! Tell a friend *right now*, in fact tell **everyone** - yell from a mountain if you have to, every person counts! If you've got a great story to tell or have some interesting way you've spread the word about Status let us know about it in our [chat](https://join.status.im/chat/public/status)
## Status API
View our [API Docs](https://status.im/developer_tools/status_web_api.html) and learn how to integrate your DApp into Status. You can read more about how to add your DApp to Status [here](https://status.im/developer_tools/add_your_dapp.html).
Help us spread the word! Tell a friend *right now*, in fact, tell **everyone** - yell from a mountain if you have to, every person counts! If you've got a great story to tell or have some interesting way you've spread the word about Status let us know about it in our [chat](https://join.status.im/chat/public/status)
## Give me Binaries!
You can get our Beta builds for both Android and iOS on our [website](https://status.im), through our [nightly builds](https://status.im/nightly/) or by [building it yourself](https://status.im/technical/build_status/).
You can get our Beta builds for both Android and iOS on our [website](https://status.im), through our [nightly builds](https://status.im/nightly/), or by [building it yourself](https://status.im/technical/build_status/).
## Core Contributors
@@ -68,12 +67,8 @@ Without the dedication of these outstanding individuals, Status would not exist.
## Contact us
Feel free to email us at [support@status.im](mailto:support@status.im) or better yet, [join our chat](https://join.status.im/chat/public/status).
Feel free to email us at [support@status.im](mailto:support@status.im).
## License
Licensed under the [Mozilla Public License v2.0](https://github.com/status-im/status-mobile/blob/develop/LICENSE.md)
@@ -23,7 +23,7 @@ setups and runs the test suite once.
setups and runs the test suite and watches for code changes will then retrigger the test suite.
## Writing Tests
New test files will need their namespace added to either the file "src/quo2/core_spec.cljs" or "src/status_im2/core_spec.cljs. These locations may update overtime but it is dependent on the entrypoint in shadow-cljs config discussed below.
New test files will need their namespace added to either the file "src/quo/core_spec.cljs" or "src/status_im2/core_spec.cljs. These locations may update overtime but it is dependent on the entrypoint in shadow-cljs config discussed below.
When building/fixing/refactoring components, it can be annoying to set-up the component for instant visual feedback (i.e. finding it in the UI when fixing/refactoring; finding a place for it when building from scratch). Very often if the location of the screen containing your component nested deeply in the app, you might have to do a lot of repeated navigation, nevermind logging in every time the app reloads (even with fast refresh disabled this happens quite often).
To alleviate this discomfort and make the development cycle more *pleasant*, you can use one of the following options (*_both of which involve the ... REPL ༼ つ ╹ ╹ ༽つ, so make sure you have that set-up with your IDE/editor_*)
#### REPL-ing to a screen
This one is straightforward, just evaluate a navigation dispatch form from anywhere:
> TIP: you can run this from an untracked user namespace `(ns user)`, from which you can experiment or interact with the REPL. This is where I usually keep my development navigation forms.
#### REPL-ing a component
This is also straighforward, but there are some small differences. Just like above, we only have to evaluate a dispatch form, as follows:
```cljs
;; example debugging a quo component, although it could be any other component e.g. from the `status-im2` ns.
When evaluated, a full-screen bottom sheet will appear with your component inside. You can make changes to the props or the component internals and re-evaluate the changed forms, after which the component will be re-mounted without running a reload (unless you save the file). Other times it's quicker to just hit save and the component will be reloaded as usual (except for the props you evaluated, which have to be re-evaluated when changed).
> TIP: You can have multiple versions of the component as separate comments to check for the component variations
> TIP: You can leave `comment` blocks at the end of component files (other than quo, since can be previewed in other ways) with usages of components, which other developers can use for visualisation/testing.
There was a generally dissatisfaction with our PR flow process from multiple stakeholders, including devs, QA and design. These largely centered around size, speed of integration and quality of PRs.
For more details, please see pain points in the meeting notes held end of February here: https://notes.status.im/C5pj8g7gQOu9Wo8PtDZsMw?edit# as well as the preceeding Discuss thread: https://discuss.status.im/t/better-pull-requests-process/1044
For more details, please see pain points in the meeting notes held end of February here: https://notes.status.im/C5pj8g7gQOu9Wo8PtDZsMw?edit# as well as the preceding Discuss thread: https://discuss.status.im/t/better-pull-requests-process/1044
Also see conversations in Core Dev Call #12 and #13: https://github.com/status-im/pm/
@@ -18,7 +18,7 @@ The whitepaper also proposes that the deposit is only forfeited to the recipient
Considering:
- the absence of efficient ways to perform anonymous transactions (zk-snarks could be used in the future for that)
- the impossibility to prove that a recipient has made an actual reply and not some kind of automated reply (captcha solution was proposed, but wouldn't be pratical until we can use a solution such as swarm feeds that allow users to make free updates to their captcha without on-chain transactions)
- the impossibility to prove that a recipient has made an actual reply and not some kind of automated reply (captcha solution was proposed, but wouldn't be practical until we can use a solution such as swarm feeds that allow users to make free updates to their captcha without on-chain transactions)
- the limited time to develop the feature
We opted for a solution that:
@@ -28,8 +28,8 @@ We opted for a solution that:
## Manifests
Since TtT related informations aren't stored on chain, they need to be stored somewhere else.
For the first iteration of TtT we opted for IPFS, which is already used accross the app for other forms of content, through Infura IPFS gateway.
Since TtT related information aren't stored on chain, they need to be stored somewhere else.
For the first iteration of TtT we opted for IPFS, which is already used across the app for other forms of content, through Infura IPFS gateway.
On IPFS we store what we call a ttt manifest, which is a json file with the following format:
Sometimes, we can't reproduce crash with local dev build, probably because your built version differs from the one QA team used.
The QA team mostly used the PR build version. In this guide we will try to make a build as close as possible to the PR build for iOS.
You may notice various configuration files starting with .env (such as .env, .env.e2e, .env.jenkins) in the project.
The usage of these files and environment variables injected at build time on CI will not be covered in this guide.
This guide covers how to configure Xcode to capture a crash stack trace with a physical iOS device. This allows debugging crashes by inspecting the stack trace.
I will use [issue #17255](https://github.com/status-im/status-mobile/issues/17255) as an example to reproduce and analyze a crash.
## Prerequisites
- A physical ios device (simulator is not considered in this doc)
- Xcode installed
## Steps
1. Prepare Status Mobile
1. Open Terminal, cd to project root
2. Run `make run-clojure` in one tab
3. Run `make run-metro` in a second tab
4. Run `make pod-install` in a third tab
2. Configure Xcode Project
1. Open Xcode
2. Open a project or file, navigate to folder `path_to_root_directory_of_status_mobile/ios`
3. Set Scheme `StatusImPR` as current scheme 
7. Set automatically manage signing 
3. Update Code
1. Edit `src/status_im2/setup/dev.cljs`, comment out lines 47-52 
2. Edit `shadow-cljs.edn`, comment out `re-frisk-remote.preload`, otherwise it will try to connect `localhost:4567` on physical device which could slow down performance 
4. Reproduce Crash And Analyze
1. Choose your physical ios device as target device and Run
2. Follow reproduce steps from [issue #17255](https://github.com/status-im/status-mobile/issues/17255) mentioned and xcode will halt at crash point 
3. Inspect stack trace to identify root cause. From the stack trace, we can locate the crash happened in `api/geth_backend.go:1048`(createTempDBFile) clearly! 
## Links
- [changes](https://github.com/status-im/status-mobile/commit/4306d419de15e737e8ded3a749cc5e8d6a06e627) to source code
@@ -19,7 +19,7 @@ For now we support e2e for Android only.
## What's happening when any e2e job is running
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, amout is changing)** against each nightly build (if the nightly builds job succeeded). Results of the test run are saved in 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).
In that case we save results in TestRail as well and push a comment with test results in a respective PR.
@@ -49,8 +49,8 @@ Params to specify:
- apk: [url_to_apk_build_here]
- pr_id: pull request number (e.g. 1234)
- branch: branch name from which the test are taken (in most of cases `develop`)
- keyword expression: tests by area (let's say `ens` or `chat`, thay can be combined`ens or chat or send_tx`. All keywords can be found in testrail, ping Chu for details)
- test_marks: tests by priorities (by default: `critical or high or medium`, which corresponds the whole suite; to lauch the same suite as in PRs, use `critical or high`)
- keyword expression: tests by area (let's say `ens` or `chat`, they can be combined`ens or chat or send_tx`. All keywords can be found in testrail, ping Chu for details)
- 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.
@@ -64,7 +64,7 @@ tests (otherwise some PRs could wait their turn of the scheduled Jenkins job til
## Analysing test results (and why test fails to pass)
After automated test run finished test results could be found in GH comment (if the test suite ran agaist PR) and TestRail. There are two states of the test: Passed and Failed. Test failure happens when certain condition of test step has not met or automated test can not proceed execution because it can not find the respective element on screen it expects should be there.
After automated test run finished test results could be found in GH comment (if the test suite ran against PR) and TestRail. There are two states of the test: Passed and Failed. Test failure happens when certain condition of test step has not met or automated test can not proceed execution because it can not find the respective element on screen it expects should be there.
You should now see an dialog with the following message:
You should now see a dialog with the following message:
```shell
Connecting to remote nREPL server...
@@ -160,24 +161,24 @@ Following the above should give you the below result:
For additional details on issues you may face when setting up REPL with Cursive [see this document](https://notes.status.im/9Gr7kqF8SzC_SmYK0eB7uQ?view#Connecting-Cursive--IntelliJ-IDEA-to-REPL-Problems)
## Using Calva
## Visual Studio Code
For VS Code users.
### Set up the REPL
0. Install Calva.
1. Install Calva extension.
2. Open the `status-mobile` folder.
3. Start [Status development](starting-guide.md#development) (Starting the
`run-clojure` and `run-metro` jobs in split view in the VS Code integrated
terminal works great).
4. Run the VS Code command: **Calva: Connect to a running REPL Server in the
project**.
- Select the project type `shadow-cljs`.
- Accept the suggested connection `host:port`.
- Select to connect to the `:mobile` build.
### Start and connect the REPL
1. Open the `status-mobile` folder.
1. Start [Status development](STARTING_GUIDE.md#development) (Starting the `run-clojure` and `run-metro` jobs in split view in the VS Code integrated terminal works great.)
1. Run the VS Code command: **Calva: Connect to a running REPL Server in the project**
1. Select the project type `shadow-cljs`
1. Accept the suggested connection `host:port`
1. Select to connect to the `:mobile` build
### Use the REPL
Open any `.cljs` file in the project and evaluate forms in it. See https://calva.io/try-first/ for some starter tips and links. Confirm that your REPL is connected to the app by evaluating:
Open any `.cljs` file in the project and evaluate forms in it. See
https://calva.io/try-first/ for some starter tips and links. Confirm that your
REPL is connected to the app by evaluating:
```clojure
(js/alert"Hello from Status App!")
@@ -185,9 +186,35 @@ Open any `.cljs` file in the project and evaluate forms in it. See https://calva
🎉 Tada! You are ready to use the REPL to improve Status.im! 🎉
Please consider bookmarking [calva.io](https://calva.io/) for quick access to the Calva documentation.
Consider bookmarking [calva.io](https://calva.io/) for quick access to the Calva
documentation.
## Using Emacs/Cider
### Auto-format files on save
We format Clojure code with [zprint](https://github.com/kkinnear/zprint). We
recommend configuring VSCode to auto-format Clojure files on every save,
otherwise you'll need to constantly rely on the much slower `make lint-fix`
command.
1. Create a file `~/.zprintrc` and enable the `:search-config?` option. This is
necessary so the VSCode extension finds the project's `.zprintrc`.
```bash
echo"{:search-config? true}" > ~/.zprintrc
```
2. Install the extension
[vscode-clj-zprint](https://github.com/rflagreca/vscode-clj-zprint). By the
way, did you know this extension is written in ClojureScript?
3. Copy the recommended settings from our repository in
[.vscode/settings.example.json](/.vscode/settings.example.json) and merge it
with your workspace settings in `.vscode/settings.json`.
The extension `vscode-clj-zprint` is only available for VSCode. If you are using
VSCodium, you'll need to build the `vsix` (extension) yourself (it's easy, only
`yarn` and `vsce` are required).
## Using Emacs with CIDER
1. Install Emacs/Cider/etc. (there is a lot of variability in how to manage things in emacs, so please google for help with this)
2. Add a local ~/.shadow-cljs/config.edn file like below (corresponding to the version numbers of the packages you are using):
@@ -198,5 +225,3 @@ Please consider bookmarking [calva.io](https://calva.io/) for quick access to th
2) Add some reviewers to the PR and wait for feedback
3) Address feedback
4) Make sure builds and tests are green (run `make test` locally, `make lint-fix` to fix any indentation issue and `make lint`)
5) Once the PR has been reviewed by the dev team you can run e2e tests on it by going to https://github.com/status-im/status-mobile/projects/7 and move the pr under the column E2E tests. This will trigger tests.
5) Once the PR has been reviewed by the dev team, run e2e tests on it by going to https://github.com/status-im/status-mobile/projects/7 and move the pr under the column E2E tests. This will trigger tests.**Running E2E tests is required for all PRs.**
1) Read our [PR Review Policy](pr-review-policy.md) for more details on our approach to PR reviews.
2) Learn more about our [Pipeline for QA](pipeline_process.md) process
6) Once e2e tests have run, they will report the result on the PR, if it's less than 100%, ask QA to take a look to make sure everything is in order (some might fail for legitimate reasons)
7) Ask QA for manual testing if the PR requires it
7) Ask QA for manual testing if the PR requires it (more details [here](pipeline_process.md))
8) Once it has been tested successfully, squash everything into one commit. rebase and merge. The commands we use:
```
git checkout develop
@@ -40,7 +41,9 @@ In practice, this means that sometimes they need to be merged in lockstep.
git push origin vx.y.z
```
5) Update status-mobile with the new status-go version, using the new tag `scripts/update-status-go.sh "vx.y.z"`
6) In status-mobile, push, rebase against `develop` and merge it 🚀
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.
7) In status-mobile, push, rebase against `develop` and merge it 🚀
important note : make sure your status-go PRs get a tested-ok by QA before merging them in.
@@ -107,7 +157,7 @@ the source file. For a real example, see
### Always add styles inside the `:style` key
Although when compiling ReactNative for mobile some components are able work with
Although when compiling ReactNative for mobile some components are able work with
their styles in the top-level of the properties map, prefer to add them inside the
`:style` key in order to separate styles from properties:
@@ -126,12 +176,11 @@ their styles in the top-level of the properties map, prefer to add them inside t
:on-press#(js/alert"Hi!")
:title"Button"}]
;; better
;; better
;; (define them in a style ns & place them inside `:style` key)
[rn/button{:style(style/button)
:on-press#(js/alert"Hi!")
:title"Button"}
]
:title"Button"}]
```
Also its fine to keep one liner styles in view
@@ -143,7 +192,7 @@ Also its fine to keep one liner styles in view
### Don't define properties in styles ns
Properties must be set on view level
Properties must be set on view level
```clojure
;; bad
@@ -163,10 +212,8 @@ Properties must be set on view level
:bottom0}
```
### Apply animated styles in the style file
```clojure
;; bad
(defn circle
@@ -199,24 +246,37 @@ Joshua Comeau.
[rn/view{:style{:padding-horizontal20}}]
```
### Don't prepend booleans with is-
### Use a question mark to convey the value is a boolean
It is a common practice in JavaScript and other languages to prepend boolean variable names with `is-*`.
In ClojureScript it is common practice to suffix boolean variable names with a `?`.
There is no need for both of these and so it is preferable to stick with the latter.
The Clojure Style Guide suggests using a question mark only in [predicate
functions](https://guide.clojure.style/#naming-predicates), but nothing is
mentioned about other symbols and keywords. We prefer to extend the convention
to all boolean references.
```clojure
;; bad
(let [is-open?true]...)
(def flag-is-enabledfalse)
;; good
(let [open?true]...)
(def flag-enabled?false)
```
And for keywords too:
```clojure
;; bad
[some-component{:logged-intrue}]
;; good
[some-component{:logged-in?true}]
```
### Styles def vs defn
Always use `def` over `defn`, unless the style relies on dynamic values, such as
deref'ed atoms.
Always use `def` over `defn` if there are no dynamic values. This helps cut the
cost of function calls.
```clojure
;; bad
@@ -240,15 +300,18 @@ deref'ed atoms.
### Custom Colors
The Status designs have a lot of customization of user and group colors with components and pages. For consistency it is best to use `customization-color` as the prop key on pages and components. This will help easily identify what pages and components in the application are using customized colors.
The Status designs have a lot of customization of user and group colors. For
consistency it is best to use `customization-color` as the prop key on pages and
components. This will help easily identify what pages and components in the
Please check the [Clojure Style](https://guide.clojure.style/#deprecated) documentation
To reduce visual clutter from deprecated methods in your text editor, consult this [example](https://rider-support.jetbrains.com/hc/en-us/community/posts/4419728641810-How-to-disable-the-the-strike-thru-for-deprecated-methods-in-Javascript-#:~:text=Try%20disabling%20%22Preferences%20%7C%20Editor%20%7C,It%20works%20for%20me). The approach can be adapted for settings in VSCode, Emacs, VIM, and others.
### Test structure
[Unit tests](#glossary) should be created alongside their respective source
@@ -736,9 +827,9 @@ Clojure (JVM) codebases which mirror the sources in a top-level test directory.
└── models_test.cljs
```
Component tests should be created in a separate directory `__tests__`, colocated
with the source. When the entire component implementation is isolated under a
single directory, create a test file named `component_spec.cljs` instead.
Component tests should be created in the same directory as the source component,
If 3rd party library has an issue and fix is not yet released (or we can't switch to a new release), we use forks. Fix should be commited to the fork, tagged and referenced from package.json.
If 3rd party library has an issue and fix is not yet released (or we can't switch to a new release), we use forks. Fix should be committed to the fork, tagged and referenced from package.json.
[Pipeline for QA](https://github.com/status-im/status-mobile/projects/7) is a project board for developers and testers used to track the status of a pull request, get reviews and manual testing, _and run autotests_ (_temporary disabled_).
[Pipeline for QA](https://github.com/status-im/status-mobile/projects/7) is a project board for developers and testers used to track the status of a pull request, get reviews and manual testing, and run autotests.
The generally accepted recommendations for its use are described below:
@@ -30,7 +30,7 @@ Ready for testing PR should meet the following criteria:
3. Wait for the review.
4. Make sure that after review and before requesting manual QA your PR is rebased to current develop.
5. Once the PR has been approved by reviewer(s) - label `request-manual-qa` should be applied to the PR
6. Move PR to the E2E column when it is ready for testing. That will also trigger e2e tests run. QAs are monitoring PRs from E2E column and take it into test.
6. Move PR 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.
After that - PR will be taken into manual testing by the QA team.
@@ -41,38 +41,50 @@ After that - PR will be taken into manual testing by the QA team.
- 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, tester can add the ```Tested - Issues``` label and drag the card to the ```CONTRIBUTOR``` column. These two actions are optional.
- When manual testing of PR is fully completed and all issues are fixed, QA adds the ```Tested - OK``` label and drags the card to the ```MERGE``` column, after which developer merges PR into develop.
If manual testing was not carried out, developer drags PR to the ```MERGE``` column themselves.
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 manual testing of the PR is fully completed and all the issues are fixed, the QA adds the ```Tested - OK``` label and drags the card to the ```Design review``` column (the cases when design review is necessary are described below).
- If design review is not required, the QA drags the PR to the ```MERGE``` column. After that the developer merges PR into develop.
- If design review has been done, the designer (```@Francesca-G```) drags the PR to the ```MERGE``` column.
After that the developer merges PR into develop.
- If manual testing/design review was not carried out, the developer drags PR to the ```MERGE``` column themselves.
### Design review
_**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.
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).
There are three possible scenarios when the design review is completed:
1. **Approved by design** > the PR is moved to the ```MERGE``` column by Francesca
2. **Some changes requested, but can be fixed as followups** > need to be negotiated with Francesca > Francesca moves PR to the ```MERGE``` column and adds the ```Follow-up required``` label > follow-ups should be added **by the dev** right after the PR is merged
3. **Some changes requested, they should be fixed before merge** > Francesca reviews the PR again after the fixes and moves PR to the ```MERGE``` column from ```Design review```
---
**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.
---
**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.
#### 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`.
In the first case most often this happens due to conflicting files in PR.
In the second case - after fixing of all found issues, the developer should ping the QA in the PR comments for retesting.
#### Why is my PR in `To Rebase` column?
PR is moved to the "To Rebase" column in two cases:
- automatically by github bot if PR branch has conflicts that should be resolved
- manually (by QAs) if PR branch is out-of-date with the base branch and requires rebasing to the latest develop
If PR appeared in the "To Rebase" column dev who is working on the PR should resolve conflicts/rebase branch to the latest develop. After resolving conflicts/rebasing PR should be moved by developer to the right column depending on PR work progress.
## Merging a PR
**Merge conditions:**
1. Required number of reviews received
2. All commits are squashed into one.
3. No conflicting files in PR
4. No issues from lint
5. Pay attention to automation checks (some of them are not blockers, best to check before merge anyway)
2. E2E results are received and reviewed
3. All commits are squashed into one.
4. No conflicting files in PR
5. No issues from lint
6. Pay attention to automation checks (some of them are not blockers, best to check before merge anyway)
The Status Mobile team aims to align the design implementation perfectly according to a given screens respective Figma design spec.
Currently, the Figma Designs match up with both "iPhone 11 Pro" and "iPhone 13" screen size.
The Dimension reference for iPhone 11 Pro is 375 x 812 (width x height) and for iPhone 13 is 390 x 844.
To test your implementation is correct you can take the following steps
- Open a new Figma file so that you have write privileges.
- Copy in the component or screen from the Figma file.
- Using the "iPhone 11 Pro" or the "iPhone 13" simulator (it is the default now) you take a screenshot of your component and paste it into your Figma file.
- To get the right size, set your screenshot to width according to your simulator:
- for iPhone 13 set 390
- for iPhone 11 Pro set 375
- Lower the opacity so you can see it sitting on top of the Figma mock ups.
The optimal way of pushing to GitHubis using SSH instead of user/pass auth.
The optimal way of pushing to GitHubis using SSH instead of user/pass auth.
It's recommented that you [add your public SSH key to your GitHub account](https://help.github.com/en/github/authenticating-to-github/adding-a-new-ssh-key-to-your-github-account).
It's recommended that you [add your public SSH key to your GitHub account](https://help.github.com/en/github/authenticating-to-github/adding-a-new-ssh-key-to-your-github-account).
shellScript = "diff \"${PODS_PODFILE_DIR_PATH}/Podfile.lock\" \"${PODS_ROOT}/Manifest.lock\" > /dev/null\nif [ $? != 0 ] ; then\n # print error to STDERR\n echo \"error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.\" >&2\n exit 1\nfi\n# This output is used by Xcode 'outputs' to avoid re-running this script phase.\necho \"SUCCESS\" > \"${SCRIPT_OUTPUT_FILE_0}\"\n";
shellScript = "diff \"${PODS_PODFILE_DIR_PATH}/Podfile.lock\" \"${PODS_ROOT}/Manifest.lock\" > /dev/null\nif [ $? != 0 ] ; then\n # print error to STDERR\n echo \"error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.\" >&2\n exit 1\nfi\n# This output is used by Xcode 'outputs' to avoid re-running this script phase.\necho \"SUCCESS\" > \"${SCRIPT_OUTPUT_FILE_0}\"\n";
shellScript = "diff \"${PODS_PODFILE_DIR_PATH}/Podfile.lock\" \"${PODS_ROOT}/Manifest.lock\" > /dev/null\nif [ $? != 0 ] ; then\n # print error to STDERR\n echo \"error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.\" >&2\n exit 1\nfi\n# This output is used by Xcode 'outputs' to avoid re-running this script phase.\necho \"SUCCESS\" > \"${SCRIPT_OUTPUT_FILE_0}\"\n";
shellScript = "diff \"${PODS_PODFILE_DIR_PATH}/Podfile.lock\" \"${PODS_ROOT}/Manifest.lock\" > /dev/null\nif [ $? != 0 ] ; then\n # print error to STDERR\n echo \"error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.\" >&2\n exit 1\nfi\n# This output is used by Xcode 'outputs' to avoid re-running this script phase.\necho \"SUCCESS\" > \"${SCRIPT_OUTPUT_FILE_0}\"\n";
@@ -12,12 +12,13 @@ By using the following command:
```sh
shadow-cljs classpath --force-spawn
```
We both download the necessary JARs and POMs into `~/.m2` folder, but also get the classpath printed into standard output.
We download the necessary JARs into `~/.m2` folder, but also get the classpath printed into standard output.
We skip POM files since they are not necessary, and add edge cases we don't want to handle.
We then use the classpath in combination with contents of `~/.m2` folder to generate the following files:
*`deps.list` - List of JARs relative to the `~/.m2` cache folder.
*`deps.json` - Full list of JARs and POMs including their SHAs.
*`deps.json` - Full list of JARs including their SHAs.
The `deps.list` file is just intermediate and for debugging purposes.
The `deps.json` is loaded by the derivation in [`default.nix`](./default.nix) and used to produce a derivation that contains all the necessary dependencies:
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Andrea Maria Piana
jakub
