Каков наилучший способ структурировать набор экранов React Native с помощью общей навигации? - PullRequest
Новая
       32

Каков наилучший способ структурировать набор экранов React Native с помощью общей навигации?

0 голосов
/ 05 апреля 2020

Я пытаюсь создать приложение React Native, в котором в левой части заголовка есть кнопка меню, и нажатие этой кнопки вызывает переключение меню в верхней части реального экрана. Под этим меню находится содержание каждого отдельного экрана. Я пытаюсь сделать приложение таким, чтобы все экраны разделяли эту структуру, и вы можете переключаться между ними с помощью переключаемого меню.

Базовая c структура, которую я имею для функции рендеринга экрана, - это нечто как следующее: 

<View>
    { showMenu && (
        menuLinks.map((link) => {
            return (
                <View>
                    <TouchableOpacity
                        onPress={() => {/* Go to another screen. */}}
                    >
                        <Text>{link.label}</Text>
                    </TouchableOpacity>
                </View>
            );
        })
    )}
    <ScrollView>
        {/* Actual screen content here. */}
    </ScrollView>
</View>

А затем под функцией рендеринга у меня есть кнопка такого типа для кнопки меню в левой части заголовка: 

screen.navigationOptions = ({ navigation }) => {
    const { params } = navigation.state;

    return {
        headerLeft: () => {
            return (
                <TouchableOpacity
                    onPress={params.toggleMenu}
                >
                    <Text>Menu</Text>
                </TouchableOpacity>
            );
        }
    };
};

The * Метод 1009 * - это просто метод, который переключает переменную состояния showMenu.

Что меня смущает, так это лучший способ структурировать приложение. Вот некоторые возможности:

1) Поставить меню, navigationOptions, et c. (т.е. все, что не является частью реального экрана) в компонент, а затем включите этот компонент на каждом экране и используйте props.children для фактического включения содержимого страницы. По сути, каждый экран будет иметь функцию рендеринга, подобную следующей: 

<ContainerComponent>
    {/* Actual screen content here. */}
</ContainerComponent>

Одна «проблема» этого метода, когда я попробовал его, заключается в том, что, поместив navigationOptions в ContainerComponent, я не сделал на самом деле кнопка меню слева от заголовка (я не знаю почему; возможно, это легко исправить).

2) Еще одна идея, которая у меня была, - сделать контейнер реальным экраном, а затем использовать этот экран, чтобы загрузить все другие экраны, имея переменную screen, которая передана ему, и некоторый оператор switch для условной загрузки содержимого экрана. Когда я это проверял, у меня не было проблемы navigationOptions (другими словами, я получил кнопку меню, и она сработала), но мне это кажется немного неаккуратным, мне кажется странным иметь по существу один экран во всем приложении затем загружаются все остальные экраны (хотя, возможно, это нормально; не знаю).

3) Третья идея, которая у меня была, заключалась в том, чтобы абстрагироваться только от меню и navigationOptions на отдельные компоненты, а затем импортируйте их на каждый экран, хотя это кажется немного повторяющимся.

Поэтому я ищу несколько советов: следует ли мне выбрать вариант № 1, № 2 или № 3, описанный выше, или есть еще больше логики c вариант № 4 я не думаю? Большое спасибо.

...