Add only category and kind #14
Conversation
src/backend/category.ml
Outdated
| let categories = Types.Category.all in | ||
| let res : Types.CategoryList.t = { categories; } in | ||
| Ok res | ||
| ) |
There was a problem hiding this comment.
I'm not sure what's the use of an API call to return the list of categories: the type of categories already defines that list, so it seems a bit redundant and wasteful to have an API call to return something that is static and known at compile-time for both the backend and frontend.
There was a problem hiding this comment.
Since EventIdList was implemented (which also feels redundant to me) by you, I thought it was mandatory to create a "List" type for all things that could be recuperated as a list.
It's true that is it known by backend at compile time, but I'm not sure for frontend since frontend only knows of stuff from the dynamically generated openapi spec. Can the frontend be in sync to the list of possible division categories without an API? For me, we will need the lists when we want to show forms for creating events and competitions.
I feel like we should give it some ways to access the list of possible values for all concepts defined in doc/concepts.md. Do you have an alternative ways to transmit the list of possible values to the frontend?
There was a problem hiding this comment.
The frontend will *have to statically know about the different categories, if onyl to properly print and display them for each competition. Said otherwise, if at any point the frontend does not statically know about all of the categories, then it is a bug. I agree that it means additional work to ensure that the frontend and backend are in sync, but it's unavoidable since the two have separate code.
src/backend/kind.ml
Outdated
| let kinds = Types.Kind.all in | ||
| let res : Types.KindList.t = { kinds; } in | ||
| Ok res | ||
| ) |
There was a problem hiding this comment.
same remark as for category lists (also, you forgot to rename the list to kind_list).
Co-authored-by: Guillaume Bury <[email protected]>
It's mainly to get used to modify code. But I believe the openapi doc is dynamically generated by the ocaml code. If we don't represent them, we won't be able to access them for forms! |
|
I'm inclined to close this PR: in practice we will hve to keep the frontend and backend in sync so they can properly interact and work. Just like the backend, the frontend needs to know about:
So an API to return the list of kinds is superfluous since the frontend code needs this list hardcoded. |
|
@Gbury all changes you asked for were deleted, please accept this MR to improve doc |
No description provided.