Add "Search terms" to each function's docs page

[aleclarson]

The idea here is to make searching the docs more likely to turn up a function you're looking for by describing possible use cases and alternative names often used by other implementations.

For example, the dash docs might have:

### Search terms

- Often called `slugify`, `kebabCase`, or `hyphenate` in other libraries.
- Popular use cases include:
  - Converting titles to URL-friendly formats by replacing spaces with dashes.
  - Creating consistent, dash-separated CSS class names from multi-word strings.
  - Generating SEO-friendly slugs for blog posts or website content.
  - Normalizing user input into dash-separated identifiers.
  - Preparing filenames by transforming descriptive phrases into dash-separated strings.

LLM assistance

LLMs like ChatGPT can help out with this task. For example, I used the following prompt to generate the above example:

Write a markdown section that includes search terms and possible use cases of my utility function. The markdown should be structured like this:

    ### Search terms

    - Often called `foo`, `bar`, or `baz` in other libraries.
    - Popular use cases include:
      - [list the most popular use cases of this function in a compact but “search-term rich” way]

My utility function is:
- dash
- It returns a string that is the dash-separated version of the input string.

[MarlonPassos-git]

I could help with it. However, I might like the structure.

### Search terms
- Often called `slugify`, `kebabCase`, or `hyphenate` in other libraries.

### Popular use cases:
- Converting titles to URL-friendly formats by replacing spaces with dashes.
- Creating consistent, dash-separated CSS class names from multi-word strings.
- Generating SEO-friendly slugs for blog posts or website content.
- Normalizing user input into dash-separated identifiers.
- Preparing filenames by transforming descriptive phrases into dash-separated strings.

Another point:

It will generate a significant amount of new documentation, resulting in a large PR that may pose a challenge for review. I believe it would be more efficient to divide it into smaller PRs for each module. What do you think?

[aleclarson]

However, I might like the structure.

Good idea, let's go with that 👍 (minus the trailing colon : in "Popular use cases" heading)

I believe it would be more efficient to divide it into smaller PRs for each module. What do you think?

Sounds good!

[MarlonPassos-git]

Module documentation progress

• array (PR opened)
• async (PR opened)
• curry (PR opened)
• function
• number
• object
• random
• series
• string
• typed

[aleclarson]

I thought about this a bit more, and I'm kinda worried it will increase the barrier to contribution too much. What do you think?

[MarlonPassos-git]

At what specific point? I know it's going to be a lot of work to review all the texts, but module by module, it will eventually be done.

My idea is to open PRs for all the modules with the texts generated by the LLM, and then review them function by function. Once I take the PR out of draft mode, it means you or other members can take a look.

I apologize for the delay, I am juggling other personal obligations at the moment.

[aleclarson]

Sorry for being unclear. What I mean is: when someone implements a new function, there's now one more thing they have to do (or that we have to do) before it can be merged. That's my worry; that people may be less likely to contribute new functions if too much is expected of them.

What you're doing now is just great, no complaints there. 😄

[MarlonPassos-git]

Regarding that, I think the search terms part doesn’t need to be mandatory for us to implement new features. Whether we like it or not, it’s more of an additional feature that will help with searches and SEO.

[aleclarson]

Yeah that makes sense 👍