RE: Reusable Hydra components

Trying to reply to both Tom and Kev at the same time here..


> On Monday, January 26, 2015 10:21 AM, Tomasz Pluskiewicz wrote:
>> 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.

They are definitely not built that way currently.. I wouldn't be so pessimistic about the near future though. But probably it also depends on what you exactly mean by "generic clients". For me a generic Hydra SDK is also a generic client. You built a custom UI etc. on top of such a library.


>> 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.

I agree, we definitely shouldn't depend on it. But it would be nice to have something that is easy to plug into popular frameworks such as Angular.


On Monday, January 26, 2015 11:58 AM, Kev Kirkland wrote:
> I've been working on similar themes with the AngularJS client [4].

Cool! Shall we include this in the tools section on hydra-cg.com? If so, please file a PR [5]. It would also be nice if you could host a demo somewhere so that people can play with it directly.


> On Monday, January 26, 2015 10:21 AM, Tomasz Pluskiewicz wrote:
>> 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.

I haven't had much time to play with this yet but it seems to be an extremely versatile and powerful building block.


>> 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.
>> 
>> <app-router>
>>   <!-- matches static route and template inlined -->
>>    <app-route path="/example">
>>     <template>
>>     <p>Inline template FTW!</p>
>>   </template>
>>   </app-route>
>>     <!-- matches a pattern like '/word/number' and template lazy-loaded -->
>>     <app-route path="/^\/\w+\/\d+$/i" regex import="/pages/regex-page.html"></app-route>
>> </app-router>
>>
>> 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 <app-router /> so that
>> resource @type is used to choose the UI:
>> 
>> <ld-router>
>>   <ld-route type="http://schema.org/Person">
>>     <template>
>>       <!-- view inline -->
>>     </template>
>>   </ld-route>
>>   <ld-route type="http://schema.org/Book" import="/pages/Book"></ld-route>
>>   <!-- no [type] attribute could mean a fallback route -->
>>   <ld-route import="..."></ld-route>
>> </ld-router>

Yep. This is how you would typically do it in Linked Data Land :-) I wonder if something like "ld-renderer" wouldn't be a better name!?


>> 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 <ld-router />s on a page all
>> independently reacting to model changes.

Sounds like a sensible architecture to me.


>> 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
>> 
>> <hydra-form operation="http://example.com/Api#SubmitIssue"></hydra-form>

Hmmm... why wouldn't this simply be another ld-router/renderer? Supporting type hierarchies so that you can fall back to more generic renderers would be nice to have as well. Imagine you encounter an operation you don't support "natively". You could fall back on rendering a simple form just like the HydraConsole does. Also keep in mind that an entity/operation might have multiple types.


>> Of course one could iterate a processed model and output the <hydra-
>> form/>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.

So you are saying that, let's say CommentAction forms would only be shown for issues but not for blog post even though the Web API tells you it supports them for both?


On Monday, January 26, 2015 11:58 AM, Kev Kirkland wrote:
> Here's some links to GitHub which highlight some of the things you
> mentioned above.
> 
> I've used routing to have separate views for Forms, Collections and
> 'normal views'. These seem to be the three main view types in a Hydra
> client (judging by Marcus's implementation):

I just treat operations (forms) in a special way in the HydraConsole. But yeah, in Hydra these are probably the main three types.


> https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L378-403

Unless you changed the $routeProvider provider somewhere else, you switch based on the URL structure. That's very brittle and should be avoided. Using an entity's type as Tom outlines above is  the better approach IMO.


[...]

> I've got a couple of extensions in my client, over and above the
> standard. These don't stop it functioning like a normal Hydra client,
> but help the client look and behave like a standard web app. CSS
> styling can be applied to SupportedProperties, so the EntryPoint for
> my app looks like this (CSS is applied to the SupportedOperations to
> make them look like buttons):
> 
> https://www.dropbox.com/s/lf1iqyycefbcp9x/du_home.png?dl=0

Nice. I really like where this is going!


> There is also an option to add custom routes. In my application
> there's a couple of screens which really need a very tailored user
> experience which involve a lot of javascript interaction (I make data
> visualisation software). The easiest way I've found of including them
> is to have a Provider which lets you insert new Routes into the Hydra
> client (by specifying a SupportedClass/SupportedOperation
> combination):
> 
> https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L5-266

This probably couples the web app quite tightly to the API.. can you think of a way to avoid that?


> I've supported supplying drop down value choices through OSLC. I chose OSLC
> from the current Hydra Shapes options because it was easy to understand and
> implement (drop downs are visible in the Form screenshot above):
> https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L1931-1983
> https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L2415-2435

I really need to get up to speed on Shapes quickly..


> I haven't done a very good job of sharing my work with the group yet
> (sorry guys). The main issues are intense workload, and the fact that
> I can't Open Source my Hydra API just yet (I need to improve some
> security options). However I hope some of the screenshots above show
> that Hydra can be used to create a familiar web experience for the
> user.

Kudos! This is fantastic work! It's much appreciated that you took the time to write this down.


> PS: there's more features to the AngularJS Hydra client, like allowing
> parallel routes through an API, but I think I've already put too much
> info into this email so I'll save it for future discussions.

:-) Looking forward to hear more about this


Cheers,
Markus


>> [1]: https://github.com/erikringsmuth/app-router
>> [2]: https://github.com/facebook/flux
>> [3]: https://github.com/spoike/refluxjs
[4] https://github.com/dataunity/dataunity-hydra-client
[5] https://github.com/HydraCG/hydra-cg.com

Received on Monday, 26 January 2015 23:42:15 UTC