-
Notifications
You must be signed in to change notification settings - Fork 17
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
fix(spec): name conflict between method and params #121
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🚀
*/ | ||
function batchDictionaryEntries({ | ||
dictionaryName, | ||
batchDictionaryEntries, | ||
batchDictionaryEntriesParams, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be too late for this discussion, but I'm wondering if we cannot have flattened parameters like:
dictionaryName: 'compounds' | 'plurals' | 'stopwords';
clearExistingDictionaryEntries?: boolean;
requests: BatchDictionaryEntriesRequest[];
It's weird to have a nested parameter for whatever benefit I cannot see 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The goal of wrapping parameters in an object is to have a single parameter when calling the method. It would indeed improve the DX to flatten this object but adds a lot of complexity to our templates (might be worth doing a small POC, I'll take a closer look this week).
This is definitely an open discussion as we're still in closed beta, any improvements are welcome!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! Let's keep it at the back of our brains :)
🧭 What and Why
🎟 JIRA Ticket: -
Changes included:
We've decided to go with the
Params
suffix in our specs after #96, but some of the parameters were still using other wording. It's not mandatory to use theParams
suffix, but it should be the go-to when the name conflict with theoperationId
.🧪 Test
CI :D