React Native сложный шаблон условного рендеринга - PullRequest
0 голосов
/ 19 октября 2019

В моем приложении есть маршрут, который может значительно различаться в зависимости от состояния, в которое оно было передано. Например, скажем, у нас есть 3 состояния: состояние1, состояние2 и состояние3. В каждом из этих состояний отображаются некоторые функциональные компоненты (например, верхний и нижний колонтитулы, однако их содержимое может различаться). У меня также есть другие компоненты, которые должны отображаться только в состоянии1, другие компоненты только в состоянии2 и т. Д.

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

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

Вариант первый: Первый шаблон I 'мы думали о том, чтобы создать разные представления для каждого государства. Эти специфичные для состояния представления будут включать только те компоненты, которые я хочу визуализировать для этого конкретного состояния. Затем я мог бы обернуть все представления в компонент более высокого порядка, который будет отображать правильное представление на основе переданного состояния. Я чувствую, что эта опция будет масштабируемой / поддерживаемой, однако я думаю, что это также приведет к большому количеству дублирующегося кода. Например:

switch (currentState) {
  case "state1":
    return <State1Component />
  case "state2":
    return <State2Component />
  ...
}

И State1Component будет выглядеть примерно так:

class State1Component extends Component {
  state = {
    headerText: "lorem ipsum",
    componentText: "..."
    ...
  }

  render() {
    return (
      <View>
        <Header headerText={headerText} />
        ...
      </View>
    )
  }
}

Второй вариант: Другой вариант, который я подумал, будет создать один,высокоуровневый объект, который содержит всю информацию, необходимую для каждого нижестоящего компонента в каждом отдельном состоянии. Этот объект будет содержаться в основном маршруте. Например,

stateObject = {
  state1: {
    header: {
      renderComponent: true,
      text: "Welcome to state1"
    },
    component1: {
      renderComponent: false,
    },
    ...
  },
  state2: {
  ...
  }
  ...
}

Теперь я мог бы легко извлекать всю необходимую информацию в зависимости от переданного состояния и передавать информацию через реквизит. Я чувствую, что эта опция будет полезна для минимизации дублирующегося кода, однако я думаю, что в результате компонент маршрута будет занят / сложен.

1 Ответ

3 голосов
/ 19 октября 2019

Я сделал приложение с похожими обстоятельствами, во многих штатах, слишком много хлопот. Так что то, что вы предложили во втором подходе, лучше. Всегда хорошо иметь глобальные компоненты и выполнять рендеринг в соответствии с желаемым состоянием. Предположим, у вас есть 2 состояния и вы хотите отобразить 2 разных компонента.

  1. Создайте два файла X.js и Y.js, которые вы хотите визуализировать в state1 и state2 соответственно.

2. Создайте класс Home.js, в котором вы хранитеотслеживать состояние, импортировать в него два вышеупомянутых компонента и выполнять рендеринг в соответствии с условием:

import X from 'X.js'
import Y from 'Y.js'

class Home extends Component {

constructor(props){
super(props)
this.state={
state1:false,
state2:true
}
}


render(){

return(
<View>
{this.state.state1?<X />:<View />}
{this.state.state2?<Y />:<View />}
</View>

)
}

}

Это не только повышает удобочитаемость кода, но вы фактически следуете структуре фрактальных папок, разбивая каждыйкомпонент.

Не стесняйтесь задавать любые сомнения.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...