Логика Common Component решается с помощью Composition вместо наследования в React-Native

Question

Мы разрабатываем приложение с нативной реакцией с помощью redux-saga.

В тот момент, когда вы ищете наследование в реакции, вы всегда обнаруживаете: не делайте этого, используйте композицию! с примерами повторного использования макета с композицией.

Проблема сейчас в том, что речь идет не о компоновке, а о общей логике конструктора. Я дам вам конкретный случай:

• LoggedOutComponent
• LoggedInComponent

Если пользователь переходит к Компоненту, расширяющему LoggedOutComponent, первым распространенным шагом является проверка, вошел ли пользователь в систему. Если он есть, мы переходим к начальному экрану части LoggedIn и наоборот для LoggedInComponent.

Есть ли лучший способ достичь этого без использования наследования. Или это хороший пример, где наследование - это путь? Я не хочу писать одинаковую логику в каждом компоненте.

Answer 1

Не совсем уверен, что я вас понял, но, как я вижу, у вас есть два варианта:

1. Напишите метод "navigateLoggedIn (route)", в котором вы будете проверять, вошел ли пользователь в систему или нет. если он НЕ вошел в систему, этот метод перейдет к маршруту экрана входа в систему. если он вошел в систему, этот метод будет переходить к заданному параметру маршрута. убедитесь, что если у вас есть поток выхода из системы где-то в приложении, перейдите к маршруту экрана входа в конце этого потока.

2. второй вариант - создать класс компонента-оболочки, называемый, например, ForceLoggedIn. этот класс в своем методе рендеринга проверит, вошел ли пользователь в систему. Если он есть, покажите содержимое this.props.children, в противном случае покажите содержимое страницы входа. Затем вы можете использовать этот компонент-оболочку в своем коде с:

Answer 2

мне кажется, что это неправильный путь, если вы пытаетесь перемещаться из конструктора компонентов. Можете ли вы подробнее рассказать о том, чего именно вы пытаетесь достичь?