W3C home > Mailing lists > Public > public-hydra@w3.org > January 2015

Reusable Hydra components

From: Tomasz Pluskiewicz <tomasz@t-code.pl>
Date: Mon, 26 Jan 2015 09:21:04 +0000
Message-ID: <393906b9c3a5348bf5d9ffa16fad9ba0@rainloop.t-code.pl>
To: "Dumont Cedric" <cedric.dumont@outlook.com>
Cc: public-hydra@w3.org
Hi Cedric, Hi everyone

 I'm currently reiterating my ideas for consuming Hydra APIs. Most discussions here seem to revolve around building generic clients. However this is not how most web apps are built, nor will they be in the nearest future. There was also some discussion about implementing a client in AngularJs, though I don't think that we should depend on any such general-purpose framework.

 Lately I've been experimenting with web components, the upcoming HTML5 set of features and it seems to fit nice. Currently only Chrome and Opera support that natively but other modern browsers can be polyfilled successfully. Native support is just a matter of time anyway.

 And so there is that custom component called app-router [1]. It works by defining in a declarative way what UI should render when a particular route is matched.
  
   
   
   Inline template FTW!
  
  
   
   
 I find this very clean. Unfortunately path-based routing is irrelevant for REST state transitions, where the returned model determines the UI state. I've looked around AngularJs and generally and surprisingly I've found little about building such browser apps. Thus I've successfully experimented with adapting the  so that resource @type is used to choose the UI:
   
    
    
    
   
   
 
   
 Currently I've adopted the flux pattern [2] implementation Reflux [3] to decouple the UI from the actual content navigation by using events. This way there can be multiple s on a page all independently reacting to model changes.

 As far as Hydra is concerned I envision similar reusable components for rendering links and operation forms based on the model and ApiDocumentation. For example a form-element could be as simple as
 Of course one could iterate a processed model and output the s programmatically for each documented operation but I see great value in such declarative way of building the UI from self-contained blocks. After all most apps don't expose generic show-all-in-whatever-order UIs but rather have carefully crafted design to enhance usability. 

 @Cedric, have you actually started working on your AngularJs API? Or maybe you would be interested in my proposed approach? 

 @All, what do you think about the above ideas?

 Thanks,
 Tom

 [1]: https://github.com/erikringsmuth/app-router
 [2]: https://github.com/facebook/flux
 [3]: https://github.com/spoike/refluxjs
Received on Monday, 26 January 2015 09:21:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 26 January 2015 09:21:52 UTC