2016-03-05 5 views
17

Я заинтересован в использовании принципа REST HATEOAS для сокращения бизнес-логики в приложении SPA. В контексте, специфичном для Реагирования, я хотел бы знать, есть ли проблемы, которые делают это непрактичным, а если нет, то, что является хорошей стратегией для подражания?REST (HATEOAS) и ReactJS

Концептуальные примеры использования HATEOAS для удаления бизнес-логику от пользовательского интерфейса:

Я только нашел одну ссылку, которая предполагает React/Flux is not compatible with a HATEOAS strategy и не содержательную дискуссию в другом месте , Действительно ли это невозможно в приложении React/Flux? Это сообщение SO не привлекло достаточного внимания. У кого-нибудь есть любимый или рекомендуемый подход для достижения успеха (с Flux или Redux или без него)?

Кто-то дал довольно подробный пример leveraging HATEOAS in the context of Angular. Я ищу что-то подобное для React.

Лично я представляю метку rel в гиперссылках, которые контролируют, какие компоненты JSX визуализируются (conditional JSX). Это наивно для реального приложения React? Возможно, условно визуализированные компоненты React слишком грубые, чтобы их можно было использовать таким образом?

Я предполагаю, что ссылки гипермедиа обеспечены реализацией HAL или иным образом соответствуют соглашению о подаче ATOM (RFC4287).

ответ

1

Прежде чем я расскажу о своем наиболее вероятном неправильном/нерелевантном ответе, я просто хочу сообщить вам, что я только что прочитал, что такое HATEOAS. Это предупреждение, из того, что я кратко прочитал, HATEOAS, похоже, в основном касается API, рассказывающего вам, как перемещаться по самому себе, предоставляя ссылку на ресурсы, относящиеся к ресурсу, который вы только что запросили.

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

// our component file 
import React from 'react' 
import { makeAWithdrawl } from './actions' 

export default React.createClass({ 
    handleClick: function(e) { 
    e.preventDefault() 
    makeAWithdrawl(this.props.account.withdraw.href) 
    }, 
    render: function() { 
    <div className="account"> 
     <p className="account_number">{this.props.account.accountNumber}</p> 
     <p className="balance">{this.props.account.balance}</p> 
     <p><a href={this.props.account.deposit.href}>Deposit</a></p> 
     {this.props.account.withdraw ? <p><a onClick={this.handleClick}>Withdraw</a></p> : ''} 
    </div> 
    } 
}) 


// our actions file 
import store from 'store' // our redux store 
import axios from 'axios' // an ajax library 

export function makeAWithdrawl(url) { 
    return axios.post(url).then(function(resp){ 
    store.dispatch({ 
     type: 'MAKE_WITHDRAWL', 
     action: resp.data 
    }) // do your reducer stuff 
    }) 
} 

Ваше приложение по-прежнему знает, что он делает в SPA, однако, это позволит API, чтобы направлять вас туда, куда нужно позвонить, для каких-либо действий, которые необходимо выполнить. Надеюсь, поможет.

3

100% HATEOAS IS совместим с React & Flux, HATEOAS совместим с угловым, HATEOAS совместим с JQuery и даже с ванильным JS.

HATEOAS не налагает каких-либо технических или исполнительных требований на потребитель-клиент.

HATEOAS фактически просто понятие, к которому вы можете создать свой API (вы можете использовать один из нескольких стандартов, хотя, как HAL)

В принципе, если вы можете вызвать API, то вы можете реализовать клиент HATEOAS.

Так как добраться:

  • Шаг 1, как вы обычно делаете вызов API в Реагировать? Сделайте то же самое.
  • Шаг 2, опросить ответ.
  • Шаг 3, основываясь на ответе, соответствующим образом отвечает в пользовательском интерфейсе.

Например дан призыв к апи порядка /orders, я получаю следующий ответ:

{ 
    "_links": { 
     "self": { "href": "/orders" }, 
     "next": { "href": "/orders?page=2" } 
    } 
} 

Из этого я могу сделать вывод, что next является уважительное отношение, и что, если я пойду к этому HREF На самом деле я бы получил вторую страницу заказов, поэтому в этом случае в пользовательском интерфейсе отобразится следующая кнопка.

Однако, если я получил следующий ответ:

{ 
    "_links": { 
     "self": { "href": "/orders" }, 
    } 
} 

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

Нет никакой магии, это просто изменение мышления, новая парадигма.

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