Как обновить магазин Redux после возврата запроса Apollo GraphQL
Я получаю список данных с graphql HOC предоставлен реакцией Аполлона. Например:
const fetchList = graphql(
dataListQuery, {
options: ({ listId }) => ({
variables: {
listId,
},
}),
props: ({ data: { loading, dataList } }) => {
return {
loading,
list: dataList,
};
}
}
);
Я отображаю список в группе управляемых переключателей, и мне нужно выбрать один из элементов по умолчанию. id выбранного элемента хранится в магазине Redux.
Итак, вопрос в том, как обновить хранилище Redux (т.е. установить selectedItem) после того, как запрос успешно возвращается?
Несколько вариантов, которые пришли мне в голову:
Опция 1
Должен ли я слушать APOLLO_QUERY_RESULT действия в моем редуксе редуктора? Но это немного неловко, потому что тогда мне нужно было бы послушать APOLLO_QUERY_RESULT а также APOLLO_QUERY_RESULT_CLIENT если запрос уже выполнялся раньше. А также operationName опора присутствует только в APOLLO_QUERY_RESULT действие, а не в APOLLO_QUERY_RESULT_CLIENT действие. Так что мне нужно было бы анализировать каждый APOLLO_QUERY_RESULT_CLIENT действие, чтобы знать, откуда это пришло. Разве нет простого и понятного способа определить действия в результате запроса?
Вариант 2
Должен ли я отправить отдельное действие, как SELECT_LIST_ITEM в componentWillReceiveProps например (используя перекомпоновку):
const enhance = compose(
connect(
function mapStateToProps(state) {
return {
selectedItem: getSelectedItem(state),
};
}, {
selectItem, // action creator
}
),
graphql(
dataListQuery, {
options: ({ listId }) => ({
variables: {
listId,
},
}),
props: ({ data: { loading, dataList } }) => ({
loading,
items: dataList,
}),
}
),
lifecycle({
componentWillReceiveProps(nextProps) {
const {
loading,
items,
selectedItem,
selectItem,
} = nextProps;
if (!selectedItem && !loading && items && items.length) {
selectItem(items[items.length - 1].id);
}
}
})
);
Вариант 3
Должен ли я использовать клиент Apollo напрямую, вводя его с withApollo а затем отправить мое действие с client.query(...).then(result => { /* some logic */ selectItem(...)}), Но тогда я потерял бы все преимущества интеграции реактивного-аполлона, так что на самом деле это не вариант.
Вариант 4
Стоит ли вообще обновлять хранилище Redux после возврата запроса? Потому что я мог бы просто реализовать селектор, который возвращает selectedItem если он установлен, и если нет, он пытается получить его, просматривая apollo часть магазина.
Ни один из моих вариантов не удовлетворяет меня. Итак, как бы я сделал это правильно?
5 ответов
Я бы сделал что-то похожее на Вариант 2, но поместил бы методы жизненного цикла в реальный Компонент. Таким образом, бизнес-логика в жизненном цикле будет отделена от реквизита, унаследованного от контейнера.
Так что-то вроде этого:
class yourComponent extends Component{
componentWillReceiveProps(nextProps) {
const {
loading,
items,
selectedItem,
selectItem,
} = nextProps;
if (!selectedItem && !loading && items && items.length) {
selectItem(items[items.length - 1].id);
}
}
render(){...}
}
// Connect redux and graphQL to the Component
const yourComponentWithGraphQL = graphql(...)(yourComponent);
export default connect(mapStateToProps, mapDispatchToProps)(yourComponentWithGraphQL)
Я бы прослушал изменения в componentDidUpdate и, когда они произошли, отправил действие, которое установит selectedItem в хранилище Redux
componentDidUpdate(prevProps, prevState) {
if (this.props.data !== prevProps.data) {
dispatch some action that set whatever you need to set
}
}
Должно быть достаточно использовать "реквизит", например:
const enhance = compose(
connect(
function mapStateToProps(state) {
return {
selectedItem: getSelectedItem(state),
};
}, {
selectItem, // action creator
}
),
graphql(
dataListQuery, {
options: ({ listId }) => ({
variables: {
listId,
},
}),
props: ({ data: { loading, dataList } }) => {
if (!loading && dataList && dataList.length) {
selectItem(dataList[dataList.length - 1].id);
}
return {
loading,
items: dataList,
}
},
}
),
);
В прошлом я сталкивался с подобной проблемой и выбирал что-то похожее на вариант 2. Если у вас есть как собственное хранилище с избыточностью, так и собственное внутреннее хранилище apollo, синхронизация состояний между ними становится проблемой.
Я бы посоветовал избавиться от собственного магазина редуксов, если вы используете apollo. Если вы используете сервер gql и несколько остальных серверов одновременно, разделите данные логически и физически.
Как только вы решите использовать apollo в качестве "источника данных", диспетчеризация - это просто мутация, а получение состояния - просто запрос. Вы также можете фильтровать, сортировать и т. Д. С запросами
На мой взгляд, лучший подход - это создать слегка модифицированную и компонуемую версию hoc варианта 2, которая будет использоваться аналогично graphql Hoc. Вот пример использования, который приходит на ум:
export default compose(
connect(
state => ({ /* ... */ }),
dispatch => ({
someReduxAction: (payload) => dispatch({ /* ... */ }),
anotherReduxAction: (payload) => dispatch({ /* ... */ }),
}),
),
graphqlWithDone(someQuery, {
name: 'someQuery',
options: props => ({ /* ... */ }),
props: props => ({ /* ... */ }),
makeDone: props => dataFromQuery => props.someReduxAction(dataFromQuery)
}),
graphqlWithDone(anotherQuery, {
name: 'anotherQuery',
options: props => ({ /* ... */ }),
props: props => ({ /* ... */ }),
makeDone: props => dataFromQuery => props.anotherReduxAction(dataFromQuery)
})
)(SomeComponent)
И самая простая реализация будет выглядеть примерно так:
const graphqlWithDone = (query, queryConfig) => (Wrapped) => {
const enhance = graphql(query, {
...queryConfig,
props: (props) => ({
queryData: { ...( props[queryConfig.name] || props.data ) },
queryProps: queryConfig.props(props),
})
})
class GraphQLWithDone extends Component {
state = {
isDataHandled: false
}
get wrappedProps () {
const resultProps = { ...this.props };
delete resultProps.queryData;
delete resultProps.queryProps;
return { ...resultProps, ...this.props.queryProps }
}
get shouldHandleLoadedData () {
return (
!this.props.queryData.error &&
!this.props.queryData.loading &&
!this.state.isDataHandled
)
}
componentDidUpdate() {
this.shouldHandleLoadedData &&
this.handleLoadedData(this.props.queryData);
}
handleLoadedData = (data) => {
if (!makeDone || !isFunction(makeDone)) return;
const done = makeDone(this.wrappedProps)
this.setState({ isDataHandled: true }, () => { done(data) })
}
render() {
return <Wrapped {...this.wrappedProps} />
}
}
return enhance(GraphQLWithDone)
}
Даже при том, что я не пробовал этот псевдокод, у него нет тестов и даже не закончен, идея этого довольно проста и легка для понимания. Надеюсь, это кому-нибудь поможет
Я использую hoc, который является немного лучшей версией варианта 2. Я использую withLoader Hoc в конце compose.
const enhance = compose(
connect(),
graphql(dataListQuery, {
options: ({ listId }) => ({
variables: {
listId,
},
}),
props: ({ data: { loading, dataList } }) => ({
isLoading:loading,
isData:!!dataList,
dataList
}),
}
),
withLoader
)(Component)
WithLoader hoc компонент рендеринга, основанный на двух свойствах isData и isLoading. Если isData истина, тогда это рендерит Wrapped Component, иначе рендеринг загрузчик.
function withLoader(WrappedComponent) {
class comp extends React.PureComponent {
render(){
return this.props.isData?<WrappedComponent {...this.props}/>:<Loading/>
}
}
}
Я установил первый элемент dataList в методе componentWillMount Компонента. Компонент не монтируется, пока мы не получим dataList, который обеспечивается withLoader hoc.