Есть ли в настоящее время консенсус, по которому дизайн api подходит для приложения реакции/сокращения?

Я создаю одностраничное приложение с реакцией и сокращением. Для этого, конечно, нужен бэкэнд. Теперь мы смотрим, какая архитектура api будет лучше, но я не мог найти никакого консенсуса относительно того, какая архитектура api лучше всего подходит для приложения реакции/сокращения.Есть ли в настоящее время консенсус, по которому дизайн api подходит для приложения реакции/сокращения?

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

Итак, мой вопрос: какая архитектура api используется в большинстве случаев для приложения response/redux в этот момент времени?

источник

2016-09-28 vkjb38sjhbv98h4jgvx98hah3fef

Из нашего опыта, лучше не делать API «подходящим» реагировать/сокращать и наоборот. Просто используйте thunk-action-creators и обрабатывайте вызовы API в любой форме или форме.

Вот надуманный пример:

export function getUserById (userId) { 
    return async dispatch => { 
     dispatch({ type: 'REQUEST_USER_BY_ID', payload: userId }) 
     try { 
      const user = await api.get(`/users/${userId}`) 
      ga('send', 'event', 'user', 'profile', 'view') 

      dispatch({ 
       type: 'LOAD_USER', 
       payload: user 
      }) 

      dispatch({ 
       type: 'NOTIFY_SUCCESS', 
       payload: `Loaded ${user.firstname} ${user.lastname}!` 
      }) 
     } 
     catch (err) { 
      dispatch({ 
       type: 'NOTIFY_ERROR', 
       payload: `Failed to load user: ${err.message}`, 
      }) 
     } 
    } 
}

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

Мы пробовали множество подходов, таких как «сокращение по проводам» и реле/apollos «связывать компонент с запросом». Этот застрял как самый гибкий и простой для понимания и рефакторинга.

источник

2016-09-28 12:57:07 igl

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

источник

2016-09-28 08:36:59

Я ожидал, что ответ, и, конечно, я пытаюсь сделать это. Но есть ценность в понимании того, какая архитектура пользуется наибольшим использованием. Это хорошая отправная точка, и обычно она пользуется наибольшим использованием, потому что она делает что-то правильно. – vkjb38sjhbv98h4jgvx98hah3fef

Поняв, перейдите по этой ссылке, чтобы просмотреть некоторые диаграммы https://github.com/reactjs/redux/issues/653, view -> action -> dispatch -> reducer -> изменение состояния, это то, что сокращение делает для наших государственного управления. Я также рекомендовал бы проверить структуру файлов Ducks для сокращения здесь: https://medium.com/@scbarrus/the-ducks-file-structure-for-redux-d63c41b7035c#.q8ukk13qg –

Спасибо за ответ, но это не так. что я имел ввиду. Я имел в виду, что покоящая архитектура json api (или стандартная, например odata или jsonapi.org) чаще всего используется в сочетании с приложением response/redux. – vkjb38sjhbv98h4jgvx98hah3fef

Трудно найти авторитетную информацию или рекомендации по этому вопросу, но трудно утверждать, что если вы создаете API специально для одного приложения flux/redux и сохраняете данные в нормализованной форме в базе данных, это довольно глупо де-нормализовать его в конечной точке API только для нормализации его прямо после вашего клиента (с использованием normalizr) ... В этом случае просто оставьте данные нормализованными и передайте их по проводу вашему клиенту, как это.

конкретно вы бы что-то вроде этого:

GET /meetings

{ 
    "result": ["1", "2"], 
    "entities": { 
     "meetings": { 
      "1": { "id": 1, "date": "2016-01-01", "attendees": [1, 2, 3] }, 
      "2": { "id": 2, "date": "2016-01-02", "attendees": [2, 3, 4] } 
     }, 
     "users": { 
      "1": { "id": 1, "name": "User 1" }, 
      "2": { "id": 1, "name": "User 2" }, 
      "3": { "id": 1, "name": "User 3" }, 
      "4": { "id": 1, "name": "User 4" } 
     } 
    } 
}

Учитывая, что каждый из этих объектов соответствуют собственности на вашем состоянии, такой ответ является trivial to merge into your store в действии редуктора, используя что-то как Lodash merge:

return _.merge({}, state, action.entities);

Если у вас есть несколько потребителей, вы можете выбрать Ф.О. r a normalize=true параметр запроса. Вы также можете объединить это с каким-то параметром запроса expand|include=entities,to,include.

Наконец, обратите внимание, что спецификация API JSON doesn't play nicely с нормализованной структурой хранилищ флюсов/редуктов.

Дальнейшее чтение:

источник

2017-10-10 12:37:59

Есть ли в настоящее время консенсус, по которому дизайн api подходит для приложения реакции/сокращения?

ответ

Смежные вопросы