✨ feat: json and bytes field support in options

[mhkarimi1383]

Hi

Some times there is a need to have results as bytes (that is builtin supported by click.STRING)
and also there is a need of decoding entire value as an json object (useful when some params are too dynamic or getting that option in a prompt). I wanted to also add pydantic support (for both single option as json and all of the options in a single model) there and also use orjson (by checking if that's installed as an optional dependency), If that's Ok.

[github-actions]

📝 Docs preview for commit 137e1bc at: https://5f9b3d47.typertiangolo.pages.dev

[github-actions]

📝 Docs preview for commit 0f5a1b3 at: https://ae7752e5.typertiangolo.pages.dev

[github-actions]

📝 Docs preview for commit 432a48c at: https://b02f882e.typertiangolo.pages.dev

[github-actions]

📝 Docs preview for commit 31e7623 at: https://6e9177ee.typertiangolo.pages.dev

Modified Pages

• https://6e9177ee.typertiangolo.pages.dev/tutorial/parameter-types/json/

[github-actions]

📝 Docs preview for commit f83e798 at: https://4dcf841b.typertiangolo.pages.dev

Modified Pages

• https://4dcf841b.typertiangolo.pages.dev/tutorial/parameter-types/json/

[mhkarimi1383]

@svlandeg it's ok to ignore coverage on newly created class?

[svlandeg]

No, in general we really need all the code in the main modules to be fully tested 🙏

[github-actions]

📝 Docs preview for commit fdb7bb4 at: https://4a6543f8.typertiangolo.pages.dev

Modified Pages

• https://4a6543f8.typertiangolo.pages.dev/tutorial/parameter-types/json/

[github-actions]

📝 Docs preview for commit 114b761 at: https://10931053.typertiangolo.pages.dev

Modified Pages

• https://10931053.typertiangolo.pages.dev/tutorial/parameter-types/json/

[mhkarimi1383]

@svlandeg

I have added tests for newly created class

coverage is 100% again :)

[mhkarimi1383]

If changes are Ok so far I can work on Pydantic support, Or move Pydantic support in another PR?

@svlandeg

[svlandeg]

HI @mhkarimi1383!

We haven't yet been able to review this PR in detail. When we do, we'll update here. No need to ping individual maintainers in the meantime 😉

In terms of adding more functionality, it's always best to open separate PRs for distinct functionality. It makes the review process much easier if one PR deals with one "atomic" change.

Do have a look at existing PRs - if I recall correctly there's already a few PRs open with proposals for Pydantic support.