I think we can simplify this function by just making the filter not optional and adding a default value as{} so we could use it directly in theURLSearchParams without having to do many ifs.

getOAuth2ProviderApps=async(filter:TypesGen.OAuth2ProviderAppFilter={},):Promise<TypesGen.OAuth2ProviderApp[]>=>{constparams=newURLSearchParams(filter);constresp=awaitthis.axios.get("/api/v2/oauth2-provider/apps",{ params},);returnresp.data;};

Another function we can improve.

exportconstgetApps=(filter:OAuth2ProviderAppFilter={})=>{return{queryKey:[...appsKey,filter],queryFn:()=>API.getOAuth2ProviderApps(filter),};};

Is it possible to have anOAuth2ProviderApp without an user?

yes, that's possible

What is the use case?

Different flows/grant types. Client credential flows have to be owned/tied to a user, while authorization code flow must not be tied to a user.

Do you think would make sense to left a comment in this attribute, in the codersdk type? I think this is something I would easily forget in the future.

My overall feeling is this component is doing way more than a form should do. I think we can improve by:

• Remove props that are not going to change and use the value directly
• Execute the mutation in the form, and only call theonSubmit oronSubmitSuccess if the parent needs that

By applying these, I think we can significantly reduce the complexity of this component. This may require a few changes, so probably will need a second review round.

I know using the WEB API is nice, but it has some gaps and to make the code consistent lets useFormik andYup for validation.

You can easily find examples on how to use both in the codebase.

⚠️ Blocker

The BE supports filtering a user by username or email, if that is not available in the app, I think we can do.

• Add the username or user email to the app response
• Add an endpoint into the backend to fetch user data by ID

I don't think we should move forward with the current solution.

We should avoid adding a new dialog style only for this case. Did you take a look in the other dialogs? Wondering what you want to achieve here that is not achievable by using the existent dialogs.

I can refactor that into a component if you'd like, but none of the other dialogs allow resizing since the max width is always hardcoded.

When opening the code example in the dialog, I want it to expand both horizontally and vertically so that the word wrap on the curl command in the code example doesn't apply, and users can see the command they are about to copy and paste without having first to copy it and then inspect it in another editor.

Ok, lets keep it as it is - in terms of design. I will give it a try and see what we can do to better support this use case in our design system.

We are not using inline CSS styles anymore. Give a try toTailwindCSS class names. You can see many of them in the code base.

Looks like it should be a button instead of a link. Links should be used for navigation.

Wondering why only these two have end set to false 🤔

None of the other items has nested menus. Only the tokens and OAuth2 app section can navigate to another route, thus making the nav item "unselected".

I will give this a try and see how it behaves.

Let's also add a log here; we probably don't want to leak the error details back in the HTTP response, so let's just say something generic; admins can refer to the logs for details.

You're still returning the error directly; we probably don't want to do that; ditto for the other cases.