[native] [25/40] RN 0.70: Update to react-native-background-upload@6.6.0
ClosedPublic
Actions

Authored by ashoat on Dec 18 2022, 7:44 PM.

Details

Reviewers

tomek
bartek

Commits

rCOMM462f30486e9b: [native] [25/40] RN 0.70: Update to react-native-background-upload@6.6.0

Summary

I was seeing Android build errors with this package, which were resolved after updating.

Test Plan

I reviewed the Release Notes and found no breaking changes
Tested along with whole stack: test plan (includes testing media upload, which uses this package)

Depends on D5918

Diff Detail

Repository

rCOMM Comm

Lint

No Lint Coverage

Unit

No Test Coverage

Event Timeline

ashoat created this revision.Dec 18 2022, 7:44 PM

Herald added a subscriber: atul. · View Herald TranscriptDec 18 2022, 7:44 PM

Harbormaster returned this revision to the author for changes because remote builds failed.Dec 18 2022, 7:45 PM

Harbormaster failed remote builds in B14248: Diff 19487!

ashoat added a child revision: D5921: [native] [26/40] RN 0.70: Update to react-native-screens@3.18.2.Dec 18 2022, 7:50 PM

ashoat retitled this revision from [native] [24/40] RN 0.70: Update to react-native-background-upload@6.6.0 to [native] [25/40] RN 0.70: Update to react-native-background-upload@6.6.0.Dec 18 2022, 8:05 PM

Rebase

Harbormaster returned this revision to the author for changes because remote builds failed.Dec 18 2022, 8:30 PM

Harbormaster failed remote builds in B14270: Diff 19509!

Rebase

Harbormaster returned this revision to the author for changes because remote builds failed.Dec 18 2022, 9:04 PM

Harbormaster failed remote builds in B14297: Diff 19536!

Rebase

Harbormaster failed remote builds in B14349: Diff 19598!Dec 19 2022, 8:42 AM

Harbormaster returned this revision to the author for changes because remote builds failed.Dec 19 2022, 9:10 AM

Harbormaster failed remote builds in B14382: Diff 19631!

Please ignore CI until the end of the stack

Rebase

Harbormaster failed remote builds in B14449: Diff 19704!Dec 19 2022, 12:42 PM

bartek accepted this revision.Dec 20 2022, 3:20 AM

This revision is now accepted and ready to land.Dec 20 2022, 3:20 AM

tomek accepted this revision.Dec 20 2022, 5:19 AM

Rebase

Harbormaster failed remote builds in B14505: Diff 19762!Dec 20 2022, 6:32 AM

Rebase

Harbormaster failed remote builds in B14564: Diff 19824!Dec 20 2022, 11:23 AM

This revision was landed with ongoing or failed builds.Dec 20 2022, 12:01 PM

Closed by commit rCOMM462f30486e9b: [native] [25/40] RN 0.70: Update to react-native-background-upload@6.6.0 (authored by ashoat). · Explain Why

This revision was automatically updated to reflect the committed changes.

ashoat added a commit: rCOMM462f30486e9b: [native] [25/40] RN 0.70: Update to react-native-background-upload@6.6.0.

Revision Contents
Changeset List

Path

Size

native/

ios/

Podfile.lock

4 lines

package.json

2 lines

yarn.lock

8 lines

Diff 19824

View Options

native/ios/Podfile.lock

This file was added.

				// @flow

				import * as React from 'react';

				import { type SetState } from 'lib/types/hook-types';
				import { type RelationshipButton } from 'lib/types/relationship-types';
				import { type ThreadInfo } from 'lib/types/thread-types';
				import type { UserInfo } from 'lib/types/user-types';

				import ThreadSettingsRelationshipButton from './thread-settings-relationship-button.react';
				import css from './thread-settings-relationship-tab.css';

				type Props = {
				+threadSettingsOperationInProgress: boolean,
				+threadInfo: ThreadInfo,
				tomekUnsubmitted Not Done Inline Actions These props aren't used. Shouldn't this give a warning? tomek: These props aren't used. Shouldn't this give a warning?
				jacekAuthorUnsubmitted Done Inline Actions Interesting. I thought flow should indicate warning for such variables. jacek: Interesting. I thought flow should indicate warning for such variables.
				ashoatUnsubmitted Not Done Inline Actions There can be a good reason for having a prop that you never use: to force the component to rerender. For instance, we do something similar here ashoat: There can be a good reason for having a prop that you never use: to force the component to…
				+setErrorMessage: SetState<string>,
				+relationshipButtons: $ReadOnlyArray<RelationshipButton>,
				+otherUserInfo: UserInfo,
				};

				function ThreadSettingsRelationshipTab(props: Props): React.Node {
				const { relationshipButtons, otherUserInfo, setErrorMessage } = props;
				const buttons = React.useMemo(() => {
				return relationshipButtons.map(action => {
				return (
				<ThreadSettingsRelationshipButton
				key={action}
				relationshipButton={action}
				otherUserInfo={otherUserInfo}
				setErrorMessage={setErrorMessage}
				tomekUnsubmitted Not Done Inline Actions In `ThreadSettingsRelationshipButton` `setErrorMessage` is `string => void` but here we use `SetState<string>`. Is flow ok with that? Is there a good reason for having different types? tomek: In `ThreadSettingsRelationshipButton` `setErrorMessage` is `string => void` but here we use…
				jacekAuthorUnsubmitted Done Inline Actions Flow is ok here. I'll replace the type in `...Button` with `SetState<string>` jacek: Flow is ok here. I'll replace the type in `...Button` with `SetState<string>`
				/>
				);
				});
				}, [otherUserInfo, relationshipButtons, setErrorMessage]);
				return <div className={css.container}>{buttons}</div>;
				}

				export default ThreadSettingsRelationshipTab;

View Options

native/package.json

This file was added.

				// @flow

				import * as React from 'react';

				import { type SetState } from 'lib/types/hook-types';
				import { type RelationshipButton } from 'lib/types/relationship-types';
				import { type ThreadInfo } from 'lib/types/thread-types';
				import type { UserInfo } from 'lib/types/user-types';

				import ThreadSettingsRelationshipButton from './thread-settings-relationship-button.react';
				import css from './thread-settings-relationship-tab.css';

				type Props = {
				+threadSettingsOperationInProgress: boolean,
				+threadInfo: ThreadInfo,
				tomekUnsubmitted Not Done Inline Actions These props aren't used. Shouldn't this give a warning? tomek: These props aren't used. Shouldn't this give a warning?
				jacekAuthorUnsubmitted Done Inline Actions Interesting. I thought flow should indicate warning for such variables. jacek: Interesting. I thought flow should indicate warning for such variables.
				ashoatUnsubmitted Not Done Inline Actions There can be a good reason for having a prop that you never use: to force the component to rerender. For instance, we do something similar here ashoat: There can be a good reason for having a prop that you never use: to force the component to…
				+setErrorMessage: SetState<string>,
				+relationshipButtons: $ReadOnlyArray<RelationshipButton>,
				+otherUserInfo: UserInfo,
				};

				function ThreadSettingsRelationshipTab(props: Props): React.Node {
				const { relationshipButtons, otherUserInfo, setErrorMessage } = props;
				const buttons = React.useMemo(() => {
				return relationshipButtons.map(action => {
				return (
				<ThreadSettingsRelationshipButton
				key={action}
				relationshipButton={action}
				otherUserInfo={otherUserInfo}
				setErrorMessage={setErrorMessage}
				tomekUnsubmitted Not Done Inline Actions In `ThreadSettingsRelationshipButton` `setErrorMessage` is `string => void` but here we use `SetState<string>`. Is flow ok with that? Is there a good reason for having different types? tomek: In `ThreadSettingsRelationshipButton` `setErrorMessage` is `string => void` but here we use…
				jacekAuthorUnsubmitted Done Inline Actions Flow is ok here. I'll replace the type in `...Button` with `SetState<string>` jacek: Flow is ok here. I'll replace the type in `...Button` with `SetState<string>`
				/>
				);
				});
				}, [otherUserInfo, relationshipButtons, setErrorMessage]);
				return <div className={css.container}>{buttons}</div>;
				}

				export default ThreadSettingsRelationshipTab;

View Options

yarn.lock

This file was added.

				// @flow

				import * as React from 'react';

				import { type SetState } from 'lib/types/hook-types';
				import { type RelationshipButton } from 'lib/types/relationship-types';
				import { type ThreadInfo } from 'lib/types/thread-types';
				import type { UserInfo } from 'lib/types/user-types';

				import ThreadSettingsRelationshipButton from './thread-settings-relationship-button.react';
				import css from './thread-settings-relationship-tab.css';

				type Props = {
				+threadSettingsOperationInProgress: boolean,
				+threadInfo: ThreadInfo,
				tomekUnsubmitted Not Done Inline Actions These props aren't used. Shouldn't this give a warning? tomek: These props aren't used. Shouldn't this give a warning?
				jacekAuthorUnsubmitted Done Inline Actions Interesting. I thought flow should indicate warning for such variables. jacek: Interesting. I thought flow should indicate warning for such variables.
				ashoatUnsubmitted Not Done Inline Actions There can be a good reason for having a prop that you never use: to force the component to rerender. For instance, we do something similar here ashoat: There can be a good reason for having a prop that you never use: to force the component to…
				+setErrorMessage: SetState<string>,
				+relationshipButtons: $ReadOnlyArray<RelationshipButton>,
				+otherUserInfo: UserInfo,
				};

				function ThreadSettingsRelationshipTab(props: Props): React.Node {
				const { relationshipButtons, otherUserInfo, setErrorMessage } = props;
				const buttons = React.useMemo(() => {
				return relationshipButtons.map(action => {
				return (
				<ThreadSettingsRelationshipButton
				key={action}
				relationshipButton={action}
				otherUserInfo={otherUserInfo}
				setErrorMessage={setErrorMessage}
				tomekUnsubmitted Not Done Inline Actions In `ThreadSettingsRelationshipButton` `setErrorMessage` is `string => void` but here we use `SetState<string>`. Is flow ok with that? Is there a good reason for having different types? tomek: In `ThreadSettingsRelationshipButton` `setErrorMessage` is `string => void` but here we use…
				jacekAuthorUnsubmitted Done Inline Actions Flow is ok here. I'll replace the type in `...Button` with `SetState<string>` jacek: Flow is ok here. I'll replace the type in `...Button` with `SetState<string>`
				/>
				);
				});
				}, [otherUserInfo, relationshipButtons, setErrorMessage]);
				return <div className={css.container}>{buttons}</div>;
				}

				export default ThreadSettingsRelationshipTab;

[native] [25/40] RN 0.70: Update to react-native-background-upload@6.6.0ClosedPublicActions

Details

Diff Detail

Event Timeline

Revision ContentsChangeset List

Diff 19824

native/ios/Podfile.lock

native/package.json

yarn.lock

[native] [25/40] RN 0.70: Update to react-native-background-upload@6.6.0
ClosedPublic
Actions

Revision Contents
Changeset List