Changed Styles and Screen Size for Mobile Device #59
252
app/index.tsx
@ -7,16 +7,17 @@ import ChipsSelector from "@/components/ChipsSelector";
|
|||||||
import ChipDistributionSummary from "@/components/ChipDistributionSummary";
|
import ChipDistributionSummary from "@/components/ChipDistributionSummary";
|
||||||
import ChipDetection from "@/components/ChipDetection";
|
import ChipDetection from "@/components/ChipDetection";
|
||||||
import CurrencySelector from "@/components/CurrencySelector";
|
import CurrencySelector from "@/components/CurrencySelector";
|
||||||
import { saveState, loadState } from "@/components/CalculatorState";
|
import { saveState, loadState } from "@/util/CalculatorState";
|
||||||
import {
|
import {
|
||||||
savePersistentState,
|
savePersistentState,
|
||||||
loadPersistentState,
|
loadPersistentState,
|
||||||
} from "@/components/PersistentState";
|
} from "@/util/PersistentState";
|
||||||
import styles from "@/styles/styles";
|
import styles from "@/styles/styles";
|
||||||
import Section from "@/containers/Section";
|
import Section from "@/containers/Section";
|
||||||
import AppContext from "@/util/context";
|
import AppContext from "@/util/context";
|
||||||
import { Picker } from "@react-native-picker/picker";
|
import { Picker } from "@react-native-picker/picker";
|
||||||
import i18n from "@/i18n/i18n";
|
import i18n from "@/i18n/i18n";
|
||||||
|
import PokerAppUi from "@/containers/PokerAppUi";
|
||||||
|
|
||||||
const IndexScreen: React.FC = () => {
|
const IndexScreen: React.FC = () => {
|
||||||
const [playerCount, setPlayerCount] = useState(2);
|
const [playerCount, setPlayerCount] = useState(2);
|
||||||
@ -25,23 +26,21 @@ const IndexScreen: React.FC = () => {
|
|||||||
const [totalChipsCount, setTotalChipsCount] = useState<number[]>([]);
|
const [totalChipsCount, setTotalChipsCount] = useState<number[]>([]);
|
||||||
const [selectedCurrency, setSelectedCurrency] = useState<string>("$");
|
const [selectedCurrency, setSelectedCurrency] = useState<string>("$");
|
||||||
const [selectedLanguage, setSelectedLanguage] = useState<string>("en");
|
const [selectedLanguage, setSelectedLanguage] = useState<string>("en");
|
||||||
|
const [lightGrayMode, setLightGrayMode] = useState<boolean>(false);
|
||||||
|
|
||||||
const context = useContext(AppContext);
|
const context = useContext(AppContext);
|
||||||
const isSettingsVisible = useMemo(() => context.showSettings, [context]);
|
const isSettingsVisible = useMemo(() => context.showSettings, [context]);
|
||||||
|
|
||||||
useEffect(() => {
|
useEffect(() => {
|
||||||
const loadPersistentData = async () => {
|
const loadPersistentData = async () => {
|
||||||
try {
|
try {
|
||||||
console.log("Loading persistent game state...");
|
|
||||||
const savedState = await loadPersistentState();
|
const savedState = await loadPersistentState();
|
||||||
if (savedState) {
|
if (savedState) {
|
||||||
console.log("Persistent state restored:", savedState);
|
|
||||||
setPlayerCount(savedState.playerCount || 2);
|
setPlayerCount(savedState.playerCount || 2);
|
||||||
setBuyInAmount(savedState.buyInAmount || 20);
|
setBuyInAmount(savedState.buyInAmount || 20);
|
||||||
setNumberOfChips(savedState.numberOfChips || 5);
|
setNumberOfChips(savedState.numberOfChips || 5);
|
||||||
setTotalChipsCount(savedState.totalChipsCount || []);
|
setTotalChipsCount(savedState.totalChipsCount || []);
|
||||||
setSelectedCurrency(savedState.selectedCurrency || "$");
|
setSelectedCurrency(savedState.selectedCurrency || "$");
|
||||||
} else {
|
|
||||||
console.log("No persistent state found, using defaults.");
|
|
||||||
}
|
}
|
||||||
} catch (error) {
|
} catch (error) {
|
||||||
console.error("Error loading persistent state:", error);
|
console.error("Error loading persistent state:", error);
|
||||||
@ -62,35 +61,23 @@ const IndexScreen: React.FC = () => {
|
|||||||
totalChipsCount,
|
totalChipsCount,
|
||||||
selectedCurrency,
|
selectedCurrency,
|
||||||
};
|
};
|
||||||
try {
|
await saveState(slot, state);
|
||||||
await saveState(slot, state);
|
await savePersistentState(state);
|
||||||
await savePersistentState(state);
|
Alert.alert(i18n.t("success"), i18n.t("state_saved", { slot }));
|
||||||
console.log(`Game state saved to ${slot}:`, state);
|
|
||||||
Alert.alert(i18n.t("success"), i18n.t("state_saved", { slot })); // Fixed interpolation
|
|
||||||
} catch (error) {
|
|
||||||
console.error("Error saving state:", error);
|
|
||||||
Alert.alert(i18n.t("error"), i18n.t("failed_to_save_state"));
|
|
||||||
}
|
|
||||||
};
|
};
|
||||||
|
|
||||||
const handleLoad = async (slot: "SLOT1" | "SLOT2") => {
|
const handleLoad = async (slot: "SLOT1" | "SLOT2") => {
|
||||||
try {
|
const loadedState = await loadState(slot);
|
||||||
const loadedState = await loadState(slot);
|
if (loadedState) {
|
||||||
if (loadedState) {
|
setPlayerCount(loadedState.playerCount);
|
||||||
setPlayerCount(loadedState.playerCount);
|
setBuyInAmount(loadedState.buyInAmount ?? 20);
|
||||||
setBuyInAmount(loadedState.buyInAmount ?? 20);
|
setNumberOfChips(loadedState.numberOfChips);
|
||||||
setNumberOfChips(loadedState.numberOfChips);
|
setTotalChipsCount(loadedState.totalChipsCount);
|
||||||
setTotalChipsCount(loadedState.totalChipsCount);
|
setSelectedCurrency(loadedState.selectedCurrency || "$");
|
||||||
setSelectedCurrency(loadedState.selectedCurrency || "$");
|
await savePersistentState(loadedState);
|
||||||
await savePersistentState(loadedState);
|
Alert.alert(i18n.t("success"), i18n.t("state_loaded_from", { slot }));
|
||||||
console.log(`Game state loaded from ${slot}:`, loadedState);
|
} else {
|
||||||
Alert.alert(i18n.t("success"), i18n.t("state_loaded_from", { slot })); // Fixed interpolation
|
Alert.alert(i18n.t("info"), i18n.t("no_saved_state_found"));
|
||||||
} else {
|
|
||||||
Alert.alert(i18n.t("info"), i18n.t("no_saved_state_found"));
|
|
||||||
}
|
|
||||||
} catch (error) {
|
|
||||||
console.error("Error loading state:", error);
|
|
||||||
Alert.alert(i18n.t("error"), i18n.t("failed_to_load_state"));
|
|
||||||
}
|
}
|
||||||
};
|
};
|
||||||
|
|
||||||
@ -100,107 +87,122 @@ const IndexScreen: React.FC = () => {
|
|||||||
};
|
};
|
||||||
|
|
||||||
return (
|
return (
|
||||||
<ScrollView
|
<PokerAppUi darkMode={lightGrayMode}>
|
||||||
style={styles.scrollView}
|
<ScrollView
|
||||||
contentContainerStyle={styles.scrollViewContent}
|
style={styles.scrollView}
|
||||||
>
|
contentContainerStyle={styles.scrollViewContent}
|
||||||
{isSettingsVisible && (
|
>
|
||||||
<Section
|
<Section
|
||||||
title={i18n.t("select_language")}
|
title={i18n.t("appearance")}
|
||||||
iconName={"language"}
|
iconName={"brightness-4"}
|
||||||
orientation="row"
|
orientation="row"
|
||||||
>
|
>
|
||||||
<Picker
|
<Button
|
||||||
selectedValue={selectedLanguage}
|
title={
|
||||||
onValueChange={handleLanguageChange}
|
lightGrayMode
|
||||||
style={styles.picker}
|
? i18n.t("switch_to_light_mode")
|
||||||
>
|
: i18n.t("switch_to_gray_mode")
|
||||||
<Picker.Item label={i18n.t("english")} value="en" />
|
}
|
||||||
<Picker.Item label={i18n.t("spanish")} value="es" />
|
onPress={() => setLightGrayMode(!lightGrayMode)}
|
||||||
</Picker>
|
|
||||||
</Section>
|
|
||||||
)}
|
|
||||||
|
|
||||||
{isSettingsVisible && (
|
|
||||||
<Section
|
|
||||||
title={i18n.t("select_currency")}
|
|
||||||
iconName={"attach-money"}
|
|
||||||
orientation="row"
|
|
||||||
>
|
|
||||||
<CurrencySelector
|
|
||||||
selectedCurrency={selectedCurrency}
|
|
||||||
setSelectedCurrency={setSelectedCurrency}
|
|
||||||
/>
|
/>
|
||||||
</Section>
|
</Section>
|
||||||
)}
|
|
||||||
|
|
||||||
<Section
|
{isSettingsVisible && (
|
||||||
title={i18n.t("select_number_of_players")}
|
<Section
|
||||||
iconName={"people"}
|
title={i18n.t("select_language")}
|
||||||
orientation="row"
|
iconName={"language"}
|
||||||
contentStyle={{ justifyContent: "center", gap: 30 }}
|
orientation="row"
|
||||||
>
|
>
|
||||||
<PlayerSelector
|
<Picker
|
||||||
playerCount={playerCount}
|
selectedValue={selectedLanguage}
|
||||||
setPlayerCount={setPlayerCount}
|
onValueChange={handleLanguageChange}
|
||||||
/>
|
style={styles.picker}
|
||||||
</Section>
|
>
|
||||||
|
<Picker.Item label={i18n.t("english")} value="en" />
|
||||||
|
<Picker.Item label={i18n.t("spanish")} value="es" />
|
||||||
|
</Picker>
|
||||||
|
</Section>
|
||||||
|
)}
|
||||||
|
|
||||||
<Section
|
{isSettingsVisible && (
|
||||||
title={i18n.t("select_buyin_amount")}
|
<Section
|
||||||
iconName={"monetization-on"}
|
title={i18n.t("select_currency")}
|
||||||
>
|
iconName={"attach-money"}
|
||||||
<BuyInSelector
|
orientation="row"
|
||||||
selectedCurrency={selectedCurrency}
|
>
|
||||||
setBuyInAmount={setBuyInAmount}
|
<CurrencySelector
|
||||||
/>
|
selectedCurrency={selectedCurrency}
|
||||||
</Section>
|
setSelectedCurrency={setSelectedCurrency}
|
||||||
|
/>
|
||||||
|
</Section>
|
||||||
|
)}
|
||||||
|
|
||||||
<Section
|
<Section
|
||||||
title={i18n.t("automatic_chip_detection")}
|
title={i18n.t("select_number_of_players")}
|
||||||
iconName={"camera-alt"}
|
iconName={"people"}
|
||||||
>
|
orientation="row"
|
||||||
<ChipDetection
|
contentStyle={{ justifyContent: "center", gap: 30 }}
|
||||||
updateChipCount={(chipData) => {
|
>
|
||||||
const chipCountArray = Object.values(chipData);
|
<PlayerSelector
|
||||||
setTotalChipsCount(chipCountArray);
|
playerCount={playerCount}
|
||||||
setNumberOfChips(chipCountArray.length);
|
setPlayerCount={setPlayerCount}
|
||||||
}}
|
/>
|
||||||
/>
|
</Section>
|
||||||
</Section>
|
|
||||||
|
|
||||||
<Section
|
<Section
|
||||||
title={i18n.t("manual_chip_adjustment")}
|
title={i18n.t("select_buyin_amount")}
|
||||||
iconName={"account-balance"}
|
iconName={"monetization-on"}
|
||||||
orientation="row"
|
>
|
||||||
contentStyle={{ alignItems: "center" }}
|
<BuyInSelector
|
||||||
>
|
selectedCurrency={selectedCurrency}
|
||||||
<ChipsSelector
|
setBuyInAmount={setBuyInAmount}
|
||||||
totalChipsCount={totalChipsCount}
|
/>
|
||||||
setTotalChipsCount={setTotalChipsCount}
|
</Section>
|
||||||
numberOfChips={numberOfChips}
|
|
||||||
setNumberOfChips={setNumberOfChips}
|
|
||||||
/>
|
|
||||||
</Section>
|
|
||||||
|
|
||||||
<Section
|
<Section
|
||||||
title={i18n.t("distribution_and_denomination")}
|
title={i18n.t("automatic_chip_detection")}
|
||||||
iconName={"currency-exchange"}
|
iconName={"camera-alt"}
|
||||||
>
|
>
|
||||||
<ChipDistributionSummary
|
<ChipDetection
|
||||||
playerCount={playerCount}
|
updateChipCount={(chipData) => {
|
||||||
buyInAmount={buyInAmount}
|
const chipCountArray = Object.values(chipData);
|
||||||
totalChipsCount={totalChipsCount}
|
setTotalChipsCount(chipCountArray);
|
||||||
selectedCurrency={selectedCurrency}
|
setNumberOfChips(chipCountArray.length);
|
||||||
/>
|
}}
|
||||||
</Section>
|
/>
|
||||||
|
</Section>
|
||||||
|
|
||||||
<Section
|
<Section
|
||||||
title={i18n.t("save_and_load")}
|
title={i18n.t("manual_chip_adjustment")}
|
||||||
iconName={"save"}
|
iconName={"account-balance"}
|
||||||
orientation="row"
|
orientation="row"
|
||||||
>
|
contentStyle={{ alignItems: "center" }}
|
||||||
<>
|
>
|
||||||
|
<ChipsSelector
|
||||||
|
totalChipsCount={totalChipsCount}
|
||||||
|
setTotalChipsCount={setTotalChipsCount}
|
||||||
|
numberOfChips={numberOfChips}
|
||||||
|
setNumberOfChips={setNumberOfChips}
|
||||||
|
/>
|
||||||
|
</Section>
|
||||||
|
|
||||||
|
<Section
|
||||||
|
title={i18n.t("distribution_and_denomination")}
|
||||||
|
iconName={"currency-exchange"}
|
||||||
|
>
|
||||||
|
<ChipDistributionSummary
|
||||||
|
playerCount={playerCount}
|
||||||
|
buyInAmount={buyInAmount}
|
||||||
|
totalChipsCount={totalChipsCount}
|
||||||
|
selectedCurrency={selectedCurrency}
|
||||||
|
/>
|
||||||
|
</Section>
|
||||||
|
|
||||||
|
<Section
|
||||||
|
title={i18n.t("save_and_load")}
|
||||||
|
iconName={"save"}
|
||||||
|
orientation="row"
|
||||||
|
>
|
||||||
<Button
|
<Button
|
||||||
title={i18n.t("save_slot_1")}
|
title={i18n.t("save_slot_1")}
|
||||||
onPress={() => handleSave("SLOT1")}
|
onPress={() => handleSave("SLOT1")}
|
||||||
@ -219,9 +221,9 @@ const IndexScreen: React.FC = () => {
|
|||||||
title={i18n.t("load_slot_2")}
|
title={i18n.t("load_slot_2")}
|
||||||
onPress={() => handleLoad("SLOT2")}
|
onPress={() => handleLoad("SLOT2")}
|
||||||
/>
|
/>
|
||||||
</>
|
</Section>
|
||||||
</Section>
|
</ScrollView>
|
||||||
</ScrollView>
|
</PokerAppUi>
|
||||||
);
|
);
|
||||||
};
|
};
|
||||||
|
|
||||||
|
|||||||
@ -1,9 +1,69 @@
|
|||||||
|
|
|||||||
import { ButtonProps, Button } from "react-native";
|
import React from "react";
|
||||||
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
import { COLORS } from "@/styles/styles";
|
import { Text, TouchableOpacity, StyleSheet } from "react-native";
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
|
||||||
// More styling can be done, or swap this out with more flexible component like a TouchableOpacity if needed
|
interface ButtonProps {
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
const AppButton = (props: ButtonProps) => (
|
title: string;
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
<Button color={COLORS.PRIMARY} {...props} />
|
onPress: () => void;
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
);
|
disabled?: boolean;
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
darkMode: boolean;
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
}
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
|
||||||
export default AppButton;
|
const Button: React.FC<ButtonProps> = ({
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
title,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
onPress,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
disabled,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
darkMode,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
}) => {
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
return (
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
<TouchableOpacity
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
onPress={onPress}
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
disabled={disabled}
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
style={[
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
styles.button,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
darkMode ? styles.darkButton : styles.lightButton,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
disabled && styles.disabled,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
]}
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
>
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
<Text
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
style={[
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
styles.buttonText,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
darkMode ? styles.darkText : styles.lightText,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
]}
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
>
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
{title}
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
</Text>
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
</TouchableOpacity>
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
);
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
};
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
const styles = StyleSheet.create({
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
button: {
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
paddingVertical: 10,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
paddingHorizontal: 20,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
borderRadius: 8,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
marginHorizontal: 5,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
marginVertical: 5,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
},
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
darkButton: {
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
backgroundColor: "#333333",
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
},
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
lightButton: {
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
backgroundColor: "#DDDDDD",
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
},
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
buttonText: {
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
fontSize: 16,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
fontWeight: "bold",
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
textAlign: "center",
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
},
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
darkText: {
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
color: "#FFFFFF",
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
},
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
lightText: {
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
color: "#000000",
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
},
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
disabled: {
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
opacity: 0.5,
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
},
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
});
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
export default Button;
|
||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
|
|||||||
|
|||||||
|
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
Can you run Free to resolve. Can you run `npx tsc` and confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundant
Free to resolve.
fixed these. fixed these.
fixed these. fixed these.
|
|||||||
52
containers/PokerAppUi.tsx
Normal file
@ -0,0 +1,52 @@
|
|||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
I believe this issue is solved I believe this issue is solved
|
|||||||
|
import React, { ReactNode } from "react";
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
import {
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
SafeAreaView,
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
StatusBar,
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
View,
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
StyleSheet,
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
Dimensions,
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
} from "react-native";
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
interface PokerAppUiProps {
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
children: ReactNode;
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
darkMode?: boolean;
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
}
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
const PokerAppUi: React.FC<PokerAppUiProps> = ({
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
children,
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
darkMode = false,
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
}) => {
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
const screenHeight = Dimensions.get("window").height;
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
return (
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
<SafeAreaView
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
style={[styles.safeArea, darkMode ? styles.lightGray : styles.light]}
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
>
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
<StatusBar barStyle={"dark-content"} />
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
<View style={[styles.container, { minHeight: screenHeight }]}>
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
{children}
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
</View>
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
</SafeAreaView>
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
);
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
};
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
const styles = StyleSheet.create({
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
safeArea: {
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
flex: 1,
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
},
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
container: {
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
flex: 1,
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
width: "100%",
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
padding: 16,
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
justifyContent: "flex-start",
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
alignItems: "center",
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
},
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
light: {
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
backgroundColor: "#F5F5F5",
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
},
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
lightGray: {
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
backgroundColor: "#D3D3D3",
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
},
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
});
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
|
export default PokerAppUi;
|
||||||
|
I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout. If that is correct, consider that expos stack navigation system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components. For example, our Apps We can discuss this in sync to make sure we are all on the right path I may be wrong, but it seems like the purpose of this component is to be a wrapper of sorts for stylistic purposes, to serve the global app layout.
If that is correct, consider that [expos stack navigation](https://docs.expo.dev/router/advanced/stack/#configure-header-bar) system provides a purpose built and best practice system to do this universally, and reduce complexity by not needing wrapper components.
For example, our Apps `<Stack>` (as implemented in `_layout.tsx`) can take a screen options parameter called `contentStyle`. This is an object which can contain a `backgroundColor`. That would be the expo way to set the background color for our app, even dynamically. The `<Stack>` props are powerfull and can take all sorts of nested style options for the main app content, header, title, etc.
We can discuss this in sync to make sure we are all on the right path
Do you know what the status bar is doing for the app? Do you know what the status bar is doing for the app?
The StatusBar is used to control the appearance of the mobile device's status bar when the app is running. The StatusBar is used to control the appearance of the mobile device's status bar when the app is running.
I believe this issue is solved I believe this issue is solved
|
|||||||
2
package-lock.json
generated
@ -13,7 +13,7 @@
|
|||||||
"@react-native-picker/picker": "^2.11.0",
|
"@react-native-picker/picker": "^2.11.0",
|
||||||
"@react-navigation/bottom-tabs": "7.2.0",
|
"@react-navigation/bottom-tabs": "7.2.0",
|
||||||
"@react-navigation/native": "7.0.14",
|
"@react-navigation/native": "7.0.14",
|
||||||
"expo": "52.0.37",
|
"expo": "^52.0.37",
|
||||||
"expo-blur": "14.0.3",
|
"expo-blur": "14.0.3",
|
||||||
"expo-constants": "17.0.7",
|
"expo-constants": "17.0.7",
|
||||||
"expo-file-system": "18.0.11",
|
"expo-file-system": "18.0.11",
|
||||||
|
|||||||
@ -23,7 +23,7 @@
|
|||||||
"@react-native-picker/picker": "^2.11.0",
|
"@react-native-picker/picker": "^2.11.0",
|
||||||
"@react-navigation/bottom-tabs": "7.2.0",
|
"@react-navigation/bottom-tabs": "7.2.0",
|
||||||
"@react-navigation/native": "7.0.14",
|
"@react-navigation/native": "7.0.14",
|
||||||
"expo": "52.0.37",
|
"expo": "^52.0.37",
|
||||||
"expo-blur": "14.0.3",
|
"expo-blur": "14.0.3",
|
||||||
"expo-constants": "17.0.7",
|
"expo-constants": "17.0.7",
|
||||||
"expo-file-system": "18.0.11",
|
"expo-file-system": "18.0.11",
|
||||||
@ -31,6 +31,7 @@
|
|||||||
"expo-haptics": "14.0.1",
|
"expo-haptics": "14.0.1",
|
||||||
"expo-image-picker": "16.0.6",
|
"expo-image-picker": "16.0.6",
|
||||||
"expo-linking": "7.0.5",
|
"expo-linking": "7.0.5",
|
||||||
|
"expo-localization": "~16.0.1",
|
||||||
"expo-router": "4.0.17",
|
"expo-router": "4.0.17",
|
||||||
"expo-splash-screen": "0.29.22",
|
"expo-splash-screen": "0.29.22",
|
||||||
"expo-status-bar": "2.0.1",
|
"expo-status-bar": "2.0.1",
|
||||||
@ -47,8 +48,7 @@
|
|||||||
"react-native-safe-area-context": "4.12.0",
|
"react-native-safe-area-context": "4.12.0",
|
||||||
"react-native-screens": "4.4.0",
|
"react-native-screens": "4.4.0",
|
||||||
"react-native-web": "0.19.13",
|
"react-native-web": "0.19.13",
|
||||||
"react-native-webview": "13.12.5",
|
"react-native-webview": "13.12.5"
|
||||||
"expo-localization": "~16.0.1"
|
|
||||||
},
|
},
|
||||||
"devDependencies": {
|
"devDependencies": {
|
||||||
"@babel/core": "7.26.9",
|
"@babel/core": "7.26.9",
|
||||||
|
|||||||
@ -1,12 +1,12 @@
|
|||||||
import AsyncStorage from "@react-native-async-storage/async-storage";
|
import AsyncStorage from "@react-native-async-storage/async-storage";
|
||||||
import { saveState, loadState, PokerState } from "../CalculatorState";
|
import { saveState, loadState, PokerState } from "@/util/CalculatorState";
|
||||||
|
|
||||||
// Mock AsyncStorage
|
// Mock AsyncStorage
|
||||||
jest.mock("@react-native-async-storage/async-storage", () =>
|
jest.mock("@react-native-async-storage/async-storage", () =>
|
||||||
require("@react-native-async-storage/async-storage/jest/async-storage-mock")
|
require("@react-native-async-storage/async-storage/jest/async-storage-mock")
|
||||||
);
|
);
|
||||||
|
|
||||||
describe("CalculatorState.tsx", () => {
|
describe("CalculatorState.ts", () => {
|
||||||
const mockState: PokerState = {
|
const mockState: PokerState = {
|
||||||
playerCount: 4,
|
playerCount: 4,
|
||||||
buyInAmount: 50,
|
buyInAmount: 50,
|
||||||
@ -3,14 +3,14 @@ import {
|
|||||||
savePersistentState,
|
savePersistentState,
|
||||||
loadPersistentState,
|
loadPersistentState,
|
||||||
PokerState,
|
PokerState,
|
||||||
} from "../PersistentState";
|
} from "@/util/PersistentState";
|
||||||
|
|
||||||
jest.mock("@react-native-async-storage/async-storage", () => ({
|
jest.mock("@react-native-async-storage/async-storage", () => ({
|
||||||
setItem: jest.fn(),
|
setItem: jest.fn(),
|
||||||
getItem: jest.fn(),
|
getItem: jest.fn(),
|
||||||
}));
|
}));
|
||||||
|
|
||||||
describe("PersistentState.tsx", () => {
|
describe("PersistentState.ts", () => {
|
||||||
|
Not related to this file/line, but I checked out the branch and ran Free to resolve when done Not related to this file/line, but I checked out the branch and ran `npm t` It seems that possibly some existing tests have broken with these changes.
Can you confirm this, and fix up the pre-existing tests as necessary so they all pass?
Free to resolve when done
It is working without any error on my machine. It is working without any error on my machine.
|
|||||||
const mockState: PokerState = {
|
const mockState: PokerState = {
|
||||||
playerCount: 4,
|
playerCount: 4,
|
||||||
buyInAmount: 50,
|
buyInAmount: 50,
|
||||||
Can you run
npx tscand confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundantFree to resolve.
Can you run
npx tscand confirm that this change, and any other new changes are not introducing typescript errors? It appears from my end that they might be. If so, they should be fixed please. However, please see my other comment about prop passing for a color scheme which may make some of these typescript errors redundantFree to resolve.
fixed these.
fixed these.