Paths

Table of Contentst

-
keyserver/src/fetchers/
-
src/
-
fetchers/
-
message-fetchers.js

[lib] Refactor fetchDerivedMessages to call isInvalidSidebarSource or isInvalidPinSource
ClosedPublic
Actions

Authored by rohan on Oct 19 2023, 6:39 AM.

Details

Reviewers

atul
ginsu

Commits

rCOMM8f24d1bb8c0e: [lib] Refactor fetchDerivedMessages to call isInvalidSidebarSource or…

Summary

Now that we have both isInvalidSidebarSource and isInvalidPinSource, it makes sense to make the checks in fetchDerivedMessages more specific. Rather than simply filtering out message types generically, we'll handle it more specifically with 1) checking the message type and 2) calling either isInvalidSidebarSource or isInvalidPinSource accordingly.

Once again, there's a FlowFixMe for the same reason as in D9537 -- Flow doesn't refine the types if I don't explicitly invariant on all of the unexpected message types, and that list can either get long or just generally defeats the purpose of moving the logic into message specs to have one single source of truth.

Resolves https://linear.app/comm/issue/ENG-5218/refactor-fetchderivedmessages-to-call-isinvalidsidebarsource-or

Depends on D9537

Test Plan

yarn workspace lib test and repeated the same test plan as D9537 to ensure usage of the app doesn't trigger unexpected invariants

Diff Detail

Repository

rCOMM Comm

Branch

ENG-4849

Lint

No Lint Coverage

Unit

No Test Coverage

Event Timeline

rohan created this revision.Oct 19 2023, 6:39 AM

rohan held this revision as a draft.

Herald added subscribers: will, tomek, ashoat. · View Herald TranscriptOct 19 2023, 6:39 AM

rohan edited the summary of this revision. (Show Details)Oct 19 2023, 6:40 AM

rohan added inline comments.

keyserver/src/fetchers/message-fetchers.js
773	Once again, there's a `FlowFixMe` for the same reason as in D9537 -- Flow doesn't refine the types if I don't explicitly `invariant` on all of the unexpected message types, and that list can either get long or just generally defeats the purpose of moving the logic into message specs to have one single source of truth.

rohan added inline comments.Oct 19 2023, 6:44 AM

keyserver/src/fetchers/message-fetchers.js
760	Note - should fix this concatenation

Harbormaster completed remote builds in B23362: Diff 32196.Oct 19 2023, 7:25 AM

rohan published this revision for review.Oct 19 2023, 7:49 AM

rohan added a child revision: D9542: [keyserver/lib] Introduce a parseDerivedMessages function in the message specs.Oct 19 2023, 9:16 AM

atul accepted this revision.Oct 19 2023, 11:37 AM

atul added inline comments.

keyserver/src/fetchers/message-fetchers.js
760	You plan on fixing this before landing, right?
773	Let's include a concise version of this comment next to the `$FlowFixMe` so the reasoning is more clear.

This revision is now accepted and ready to land.Oct 19 2023, 11:37 AM

Fix concatenation and add comment

Harbormaster completed remote builds in B23379: Diff 32226.Oct 19 2023, 12:10 PM

Closed by commit rCOMM8f24d1bb8c0e: [lib] Refactor fetchDerivedMessages to call isInvalidSidebarSource or… (authored by rohan). · Explain WhyOct 20 2023, 8:27 AM

This revision was automatically updated to reflect the committed changes.

rohan added a commit: rCOMM8f24d1bb8c0e: [lib] Refactor fetchDerivedMessages to call isInvalidSidebarSource or….

Revision Contents
Changeset List

Path

Size

keyserver/

src/

fetchers/

message-fetchers.js

22 lines

Diff 32196

View Options

keyserver/src/fetchers/message-fetchers.js

	// @flow			// @flow

	import { HeaderBackButton as BaseHeaderBackButton } from '@react-navigation/elements';			import { HeaderBackButton as BaseHeaderBackButton } from '@react-navigation/elements';
				import invariant from 'invariant';
	import * as React from 'react';			import * as React from 'react';
	import { Text } from 'react-native';			import { Alert, Text } from 'react-native';
	import { TouchableOpacity } from 'react-native-gesture-handler';			import { TouchableOpacity } from 'react-native-gesture-handler';

				import type { NavigationRoute } from '../navigation/route-names';
	import { useColors } from '../themes/colors.js';			import { useColors } from '../themes/colors.js';

	type Props = React.ElementConfig<typeof BaseHeaderBackButton>;			type ChangeRolesHeaderLeftButtonProps = {
	function ChangeRolesHeaderLeftButton(props: Props): React.Node {			+route: NavigationRoute<'ChangeRolesScreen'>,
				...React.ElementConfig<typeof BaseHeaderBackButton>,
				};

				function ChangeRolesHeaderLeftButton(
				props: ChangeRolesHeaderLeftButtonProps,
				): React.Node {
				const { memberInfo, role: selectedRole } = props.route.params;
				const { role: memberRole } = memberInfo;

				const onCancel = React.useCallback(() => {
				const { onPress } = props;
				invariant(onPress, 'onPress must be defined');

				if (selectedRole === memberRole) {
				onPress();
				return;
				}

				Alert.alert(
				'Unsaved Changes',
				'You have unsaved changes, are you sure you want to cancel? You will lose all your progress',
				[
				{ text: 'Cancel', onPress },
				{ text: 'Stay', style: 'cancel' },
				],
				{ cancelable: true },
				);
				}, [memberRole, props, selectedRole]);
				rohanAuthorUnsubmitted Done Inline Actions I think the wording here may be a bit confusing. In my experience, 'cancel' typically means close the alert, and there's another option like 'confirm' or something that will mean you're ok with discarding changes. Here it seems like 'cancel' means we're ok with discarding changes. Not sure if it's just me though (cc @ted) rohan: I think the wording here may be a bit confusing. In my experience, 'cancel' typically means…
				ashoatUnsubmitted Not Done Inline Actions What do we do in the current edit-message workflow? Heads-up I generally handle copy, not @ted ashoat: What do we do in the current edit-message workflow? Heads-up I generally handle copy, not @ted
				rohanAuthorUnsubmitted Done Inline Actions Ah my bad. It looks like in message editing: `Continue editing` closes the alert and continues editing while `Discard edit` closes the alert and exits editing rohan: Ah my bad. It looks like in message editing: `Continue editing` closes the alert and continues…
				ashoatUnsubmitted Not Done Inline Actions I agree we shouldn't use the term `Cancel` here... how about `Leave`? I don't think we need `{ cancelable: true }`... we can just default to `Stay` if the user dismisses the `Alert` Can we try to match copy for title / description with the edit-message workflow? ashoat: 1. I agree we shouldn't use the term `Cancel` here... how about `Leave`? 2. I don't think we…
				rohanAuthorUnsubmitted Done Inline Actions Yeah that makes sense, I'll update the diff rohan: Yeah that makes sense, I'll update the diff

	const { panelForegroundSecondaryLabel } = useColors();			const { panelForegroundSecondaryLabel } = useColors();
	const labelStyle = React.useMemo(			const labelStyle = React.useMemo(
	() => ({			() => ({
	color: panelForegroundSecondaryLabel,			color: panelForegroundSecondaryLabel,
	marginLeft: 10,			marginLeft: 10,
	}),			}),
	[panelForegroundSecondaryLabel],			[panelForegroundSecondaryLabel],
	);			);

	return (			return (
	<TouchableOpacity onPress={props.onPress}>			<TouchableOpacity onPress={onCancel}>
	<Text style={labelStyle}>Cancel</Text>			<Text style={labelStyle}>Cancel</Text>
	</TouchableOpacity>			</TouchableOpacity>
	);			);
	}			}

	export default ChangeRolesHeaderLeftButton;			export default ChangeRolesHeaderLeftButton;

[lib] Refactor fetchDerivedMessages to call isInvalidSidebarSource or isInvalidPinSourceClosedPublicActions