Redux: Промежуточное ПО сломано

Созданный на 6 июн. 2018 · 3Комментарии · Источник: reduxjs/redux

Ошибка

Нарушен важный паттерн промежуточного программного обеспечения. ИМО, большинство решений промежуточного программного обеспечения инкапсулируют свои собственные проблемы и не зависят от существования другого промежуточного программного обеспечения. Недавно было внесено изменение, чтобы сломать шаблон, который вызывал лишь незначительную проблему для определенного подмножества промежуточного программного обеспечения: тех, которые демонстрируют другое поведение при взаимодействии с другим промежуточным программным обеспечением во время пути инициализации applyMiddleware .

Вот некоторые примеры:

// Make state aware of browser media queries
const mediaQueries = (mediaQueries = defaultMediaQueries): Middleware => store => {
  if (typeof window !== 'undefined') {
    const reverseMap = createReverseMap(mediaQueries)

    const handleMediaChange = ({media, matches}: MediaChangedActionPayload) =>
      store.dispatch(mediaChanged(reverseMap[media], matches))

    const addMatchListener = (media: string) => {
      const match = window.matchMedia(media)
      match.addListener(handleMediaChange)
      return match.matches
    }

    values(mediaQueries).forEach(media => 
      handleMediaChange({media, matches: addMatchListener(media)}))
  }

  return next => (action: any) => next(action)
}

Другой пример:

// Make state aware of user adblockers
const adBlockDetection: Middleware = store => {
  if (typeof document !== 'undefined' && !document.getElementById('XMpADSwgbPUC')) {
    store.dispatch({type: AD_BLOCKER_DETECTED, payload: true})
  }
  return next => (action: any) => next(action)
}

Другой пример:

// Make state aware of socket connectivity and allow synchronisation of actions
const socketMiddleware = ({actionCreator, url, dataSync}) => store => {
  const socket = new WebSocket(url.replace(/(http|https)/, 'ws'))

  socket.addEventListener('message', ({data}) => {
    store.dispatch(JSON.parse(data))
  })

  socket.addEventListener('open', () => {
    socket.send(syncCreator(CONNECT_TO_DOMAIN, store.getState(), null, socket))
    store.dispatch(actionCreator({connected: true}))
  })

  socket.addEventListener('close', reason => {
    store.dispatch(actionCreator({connected: false}))
  })

  return next => action => {
    if (dataSync.hasOwnProperty(action.type)) {
      socket.send(syncCreator(action.type, store.getState(), action.payload, socket))
    }
    return next(action)
  }
}

Каково текущее поведение?

Следующая ошибка возникает во время applyMiddleware , что существенно нарушает работу приложения:

Uncaught Error: Dispatching while constructing your middleware is not allowed. Other middleware would not be applied to this dispatch

Рефакторинг вышеуказанного промежуточного программного обеспечения для закрытия функцией next => (как показано ниже) не имеет никакого значения (но, очевидно, также не является жизнеспособным решением).

// Still broken:
const mediaQueries = (mediaQueries = defaultMediaQueries): Middleware => store => next => {
  // ...middlewareCodeGoesHere...
  return (action: any) => next(action)
}

Какое ожидаемое поведение?

Не ломайте приложение. Зарегистрируйте предупреждение, если хотите, чтобы я мог его игнорировать, потому что в 100% моих случаев использования _ меня не волнует, сможет ли другое промежуточное ПО обработать эту отправку_. Я сильно подозреваю, что существует (или должно быть) очень мало законных причин, по которым любая отправка из контекста промежуточного программного обеспечения должна когда-либо взаимодействовать с любым другим промежуточным программным обеспечением в стеке, и если бы это было так, я бы подумал, что запах кода (это приведет к как минимум неявные зависимости порядка от промежуточного программного обеспечения).

Какие версии Redux, какой браузер и ОС подвержены этой проблеме?

Работал до этого пиара .

Источник

benoneal

Самый полезный комментарий

@markerikson Да, я видел эту проблему. Ключевая проблема, которую «решает» новый дизайн, заключается в следующем:

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

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

В текущем состоянии все существующее промежуточное программное обеспечение, включая стороннее промежуточное программное обеспечение, которое использует этот внутренний шаблон диспетчеризации (в основном все, что необходимо для создания экземпляров слушателей на чем-либо), не работает.

К сожалению, оставаться с 3.x для нас не вариант, поскольку мы используем Typescript, и только 4.x имеет правильную типизацию, и в целом мы не хотели бы зацикливаться на устаревшей версии основной части нашего логика приложения, даже если набор текста не был проблемой.

И, на мой взгляд, даже само сообщение об ошибке намекает на то, насколько оно на самом деле неважно: «проблема» в том, что Other middleware would not be applied to this dispatch , что на самом деле очень редко, и до сих пор было проблемой только для одной конкретной вариант использования, когда промежуточное ПО аналитики зависело от действий, отправляемых маршрутизатором.

Важно отметить, что «исправление» в redux прямо сейчас нарушает код, который он также должен был исправить . Это нарушает промежуточное программное обеспечение маршрутизатора. Теперь авторам этого промежуточного программного обеспечения (и всего другого аналогичного промежуточного программного обеспечения) необходимо выпустить совместимые с 4.x версии своих библиотек, которые теперь должны раскрывать детали реализации отправляемого вручную действия «Готово к хранению», которое потребитель должен реализовать.

Использование библиотек промежуточного программного обеспечения изменилось с простого импорта пакета и вставки в массив промежуточного программного обеспечения, чтобы теперь дополнительно требовать от авторов приложений найти какой-то хакерский способ отправки произвольного действия «готово к хранению» через некоторое время после завершения создания хранилища, но до того, как он будет использован. И теперь ВСЕ их промежуточное ПО должно, мы надеемся, придерживаться одного и того же типа действия, в противном случае авторам приложений придется отправлять несколько действий, «готовых к хранению», с разными типами, соответствующими любому API, реализованному авторами промежуточного ПО.

Это настоящий беспорядок, и в этом случае «лекарство» явно хуже, чем «болезнь».

benoneal 6 июн. 2018

👍4

Все 3 Комментарий

Процесс инициализации промежуточного программного обеспечения был явно изменен в 4.0 в связанном вами PR. Это было преднамеренное дизайнерское решение, призванное разрешить № 1240.

Я не уверен, что у меня есть немедленное предложение для вашего варианта использования, кроме как попытаться изменить логику вашего промежуточного программного обеспечения, чтобы дождаться какого-то вручную отправляемого действия «магазин готов». Вы также можете подумать о том, чтобы вместо этого остаться с 3.x.

markerikson 6 июн. 2018

@markerikson Да, я видел эту проблему. Ключевая проблема, которую «решает» новый дизайн, заключается в следующем:

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

Это настоящий беспорядок, и в этом случае «лекарство» явно хуже, чем «болезнь».

benoneal 6 июн. 2018

👍4

Все еще можно заставить работать каждый из ваших примеров. Просто отправьте после applyMiddleware. Возможно, в какой-то функции setupMiddleware(store) или в усилителе магазина.

Ошибка была намеренно введена в качестве альтернативы, чтобы позволить пользователям столкнуться с крайним случаем, имеющим очень неочевидную причину (если вы не знакомы с внутренним устройством applyMiddleware ). Redux придерживается позиции предотвращения ошибок пользователя, когда это возможно, так что это никуда не денется.

Альтернативой может быть какой-то обратный вызов, который промежуточное ПО может зарегистрировать как своего рода событие afterApply . Тогда вы гарантированно отправите товар в нужное время, после того, как все будет применено и в порядке. Было бы интересно подумать.