Skip to content

fix: switch to RN native ActivityIndicator#2000

Merged
cimigree merged 11 commits into
developfrom
fix/rn-activity-indicator
Jul 24, 2026
Merged

fix: switch to RN native ActivityIndicator#2000
cimigree merged 11 commits into
developfrom
fix/rn-activity-indicator

Conversation

@gmaclennan

Copy link
Copy Markdown
Member

Replaces the unmaintained react-native-indicators spinner with React Native's built-in ActivityIndicator.

react-native-indicators is unmaintained and incompatible with the New Architecture — it was causing rendering issues and pinning CPU to 100%. A new LoadingIndicator shared component wraps ActivityIndicator and all call sites switch to it.

Note: this is a visual change. The spinner is now the platform-native Material Design spinner on Android.

Split out of #1994 to reduce that PR's review surface; #1994 is stacked on top of this branch.

react-native-indicators spinner is unmaintained and incompatible with the new architecture (it was causing rendering issues and running CPU to 100%)

Note: this is a visual change: the spinner is now the android platform-native material design spinner
* develop:
  New Crowdin updates (#1990)
  chore: add Saamaka (#1997)
  chore: bump dep (#1995)
@awana-lockfile-bot

awana-lockfile-bot Bot commented Jun 30, 2026

Copy link
Copy Markdown

package-lock.json changes

Click to toggle table visibility
Name Status Previous Current
@emnapi/core UPDATED 1.4.3 1.11.2
@emnapi/runtime UPDATED 1.4.3 1.11.2
@emnapi/wasi-threads UPDATED 1.0.2 1.2.2
@napi-rs/wasm-runtime UPDATED 0.2.11 0.2.12
@tybys/wasm-util UPDATED 0.9.0 0.10.3
@types/react-native-indicators REMOVED 0.16.6 -
react-native-indicators REMOVED 0.17.0 -

@gmaclennan
gmaclennan force-pushed the fix/rn-activity-indicator branch from 08b6d3e to 04d3a3f Compare June 30, 2026 09:40
@ErikSin
ErikSin requested a review from cimigree July 2, 2026 17:48
@cimigree

Copy link
Copy Markdown
Contributor

Do you think design should weigh on in the new look?
The color? The size? The new behavior?

screen-20260716-044238-1784212948699.mp4

@gmaclennan

Copy link
Copy Markdown
Member Author

Do you think design should weigh on in the new look? The color? The size? The new behavior?

Yes, good idea, can you consult? Is the behavior different? I think color and size we can tweak immediately. The work of fixing the old spinner style, or making our own spinner to match the style of the old one, is too much work short-term unless we feel really strongly about having our own spinner.

@cimigree

Copy link
Copy Markdown
Contributor

Do you think design should weigh on in the new look? The color? The size? The new behavior?

Yes, good idea, can you consult? Is the behavior different? I think color and size we can tweak immediately. The work of fixing the old spinner style, or making our own spinner to match the style of the old one, is too much work short-term unless we feel really strongly about having our own spinner.

I asked and am waiting on a response as of July 21.

@cimigree cimigree left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ErikSin or @gmaclennan do you want to look at the changes I made? I set the default color to comapeo-blue as Aldo suggested, fixed some missing usages of the new Loading Indicator and merged with develop. Earlier I had gone through and looked at all of the places it is used and they all seemed to do the trick as far as I could tell. I just feel a little weird approving code that I wrote? But it is only a bit at the end.

@ErikSin

ErikSin commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

@cimigree Do you think it is a good idea to maintain a number size for android, and then a different prop for iOS? If so, then i think we need to create the component that automatically maintains that, so we don't have to do that for each instance of it.

IMO i think we should try to use small and large for android as well, so we don't have to maintain it. But I think you have more context than i do.

@cimigree

Copy link
Copy Markdown
Contributor

@cimigree Do you think it is a good idea to maintain a number size for android, and then a different prop for iOS? If so, then i think we need to create the component that automatically maintains that, so we don't have to do that for each instance of it.

IMO i think we should try to use small and large for android as well, so we don't have to maintain it. But I think you have more context than i do.

I agree. I think small and large look fine to me and if and until design has a strong opinion otherwise, than I would rather just have one look/ one set of code for ios and android. There will be enough places where we need to have different code, so here this seems to work to share it.

@ErikSin

ErikSin commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

I agree. I think small and large look fine to me and if and until design has a strong opinion otherwise, than I would rather just have one look/ one set of code for ios and android. There will be enough places where we need to have different code, so here this seems to work to share it.

Oh I see that is already happening. Were passing a size, but then forcing that into a "small" and "large". I didn't fully understand the code.

I think we should just get rid of that and just have the prop "Large" or "small", and make that part of this refactor. It will just make it more consistent, and less confusing instead of using a number that is then turned into an enum

@cimigree

Copy link
Copy Markdown
Contributor

Oh I see that is already happening. Were passing a size, but then forcing that into a "small" and "large". I didn't fully understand the code.

I think we should just get rid of that and just have the prop "Large" or "small", and make that part of this refactor. It will just make it more consistent, and less confusing instead of using a number that is then turned into an enum

fae79fb

@cimigree
cimigree requested a review from ErikSin July 23, 2026 20:10

@ErikSin ErikSin left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have one blocking comment about the e2e test animations. It would simplify the code in many place, and make e2e overall faster if we just turned off the animations at the component level instead of the consuming level

// spinner, animated by the OS view itself — no JS, Animated, or reanimated work
// per frame. It replaces react-native-indicators, which is unmaintained and
// whose radial-transform layout collapses to a line under the New Architecture.
export const LoadingIndicator = ({

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a jsdoc comment explicitly saying that defaults to large and defaults to COMAPEO_BLUE?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should rename this to something that more obviously separates this from the LoadingIndicator.

Perhaps FullScreenCenteredLoader or something along those lines

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

}: {
color?: string;
size?: number;
size?: 'small' | 'large';

@ErikSin ErikSin Jul 23, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i dont think we should allow a size prop here. the one place where it is small is the BackgroundMapsScreen and it is almost hard to see. I think this should always be Large, and we should not even allow any sizing prop

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

size = 'large',
color = COMAPEO_BLUE,
...props
}: Props) => <ActivityIndicator size={size} color={color} {...props} />;

@ErikSin ErikSin Jul 23, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of the components using this are turning off the animation for the e2e tests. Should we just not turn of ALL the ActivityIndicators in e2e, instead of doing it for each disparate component? In otherwords, just control that prop directly in this. That would simplify the code and make the e2e faster all around, no?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cimigree
cimigree requested a review from ErikSin July 23, 2026 21:19

@ErikSin ErikSin left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! thanks

@cimigree
cimigree merged commit 9ca4918 into develop Jul 24, 2026
9 checks passed
@cimigree
cimigree deleted the fix/rn-activity-indicator branch July 24, 2026 02:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants