Changed Styles and Screen Size for Mobile Device #59
@ -7,16 +7,17 @@ import ChipsSelector from "@/components/ChipsSelector";
|
||||
import ChipDistributionSummary from "@/components/ChipDistributionSummary";
|
||||
import ChipDetection from "@/components/ChipDetection";
|
||||
import CurrencySelector from "@/components/CurrencySelector";
|
||||
import { saveState, loadState } from "@/components/CalculatorState";
|
||||
import { saveState, loadState } from "@/util/CalculatorState";
|
||||
import {
|
||||
savePersistentState,
|
||||
loadPersistentState,
|
||||
} from "@/components/PersistentState";
|
||||
} from "@/util/PersistentState";
|
||||
import styles from "@/styles/styles";
|
||||
import Section from "@/containers/Section";
|
||||
import AppContext from "@/util/context";
|
||||
import { Picker } from "@react-native-picker/picker";
|
||||
import i18n from "@/i18n/i18n";
|
||||
import PokerAppUi from "@/containers/PokerAppUi";
|
||||
|
||||
const IndexScreen: React.FC = () => {
|
||||
const [playerCount, setPlayerCount] = useState(2);
|
||||
@ -25,23 +26,21 @@ const IndexScreen: React.FC = () => {
|
||||
const [totalChipsCount, setTotalChipsCount] = useState<number[]>([]);
|
||||
const [selectedCurrency, setSelectedCurrency] = useState<string>("$");
|
||||
const [selectedLanguage, setSelectedLanguage] = useState<string>("en");
|
||||
const [lightGrayMode, setLightGrayMode] = useState<boolean>(false);
|
||||
|
||||
const context = useContext(AppContext);
|
||||
const isSettingsVisible = useMemo(() => context.showSettings, [context]);
|
||||
|
||||
useEffect(() => {
|
||||
const loadPersistentData = async () => {
|
||||
try {
|
||||
console.log("Loading persistent game state...");
|
||||
const savedState = await loadPersistentState();
|
||||
if (savedState) {
|
||||
console.log("Persistent state restored:", savedState);
|
||||
setPlayerCount(savedState.playerCount || 2);
|
||||
setBuyInAmount(savedState.buyInAmount || 20);
|
||||
setNumberOfChips(savedState.numberOfChips || 5);
|
||||
setTotalChipsCount(savedState.totalChipsCount || []);
|
||||
setSelectedCurrency(savedState.selectedCurrency || "$");
|
||||
} else {
|
||||
console.log("No persistent state found, using defaults.");
|
||||
}
|
||||
} catch (error) {
|
||||
console.error("Error loading persistent state:", error);
|
||||
@ -62,19 +61,12 @@ const IndexScreen: React.FC = () => {
|
||||
totalChipsCount,
|
||||
selectedCurrency,
|
||||
};
|
||||
try {
|
||||
await saveState(slot, state);
|
||||
await savePersistentState(state);
|
||||
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"));
|
||||
}
|
||||
Alert.alert(i18n.t("success"), i18n.t("state_saved", { slot }));
|
||||
};
|
||||
|
||||
const handleLoad = async (slot: "SLOT1" | "SLOT2") => {
|
||||
try {
|
||||
const loadedState = await loadState(slot);
|
||||
if (loadedState) {
|
||||
setPlayerCount(loadedState.playerCount);
|
||||
@ -83,15 +75,10 @@ const IndexScreen: React.FC = () => {
|
||||
setTotalChipsCount(loadedState.totalChipsCount);
|
||||
setSelectedCurrency(loadedState.selectedCurrency || "$");
|
||||
await savePersistentState(loadedState);
|
||||
console.log(`Game state loaded from ${slot}:`, loadedState);
|
||||
Alert.alert(i18n.t("success"), i18n.t("state_loaded_from", { slot })); // Fixed interpolation
|
||||
Alert.alert(i18n.t("success"), i18n.t("state_loaded_from", { slot }));
|
||||
} 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"));
|
||||
}
|
||||
};
|
||||
|
||||
const handleLanguageChange = (language: string) => {
|
||||
@ -100,10 +87,26 @@ const IndexScreen: React.FC = () => {
|
||||
};
|
||||
|
||||
return (
|
||||
<PokerAppUi darkMode={lightGrayMode}>
|
||||
<ScrollView
|
||||
style={styles.scrollView}
|
||||
contentContainerStyle={styles.scrollViewContent}
|
||||
>
|
||||
<Section
|
||||
title={i18n.t("appearance")}
|
||||
iconName={"brightness-4"}
|
||||
orientation="row"
|
||||
>
|
||||
<Button
|
||||
title={
|
||||
lightGrayMode
|
||||
? i18n.t("switch_to_light_mode")
|
||||
: i18n.t("switch_to_gray_mode")
|
||||
}
|
||||
onPress={() => setLightGrayMode(!lightGrayMode)}
|
||||
/>
|
||||
</Section>
|
||||
|
||||
{isSettingsVisible && (
|
||||
<Section
|
||||
title={i18n.t("select_language")}
|
||||
@ -200,7 +203,6 @@ const IndexScreen: React.FC = () => {
|
||||
iconName={"save"}
|
||||
orientation="row"
|
||||
>
|
||||
<>
|
||||
<Button
|
||||
title={i18n.t("save_slot_1")}
|
||||
onPress={() => handleSave("SLOT1")}
|
||||
@ -219,9 +221,9 @@ const IndexScreen: React.FC = () => {
|
||||
title={i18n.t("load_slot_2")}
|
||||
onPress={() => handleLoad("SLOT2")}
|
||||
/>
|
||||
</>
|
||||
</Section>
|
||||
</ScrollView>
|
||||
</PokerAppUi>
|
||||
);
|
||||
};
|
||||
|
||||
|
@ -1,9 +1,69 @@
|
||||
|
||||
import { ButtonProps, Button } 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.
|
||||
import { COLORS } from "@/styles/styles";
|
||||
![]() 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 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.
|
||||
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.
|
||||
|
||||
// More styling can be done, or swap this out with more flexible component like a TouchableOpacity if needed
|
||||
![]() 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) => (
|
||||
![]() 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} />
|
||||
![]() 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
![]() 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 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.
|
||||
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.
|
||||
|
||||
export default AppButton;
|
||||
![]() 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-navigation/bottom-tabs": "7.2.0",
|
||||
"@react-navigation/native": "7.0.14",
|
||||
"expo": "52.0.37",
|
||||
"expo": "^52.0.37",
|
||||
"expo-blur": "14.0.3",
|
||||
"expo-constants": "17.0.7",
|
||||
"expo-file-system": "18.0.11",
|
||||
|
@ -23,7 +23,7 @@
|
||||
"@react-native-picker/picker": "^2.11.0",
|
||||
"@react-navigation/bottom-tabs": "7.2.0",
|
||||
"@react-navigation/native": "7.0.14",
|
||||
"expo": "52.0.37",
|
||||
"expo": "^52.0.37",
|
||||
"expo-blur": "14.0.3",
|
||||
"expo-constants": "17.0.7",
|
||||
"expo-file-system": "18.0.11",
|
||||
@ -31,6 +31,7 @@
|
||||
"expo-haptics": "14.0.1",
|
||||
"expo-image-picker": "16.0.6",
|
||||
"expo-linking": "7.0.5",
|
||||
"expo-localization": "~16.0.1",
|
||||
"expo-router": "4.0.17",
|
||||
"expo-splash-screen": "0.29.22",
|
||||
"expo-status-bar": "2.0.1",
|
||||
@ -47,8 +48,7 @@
|
||||
"react-native-safe-area-context": "4.12.0",
|
||||
"react-native-screens": "4.4.0",
|
||||
"react-native-web": "0.19.13",
|
||||
"react-native-webview": "13.12.5",
|
||||
"expo-localization": "~16.0.1"
|
||||
"react-native-webview": "13.12.5"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@babel/core": "7.26.9",
|
||||
|
@ -1,12 +1,12 @@
|
||||
import AsyncStorage from "@react-native-async-storage/async-storage";
|
||||
import { saveState, loadState, PokerState } from "../CalculatorState";
|
||||
import { saveState, loadState, PokerState } from "@/util/CalculatorState";
|
||||
|
||||
// Mock AsyncStorage
|
||||
jest.mock("@react-native-async-storage/async-storage", () =>
|
||||
require("@react-native-async-storage/async-storage/jest/async-storage-mock")
|
||||
);
|
||||
|
||||
describe("CalculatorState.tsx", () => {
|
||||
describe("CalculatorState.ts", () => {
|
||||
const mockState: PokerState = {
|
||||
playerCount: 4,
|
||||
buyInAmount: 50,
|
@ -3,14 +3,14 @@ import {
|
||||
savePersistentState,
|
||||
loadPersistentState,
|
||||
PokerState,
|
||||
} from "../PersistentState";
|
||||
} from "@/util/PersistentState";
|
||||
|
||||
jest.mock("@react-native-async-storage/async-storage", () => ({
|
||||
setItem: 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 = {
|
||||
playerCount: 4,
|
||||
buyInAmount: 50,
|
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 redundantFree 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 redundantFree to resolve.
fixed these.
fixed these.