Как использовать хранилище Redux в одном компоненте без провайдера, но с подключением, потому что дети не нужны? - PullRequest
0 голосов
/ 19 декабря 2018

Я хочу использовать connect для оптимизации производительности и простоты использования с mapStateToProps.Я не думаю, что мне нужно передавать хранилище компоненту из <Provider> компонента-оболочки в какие-либо дочерние компоненты, потому что у меня нет дочерних компонентов, которые будут нуждаться в хранилище;Я хочу, чтобы хранилище было в одном компоненте, а именно "Header.jsx".В основном у меня нет других компонентов, кроме стандартных React и Material-UI, с которыми я бы хотел использовать хранилище.

Как мне поступить?Я пытался пропустить хранилище через defaultProps и использовал export default connect(mapStateToProps)(Header), но он все время говорит Uncaught Invariant Violation: Could not find "store" in the context of "Connect(Header)". Я прочитал, что контекст - это то, что используется для передачи реквизита по дереву с помощью провайдера.

Я новичокв Redux и React, так что, если я собираюсь пойти по этому пути совершенно неправильно, пожалуйста, дайте мне знать.

Если использование connect не может быть выполнено без провайдера, как я могу обернуть мой классизнутри?

Пример:

class componentName extends Component {
    constructor(props) {
      super(props);
    };
  render() {
      return (
          <h1>Hello World!</h1>
      );
    }
  }

export default connect(mapStateToProps)(<Provider store={storeName}>componentName</Provider>); // Maybe something like this?

1 Ответ

0 голосов
/ 19 декабря 2018

Я думаю, что вы просто не можете использовать connect() без <Provider/> - это зависит от того, какой шаблон следует.Если вы хотите использовать connect(), подключенный компонент должен быть потомком поставщика.Пример, который вы предложили включить <Provider/> в вызов connect(), не будет работать, так как:

a) Этот метод принимает класс компонента реагирования, а не уже созданный экземпляр элемента реакции, и b)Даже тогда он создает класс компонента, который после создания / монтирования проверяет контекст для хранилища, и это происходит как выше (в терминах DOM-иерархии) провайдера, который создает контекст, так и до его монтирования и имеетшанс создать этот контекст.

В чем причина, по которой вы против использования <Provider/>?Вы пытаетесь оптимизировать преждевременно, потому что думаете, что включение провайдера в корень вашего приложения окажет некоторое влияние на производительность?Если это так, я думаю, что вы можете обнаружить, что от его включения нет заметного влияния, или если вы его испытываете, я бы предположил, что проблема может быть в настройке ваших редукторов, а не просто в использовании <Provider/>.

Если вы абсолютно не используете редуктор, вы можете взять свой объект Store (возвращаемый из того места, куда вы звоните createStore()), и в componentDidMount() вашего единственного компонента, который нуждается в нем.Вы можете store.subscribe() прослушать изменения состояния, затем использовать store.getState(), чтобы получить эти изменения и загрузить их в состояние.Но в конце концов вы обнаружите, что вы просто переопределяете <Provider/>, хотя, возможно, без контекстной части.

TL; DR: звучит как XY проблема

...