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

[Docs] Automate API documentation #5607

Closed
stsrki opened this issue Jul 3, 2024 · 5 comments
Closed

[Docs] Automate API documentation #5607

stsrki opened this issue Jul 3, 2024 · 5 comments
Labels
Type: Feature ⚙ Request or idea for a new feature.
Milestone

Comments

@stsrki
Copy link
Collaborator

stsrki commented Jul 3, 2024

Not a priority. However, we could investigate how to generate API documentation for each component. We could use XML comments for all needed information

One problem I see with automation is that we don't know which public methods must be mentioned and which not. Not all public methods should be used by the user. We might add an additional comment to them, like "Should be used only internally", and then skip those.

@stsrki stsrki added the Type: Feature ⚙ Request or idea for a new feature. label Jul 3, 2024
@ddjerqq
Copy link
Contributor

ddjerqq commented Jul 8, 2024

Could we use the [EditorBrowsable] Attribute, and when generating docs, use reflection to filter out those members?

If we don't want the user to use those public methods anyway, we could hide them, so someone who does not know about their existence, will not use them.

@stsrki
Copy link
Collaborator Author

stsrki commented Jul 8, 2024

All public members that should be used are already marked as Parameter Attribute. Methods are a bit different, so we need to find another way. I would not add more attributes for now.

@ddjerqq
Copy link
Contributor

ddjerqq commented Jul 8, 2024

I see, what do we have more of? public methods that are internal Blazorise use only? or public methods that are for users only?

we could use a custom xml element for marking our methods BlazoriseInternal maybe?

/// <summary>
/// Some method description
/// </summary>
/// <blazorise-internal/>
public void SomeMethod();

@ddjerqq
Copy link
Contributor

ddjerqq commented Jul 8, 2024

how about critical?

@stsrki
Copy link
Collaborator Author

stsrki commented Jul 8, 2024

My idea is to have a comment convention that indicates the method is only for internal use. Then, we can just filter out those.

/// <summary>
/// Some method description. It should not be used externally. 
/// </summary>
public void SomeMethod();

This way, we know what to filter, and the user knows that if they use it, it may not work as expected, because the same comment can show up in IntelliSense.

@stsrki stsrki added this to the 1.7 support milestone Dec 10, 2024
@stsrki stsrki added this to Support Dec 10, 2024
@github-project-automation github-project-automation bot moved this to 🔙 Backlog in Support Dec 10, 2024
@stsrki stsrki closed this as completed Dec 10, 2024
@github-project-automation github-project-automation bot moved this from 🔙 Backlog to ✔ Done in Support Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature ⚙ Request or idea for a new feature.
Projects
Status: ✔ Done
Development

No branches or pull requests

2 participants