2016-03-05 82 views
17

我有兴趣使用REST的HATEOAS原理来减少SPA应用程序中的业务逻辑。在React特定的环境中,我想知道是否有挑战使得这种做法不切实际,如果不是,那么遵循的策略是什么?REST(HATEOAS)和ReactJS

使用HATEOAS从UI删除业务逻辑的概念例子:

我只发现一个链接提示React/Flux is not compatible with a HATEOAS strategy,和其他地方没有有意义的讨论。 React/Flux应用程序真的不可行吗?这个帖子没有得到足够的关注。有没有人有最喜欢的或推荐的方法来取得成功(有或没有Flux或Redux)?

有人给出了一个相当详细的leveraging HATEOAS in the context of Angular的例子。我正在寻找类似React的东西。

就我个人而言,我在控制渲染哪些JSX组件的超媒体链接中描述了rel标记(conditional JSX)。这对于真实世界的React应用程序来说太天真了吗?也许有条件渲染的React组件太粗糙,不能用这种方式?

我假设超媒体链接是由HAL实现提供的,或者符合ATOM馈送约定(RFC4287)。

回答

1

在我吐出我最可能的错误/无关的答案之前,我只想告诉你,我刚才读了HATEOAS是什么。那里的警告,从我简要阅读的内容来看,HATEOAS似乎主要是关于API,告诉你如何通过向你提供一个链接返回与你刚才请求的资源相关的资源。

既然如此,我看不出一个理由,为什么你不能实施自己的行为动态URL的Ajax调用,将基于什么已经提供给你改变你的SPA的应用程序状态(即终极版),然而, ,你仍然需要有一些东西来代表你的应用程序所有部分的可视化状态。

// 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与React兼容& Flux,HATEOAS与Angular兼容,HATEOAS兼容JQuery甚至是vanilla JS。

HATEOAS不会对消费客户强加任何技术或实施要求。

HATEOAS其实只是一个概念,其可以设计你的API(您可以使用几个标准虽然喜欢HAL一个)

基本上,如果你可以调用的API,那么你可以实现一个HATEOAS客户端。

那么如何到达:

  • 第1步,你会怎么做,通常在反应的API调用?以同样的方式做。
  • 第2步,询问回应。
  • 第3步,基于响应,适当地在UI中进行响应。

例如,给定的顺序API /orders打电话,我得到如下回应:

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

从这个我可以推断,next是一个有效的关系,如果我去那个HREF我实际上会收到第二页的订单,所以在这种情况下,在UI中显示下一个按钮。

但是如果我收到了如下回应:

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

然后,我可以推断,next不是有效的关系,在我的UI我应该禁用或不显示下一个按钮。

没有魔力,它只是一种思维变化,一种新的范式。