Ohara: Write the documentation for the rule of value validation generated by setting definition

[konekoya]

As the UI is being rewritten, we aim to provide a more comprehensive/complete form validation before users can submit their data to the backend. We've previously discussed this matter and came up with a doc, where all naming validation (pipeline name, worker name, ...etc) across our App is documented. But still, some form inputs are not included in the docs:

I'm just writing down some rules that I just came across as for today

Node API

• [x] hostname
• [ ] port
• [ ] username
• [ ] password

/cc @vitojeng @chia7712

[chia7712]

more documents?

[konekoya]

more documents?

Sorta like that. Just we need a place to know the validation rules for these user inputs/data.

[chia7712]

Sorta like that. Just we need a place to know the validation rules for these user inputs/data.

ok. Let me complete the documents for this issue :)

[chia7712]

I plan to make all json representations to depend on definitions. And build a page to display all components’ definitions.

Keeping all document up-to-date is too expensive when we are still developing. It seems to me the document should be revised with release.

The page to all components’ definitions has two advantages. First is that it is always up-to-date. And second it is the way that backend renders the objects.

Any feedback?

[konekoya]

I plan to make all json representations to depend on definitions.

So all the APIs will be using definitions in the future?

And build a page to display all components’ definitions.

This is going to be part of our docs? I think this is going to be really helpful, so these components will include validation rules as well?

Keeping all document up-to-date is too expensive when we are still developing. It seems to me the document should be revised with release.

Agreed. It's painful to do so :)

[chia7712]

This is going to be part of our docs? I think this is going to be really helpful,

Not really. this part is for UI developers. I don't think the validation is a immutable stuff when we are in programming ...

so these components will include validation rules as well?

yep. Not only UI follows the definitions but also backend checks the input values according to definitions.

[konekoya]

Not really. this part is for UI developers. I don't think the validation is a immutable stuff when we are in programming ...

I can see that. Was wondering how you would you go about it 😅

So, to clarify, everything will be rendered with definitions in the future, right?

[konekoya]

pinging @oharastream/frontend thoughts, feedback, and thumbs up?

[chia7712]

So, to clarify, everything will be rendered with definitions in the future, right?

yep. we all count on definitions rather than hard code.

for UI developer, the page of showing definitions helps you to observer the latest rules of data (json representation) validation.

for backend developer, the page is able to show latest definitions automatically. It lets backend developers catch the breath. Of course, we still have to update the docs before release.

[chia7712]

中文化一下

前後端的步調有所差異，而現在APIs牽扯的邏輯繁雜，要在開發過程(每個commit)同時保持相容性和文檔更新的工作量太大也不實際。

definitions有的好處是框出一個"可以變化"的範圍，例如就算commit過程中要變更APIs也只會在definition所定義的範圍裏面，而不會天差地遠。

對於前端來說，所有物件的definitions可以讓前端了解現在該物件的APIs資料定義和檢查邏輯。

對於後端來說，所有物件的定義和檢查邏輯都根據definitions。換言之definitions怎麼說後端就怎麼檢查，連動且不脫鉤。

[saivirtue]

Will this issue merge to 0.9 before today noon?
If not, please help me to move this issue to 0.10 :)