Specify uri from data in pos-rich-link

[jg10-mastodon-social]

Closes #130
Also closes #132 with new storybook docs

• Acceptance criteria
  • If uri is missing, the component emits an event to receive the active resource.
  • If uri is missing and no resource is received (yet), nothing is displayed
  • If rel is present, then the corresponding link is followed and the resulting resource is displayed
  • If rev is present, then the corresponding link is followed and the resulting resource is displayed
  • (New) If there is not just one link, an error is shown
  • (New) Errors are emitted as pod-os:error events
• Otherwise a link to the active resource is displayed (e.g. within a pos-list)
• Tests have been written
  • all new code is covered by unit tests
  • the happy path of a new feature is covered by an end-to-end test
    • integration test with pos-resource
  • manual explorative tests have been performed
• all dependencies are updated to the latest patch version at minimum
• the CI pipeline passes
• documentation is up-to-date
  • TSDoc style comments on important functions, properties and events
  • stories for new PodOS elements have been added to storybook
  • Readme.md files of PodOS elements have been re-generated
  • architectural decisions are documented as an ADR
    • N/A
  • Changelogs are updated according to
    Keep a Changelog

[jg10-mastodon-social]

• Similar to pos-list, my reasoning is that the dashboard creator will want in-situ feedback on what is broken.
• I did think about throwing an error, but the user would have no way of knowing where the error is.
• The situation is a little different to pos-list because the error is caused by data and therefore might be experienced by the dashboard user as well. Ideas are welcome on other ways of elegantly handling the case where no or two many links are found.

[angelo-v]

Fine for now. We need a general concept for error handling. What comes to my mind is to have a) some error icon in the effected component that shows a summary as tooltip and b) have a global error log with more detais. Ideally one could click on the icon to jump to the error in the detailed log. All this would be a whole new task of course. What you could do is throw a pod-os:error event addtional, so that global handler can catch it. As you said it may as well be a data (runtime) error and not a build time error.

[angelo-v]

Fine for now. We need a general concept for error handling. What comes to my mind is to have a) some error icon in the effected component that shows a summary as tooltip and b) have a global error log with more detais. Ideally one could click on the icon to jump to the error in the detailed log. All this would be a whole new task of course. What you could do is throw a pod-os:error event addtional, so that global handler can catch it. As you said it may as well be a data (runtime) error and not a build time error.