Why not sort the API queries in the document? about faker HOT 16 CLOSED

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.

from faker.

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.

from faker.

I'll give it a try。

from faker.

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

from faker.

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

from faker.

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

from faker.

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

from faker.

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

from faker.

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)

from faker.

How about this display？

from faker.

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?

from faker.

Or maybe use the following structure?

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

from faker.

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

from faker.

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

from faker.

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
  • ...

from faker.

Alternatively, we could try the following

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

I think that was the original idea.

from faker.