Соглашение об именах событий в сокращении js

Ответ 1

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

• Наиболее распространенным соглашением является сохранить типы действий ( "типы событий" ) в CONSTANT_CASE.

  Это позволяет избежать ошибок орфографии, когда действие имеет тип my_type, но редуктор ожидает тип my-type или my_type.

• Другое очень распространенное соглашение - сохранить типы действий в отдельном файле как константы, например. var MY_ACTION_TYPE = 'MY_ACTION_TYPE';, и использовать их оттуда.

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

• Не совсем то же самое, но imho очень полезно, соглашение - это область действия для проекта и домена. Этот подход был популяризирован Эриком Расмуссеном в своем предложении "Утки" , в котором указывается, что типы действий должны быть в этой форме: var MY_ACTION_TYPE = 'appname/domain/MY_ACTIONTYPE'.

  Это позволяет избежать случая двух констант действия, имеющих одинаковое значение. Например. представьте, что у вас есть область администратора и область, обращенная к пользователю, и у обоих есть формы, отправляющие тип действия 'CHANGE_USERNAME'. Это приведет к тому, что два редуктора заберут одно и то же действие, где не следует выбирать другого. Это может произойти в случае аварии, и очень раздражает отслеживать. Префикс их с именем приложения и домена позволяет избежать этой проблемы: 'appname/admin/CHANGE_USERNAME' отличается от 'appname/user/CHANGE_USERNAME'!

Что все конвенции, которые я знаю и использую, но я уверен, что у кого-то еще больше - что вы использовали и нашли полезным в своих проектах?

Ответ 2

Существуют также некоторые соглашения об именах асинхронных типов действий. Если у вас есть набор действий для представления вызова api для получения пользователя, вы можете разбить их на что-то вроде:

• FETCH_USER_REQUEST - когда вы сначала отправляете вызов api
• FETCH_USER_SUCCESS - когда выполняется api-вызов и успешно возвращаются данные
• FETCH_USER_FAIL - если ошибка api не удалась и ответила с ошибкой,
• FETCH_USER_COMPLETE - иногда используется в конце вызова независимо от состояния

Ответ 3

Существует новый шаблон, который обращается к этому, redux-auto.

Взятие идей композиции редуктора еще на один шаг. Где вместо файла, представляющего ваш редуктор, и создания отдельных действий.

redux-auto подходит для того, чтобы иметь папки с отдельными JS файлами, представляющие каждое действие/преобразование в состоянии и динамически отображая это как функции

Пример

└── store/
    ├──user/
    │  └── index.js
    │  └── changeName.js
    └──posts/
       └── index.js
       └── delete.js

Теперь из любого приложения в вашем приложении вы можете написать

import actions from 'redux-auto'
...
actions.user.changeName({name:"bob"})

магазин/пользователь/changeName.js

export default function (user, payload) {
    return Object.assign({},user,{ name : payload.name });
}

Вот!!

Если вы хотите прослушать действия redux в сторонних редукторах. Вы можете использовать как функцию контроля качества для функции.

action.type == actions.user.changeName // "USER/CHANGENAME"

Для чего-то более продвинутого вы даже можете увидеть, принадлежит ли действие конкретному редуктору

// Returns true if it an action specifically for user
if(action.type in actions.user) 

Более подробную информацию можно найти на странице