OpenFn / OpenFn/docs

API reference: clarify optional vs required properties and parameters

Open
#478 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
23
Forks
20
Avg merge
3d 1h
Merged PRs (30d)
6

Description

Our JSDoc templates don't do a good job of making it clear what properties or parameters are required, and what are optional.

In the JSDoc spec, you declare an optional property or parameter in square brackets, like this:

* @param {string} [color]
* @property {string} [nickName]

But if you look at our documentation, all we do is display the property in square brackets, and who knows what that means?

image

Sometimes we explicitly say things are (Optional) in the description.:

image

This is kinda fine but we're not consistent. Also the context is different. When describing parameters, the parameters are required unless otherwise stated. But when describing an object, I'd say the properties are OPTIONAL unless otherwise stated (because objects are usually called options and if they were required, well, they wouldn't be options.

So for this issue, we need to:

  • Visualise required properties and params differently to optional ones (and agree the standard)
  • Consistently mark optional stuff the same way across our adaptors
  • Document our rules clearly somewhere (perhaps in a wiki referenced in the readme)

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the JSDoc templates and the existing adaptor documentation examples, including the required and optional notation described in this issue. Agree on a consistent visual standard for properties and parameters, apply it across the adaptors, and document the rules in a clearly referenced wiki or README section. Done means required and optional items are consistently distinguishable and the convention is documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.