Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposing new Types #89

Open
wertzui opened this issue Nov 6, 2021 · 3 comments
Open

Proposing new Types #89

wertzui opened this issue Nov 6, 2021 · 3 comments

Comments

@wertzui
Copy link

wertzui commented Nov 6, 2021

I'm missing some types and would like to get some feedback if they might be implemented in the spec.

  • bool: Simple boolean values. Either true or false. Together with required, the client would either render a normal checkbox, or a tri-state-checkbox.
  • datetime-offset: An ISO 8601 encoded string. This would be good to support users who use an API from different time zones. The default JavaScript Date-constructor automatically takes care of converting it into the browsers local timezone.
  • duration: An ISO 8601 encoded string. Must start with a 'P'. This is also supported in the upcoming ECMAScript Temporal spec, see https://tc39.es/proposal-temporal/docs/index.html
  • image: A valid image URL. Can also be a data URL, like data:image/png;base64,.... A client interface would render the image and a text input and / or a file upload.
  • file: A valid URL. Can also be a data URL. A client interface would render a download-button and a text input and / or a file upload. I've read support HTML5 types for inputs #36 and think, this is a valid solution.

For further aid, I would also like to propose a new field on properties:
mimeTypes which would be OPTIONAL and may contain an array of MIME-types. This would help clients to know which types for image and file are accepted.

@mamund
Copy link
Owner

mamund commented Nov 8, 2021

some interesting items on this list. would like to hear from others on which seems compelling additions.

as mentioned elsewhere here, the recommended approach is to create a working valid extension that is backward-compatible. then we can all see what it takes to implement it and test it against existing client applications to make sure the fallbacks are acceptable on all sides.

a side note: since HAL-FORMS might be used in UI settings as well as API settings, you should be sure that each extension has a viable solution for both use cases. we've tried to steer clear to writing specs that tell implementors what the UI should look-like and focus on how response consumers can recognize the feature and deal with it in both API and UI cases.

looking forward to seeing some of this in action.

@wertzui
Copy link
Author

wertzui commented Nov 8, 2021

Do you mean an implementation of the spec with the mentioned additions when you write: "a working valid extension that is backward-compatible"?

If yes, I'm currently working on one and will report back once it is finished.

@wertzui
Copy link
Author

wertzui commented Jul 3, 2023

I found the need for two more types:

  • percent: A number which should be displayed as percent by multiplying it with 100 and appending a percentage sign (%).
  • currency: A number that represents a currency value. Depending on the region for this currency, the client should format it appropriate and prepend or append (depending on the rules of the region) the currency symbol for the region.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants