Skip to content
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

Remove autogenerated code samples when using x-codesamples #1036

Open
tjperry07 opened this issue Dec 4, 2024 · 4 comments
Open

Remove autogenerated code samples when using x-codesamples #1036

tjperry07 opened this issue Dec 4, 2024 · 4 comments
Labels
enhancement New feature or request roadmap Features or bug fixes planned for future release

Comments

@tjperry07
Copy link
Contributor

tjperry07 commented Dec 4, 2024

Is your feature request related to a problem?

When add x-codeSamples, you have to enable the language in languageTabs to make it appear in the reference. This also makes the auto-generated ones appear.

Describe the solution you'd like

When using x-codeSamples for a specific language, the auto-generated ones should not appear or be a config option I can toggle on and off.

Describe alternatives you've considered

Turning off the language in question entirely
Editing the plugin code directly.
Tried to edit the CSS to hide the block, but they have the same CSS classes.

Additional context

If I went through the effort of creating custom code samples, I don't need the autogenerated ones.

Screenshot 2024-12-04 at 11 22 46 AM
@tjperry07 tjperry07 added the enhancement New feature or request label Dec 4, 2024
@sserrata
Copy link
Member

sserrata commented Dec 5, 2024

Hi @tjperry07, thanks for bringing this up...I think there's a couple of approaches to solving for this:

  1. Control generated snippets using variants. For example, we could support hiding some or all generated snippets/variants using the variants array, e.g. variants: [], in languageTabs. The change would apply globally across all plugin API configs.
  2. Control generated snippets using a plugin config option. For example, we could specify which languages/variants we want to appear. The change would be scoped to the specific API(s).

Some other item/feature to consider would be whether or not custom languages should be supported, or languages that aren't already included in the default language set.

Something else to consider is how x-codeSamples should be supported across endpoints. For example, it's possible that not all endpoints in an API will have the same languages and code samples represented, so the solution would need to be capable of adapting to that, such that code samples and language tabs only appear for those operations containing them.

@tjperry07
Copy link
Contributor Author

I would do #2. Since languageTabs is mostly from the Postman generator, I think messing with those might get a little messy.

It might be as simple as a check. For x-codeSamples, you have to supply a lang which usually matches the Postman languageTab. If x-codeSamples lang = Python, don't display the python postman tab?

IDK. It's tricky and everyone will have a preference. I would add an option to the plugin to just turn off the Postman languageTabs and replace them with my code samples.

@tjperry07
Copy link
Contributor Author

I've figured out a workaround for this. Add this to your custom.css. If the app changes, this will stop working.

.tabs-container.openapi-tabs__code-container.openapi-tabs__code-container-inner:nth-child(2) {
  display: none;
}

Basically when there is a custom code sample for the language, it puts in the top row and moves the auto-gen to the bottom. If there is no custom code sample, it moves the auto-gen to the top row. hiding the bottom row means when a user clicks through they only see the custom samples or the auto-gen and not both.

@sserrata
Copy link
Member

Btw, with a bit of experimentation I was able to suppress the generated variants simply by passing an empty variants: [] array in languageTabs (option 1). However, it required a couple of changes to CodeSnippets so it isn't technically supported yet. I'll try to work it into the next release, as I feel it should be supported. That said, we could still opt to pursue option 2 as I don't see options 1 and 2 as mutually exclusive.

@sserrata sserrata reopened this Dec 13, 2024
@sserrata sserrata added the roadmap Features or bug fixes planned for future release label Dec 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request roadmap Features or bug fixes planned for future release
Projects
None yet
Development

No branches or pull requests

2 participants