Блог

Существуют ли какие-либо официальные соглашения об именовании создателей действий и action.types

Просматривая учебные пособия, тема создателя действия и типа действия заключается в том, чтобы назвать тип действия практически один к одному с создателем действия.

В качестве примера предположим, что у нас есть приложение, извлекающее записи в блоге

В учебном пособии (top rated Udemy tutorial) использовалось следующее соглашение об именовании с asynchronous action creator:

 export const fetchPosts = () => async dispatch => {
    const response = await postsAPI.get('/posts');

    dispatch({type: 'FETCH_POSTS', payload: response.data});
};
 

Однако не было бы более разумным более точно называть объекты действия (для обозначения успеха или неудачи) для того, что отправляется. Вместо того, чтобы сопоставлять имя функции создателя действия с типом действия, в соответствии с:

 export const fetchPosts = () => async dispatch => {
    const response = await postsAPI.get('/posts');
    
    if (response.status === 200) {
       dispatch({type: 'FETCHED_POSTS', payload: response.data});
    } else {
        dispatch({type: 'FAILED_TO_FETCH_POSTS', payload: response});
    }
};
 

Да, официальные руководства по стилю предлагают писать типы действий как domain/eventname .

Это согласуется с несколькими другими моментами из руководства по стилю.

• рекомендация использовать redux toolkit вместо написания redux logic вручную, что позволяет создавать срезы, которые автоматически будут префиксами всех имен действий для среза. (Кроме того, вам больше не нужно будет вручную писать типы действий, создателей действий, операторы переключения или неизменяемую логику, поскольку RTK делает это за вас, см. modern redux)
• рекомендация упорядочить ваши файлы по функциям
• рекомендация моделировать действия как события
• рекомендация писать значимые названия действий

Добавляя к этому, я предпочитаю, чтобы мои действия были в прошлом, например, todos/added когда они описывают что-то, что произошло в приложении или что-то, что сделал пользователь, и чтобы они были обязательными, например todos/save , когда они описывают побочный эффект, который должен обрабатываться в промежуточном программном обеспечении (которое затем, возможно, выполнит запрос API и завершитвверх в todos/saved действии, чтобы фактически привести к изменениям в редукторе).

RTK неявно выполняет еще несколько действий, например createAsyncThunk , автоматически создаст три действия для каждого thunk: yourActionPrefix/pending , yourActionPrefix/fulfilled и yourActionPrefix/rejected .

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

например, с помощью префикса FETCH_POSTS вы можете иметь такие имена действий, как

• FETCH_POSTS_REQUEST
• FETCH_POSTS_SUCCESS
• FETCH_POSTS_FAILURE

 export const fetchPosts = () => async dispatch => {
    const response = await postsAPI.get('/posts');
    
    if (response.status === 200) {
       dispatch({type: 'FETCH_POSTS_SUCCESS', payload: response.data});
    } else {
        dispatch({type: 'FETCH_POSTS_FAILURE', payload: response});
    }
};
 

Еще один шаг, который вы могли бы предпринять, — это использовать объект constants, который определяет имена этих действий. Это связано с тем, что имена действий повторно используются в нескольких местах (создатели действий, редукторы, модульные тесты и т. Д.), А имена действий, определенные как константы, обеспечивают согласованность и читаемость.

 export const POSTS_API_ACTIONS = {
   FETCH_POSTS_REQUEST: 'FETCH_POSTS_REQUEST',
   FETCH_POSTS_SUCCESS: 'FETCH_POSTS_SUCCESS',
   FETCH_POSTS_FAILURE: 'FETCH_POSTS_FAILURE',
   DELETE_POSTS_REQUEST: 'DELETE_POSTS_REQUEST',
   ...
}

export const fetchPosts = () => async dispatch => {
    const response = await postsAPI.get('/posts');

    if (response.status === 200) {
       dispatch({type: POSTS_API_ACTIONS.FETCH_POSTS_SUCCESS, payload: response.data});
    } else {
        dispatch({type: POSTS_API_ACTIONS.FETCH_POSTS_FAILURE, payload: response});
    }
};