2016-03-05 48 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我應該禁用或不顯示下一個按鈕。

沒有魔力,它只是一種思維變化,一種新的範式。