Re: Reusable Hydra components

Markus, thank you for replying. Comments inline

January 27 2015 12:42 AM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote: 
> 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.
>

Indeed Hydra SDK is a generic client in that sense, though it is intended to be built upon. What I meant was a client like the console which should work with any Hydra API and display some generic UI. In fact both generic client and custom clients would likely use a form of Hydra SDK.

>>> 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!?
>

Yes, I don't like the term routing anyway in this context. Renderer is a bit better but not ideal IMO. The required word is for a component that decides what view to render based on an input. I guess that "render" is a logical idea but I think that "choose" is the predicate here. Maybe ld-view-selector? Descriptive...

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

This is something to think about, thanks.

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

No, but I'd like to have the option. The problem is that a UI design may position various operations available for a resource in different places on the page. In such case simply rendering them next to each other could be not perfect.

Received on Tuesday, 27 January 2015 11:22:36 UTC