Why not sort the API queries in the document?

[LARVAIDE]

Clear and concise description of the problem

It is difficult to use without sorting

Suggested solution

Alternative

No response

Additional context

No response

[github-actions]

Thank you for your feature proposal.

We marked it as "waiting for user interest" for now to gather some feedback from our community:

• If you would like to see this feature be implemented, please react to the description with an up-vote (:+1:).
• If you have a suggestion or want to point out some special cases that need to be considered, please leave a comment, so we are aware about them.

We would also like to hear about other community members' use cases for the feature to give us a better understanding of their potential implicit or explicit requirements.

We will start the implementation based on:

• the number of votes (:+1:) and comments
• the relevance for the ecosystem
• availability of alternatives and workarounds
• and the complexity of the requested feature

We do this because:

• There are plenty of languages/countries out there and we would like to ensure that every method can cover all or almost all of them.
• Every feature we add to faker has "costs" associated to it:
  • initial costs: design, implementation, reviews, documentation
  • running costs: awareness of the feature itself, more complex module structure, increased bundle size, more work during refactors

---

View more issues which are waiting for user interest

[xDivisionByZerox]

Just for clarification:
You are suggesting that we should only display modules in the API sidebar? Or are the faker constructors lower on your screenshot?

As an alternative, we could group the sidebar into core (faker constructors, util) and modules.

[matthewmayer]

Adding a extra separator before Airline would make it clearer that the rest are in alphabetical order

[LARVAIDE]

Yes, the APIs in sidebar can be sorted alphabetically。🤔

[matthewmayer]

They already are, it's just that there are some special ones at the top and the bottom. Adding some extra separators or subheadings would clarify that.

[ST-DDT]

@LARVAIDE Are you interested in creating a PR to implement this?

[LARVAIDE]

I'll give it a try。

[LARVAIDE]

From the code, it can be seen that 'Faker', 'SimpleFaker', and 'Randomizer' have special rules, among which 'Randomizer' is not quite the same. Why is this necessary? @ST-DDT

[ST-DDT]

Because those are classes whereas the others are "Modules".

Faker has some internal classes, methods and other stuff, that should not be exposed in the api docs. Such as:

• *BaseModules (because those would be redundant)
• Helper functions and classes used inside the faker functions
• Locale definition interfaces and data
• MersenneTwister implementation

For that reason we select which data we wish to expose:

• API Classes/Interfaces: 'Faker', 'SimpleFaker', and 'Randomizer' (somewhat hardcoded)
• API Modules: Any class that fullfills faker[some] = SomeModule`
• API Utilities (standalone functions): 'mergeLocales' (somewhat hardcoded)

[LARVAIDE]

How about this display？

[matthewmayer]

That makes it look like Faker Core has its own page. But I don't think we have a link for that. Maybe Faker could be the "top level" item with others nested inside it?

[ST-DDT]

Or maybe use the following structure?

• API
  • Faker
  • SimpleFaker
  • ...
  • Modules
    • Airline
    • Animal
    • ...

[matthewmayer]

I feel like the Modules are the most important part for most users so they should not be nested too deep. It's only for advanced usage you really need to delve too much into the constructors, Randomizer etc.

Maybe just a <hr> to seperate the top section off without necessarily needing nesting or extra subheaders?

API

• Overview
• Faker
• SimpleFaker
• Randomizer
• Utilities

---

• Airline
• Animal

[matthewmayer]

Alternatively stick with this proposal but add a new markdown page "Faker Core" with brief descriptions of what the 4 items inside are for?

[ST-DDT]

FakerCore will likely be a new type/interface/thing in v9. (DAO for locales, mersenne and config, not fixed yet)

How about the following structure:

• API
  • Faker
  • SimpleFaker
  • ...
• API Modules
  • Animal
  • ...

Alternatively, we could try the following

• API
  • Faker
  • SimpleFaker
  • ...
  • <hr>
  • Animal
  • ...

[xDivisionByZerox]

Alternatively, we could try the following

• API
  • Faker
  • SimpleFaker
  • ...
  • <hr>
  • Animal
  • ...

I think that was the original idea.