I'm interested in using the [HATEOAS](https://spring.io/projects/spring-hateoas) principle of REST to reduce business logic in a SPA application. In a React-specific context, I'd like to know if there are challenges that make this impractical and, if not, what is a good strategy to follow?

Conceptual examples of using HATEOAS to remove business logic from the UI:

* [Delegating valid bank account actions to the REST service](http://restcookbook.com/Basics/hateoas/)
* [Delegating role-based access control to the REST service](http://www.codeproject.com/Articles/1081859/Don-t-Hate-The-HATEOAS)

I've only found one link that suggests [React/Flux is not compatible with a HATEOAS strategy](https://stackoverflow.com/questions/30404588/flux-how-to-make-an-action-wait-for-a-store?utm_content=buffer10376&utm_medium=social&utm_source=plus.google.com&utm_campaign=buffer), and no meaningful discussion elsewhere. Is it really not feasible in a React/Flux app? That SO post didn't get enough attention. Does anyone have a favorite or recommended approach for achieving success (with or without Flux or Redux)?

Someone gave a fairly detailed example of [leveraging HATEOAS in the context of Angular](https://stackoverflow.com/questions/28926483/single-page-application-and-restful-api). I'm looking for something similar for React.

Personally, I'm picturing the `rel` tag in hypermedia links controlling which JSX components are rendered ([conditional JSX](https://facebook.github.io/react/tips/if-else-in-JSX.html)). Is that naive for a real-world React app? Perhaps conditionally rendered React components are too coarse-grained to be used this way?

I am assuming that hypermedia links are provided by a [HAL](http://stateless.co/hal_specification.html) implementation, or otherwise conform to the ATOM feed convention ([RFC4287](https://www.rfc-editor.org/rfc/rfc4287)).