JavaScript instance method page template

Note: Remove this whole explanatory note before publishing

Page front matter:

The front matter at the top of the page is used to define "page metadata". The values should be updated appropriately for the particular method.

---
title: Constructor.prototype.nameOfTheMethod()
short-title: nameOfTheMethod()
slug: Web/JavaScript/Reference/Global_Objects/Constructor/nameOfTheMethod
page-type: javascript-instance-method
status:
  - deprecated
  - experimental
  - non-standard
browser-compat: javascript.builtins.Constructor.nameOfTheMethod
sidebar: jsref
---

title

Title heading displayed at the top of the page. Format as Constructor.prototype.nameOfTheMethod(). For example, the at() method of the Array class has a title of Array.prototype.at().

short-title

A short title used in breadcrumbs and sidebars. Format as nameOfTheMethod(). For example, the at() method has a short-title of at().

slug

The end of the URL path after https://developer.mozilla.org/en-US/docs/. This will be formatted like Web/JavaScript/Reference/Global_Objects/Constructor/nameOfTheMethod. Note that the name of the method in the slug omits the parenthesis (it ends in nameOfTheMethod not nameOfTheMethod()).

page-type

The page-type key for JavaScript instance methods is javascript-instance-method.

status

Flags describing the status of this feature. An array which may contain one or more of the following: experimental, deprecated, non-standard. This key should not be set manually: it is set automatically based on values in the browser compatibility data for the feature. See "How feature statuses are added or updated".

browser-compat

Replace the placeholder value javascript.builtins.Constructor.nameOfTheMethod with the query string for the method in the Browser compat data repo. The toolchain automatically uses the key to populate the compatibility and specification sections (replacing the {{Compat}} and {{Specifications}} macros).

Note that you may first need to create/update an entry for the method in our Browser compat data repo, and the entry for the API will need to include specification information. See our guide on how to do this.

sidebar

This is jsref for JavaScript instance method pages. See Page structures: Sidebars for details.

Top-of-page macros

A number of macro calls appear at the top of the content section (immediately below the page front matter).

These macros are automatically added by the toolchain (there is no need to add/remove):

{{SeeCompatTable}} — this generates a This is an experimental technology banner that indicates the technology is experimental. If it is experimental, and the technology is hidden behind a pref in Firefox, you should also fill in an entry for it in the Experimental features in Firefox page.
{{Non-standard_Header}} — this generates a Non-standard banner that indicates that the feature is not part of any specification.

Do not provide status header macros manually. Refer to the section How feature statuses are added or updated to add these statuses to the page.

Samples of the Experimental and Non-standard banners are shown right after this note block.

Remember to remove this whole explanatory note before publishing.

Note: Remember the single most important principle for writing consistent JavaScript reference pages: look around! Many related pages have consistent structures beyond what's required in this template. For example, all proxy handlers, most array methods, etc. Start by looking for existing documentation for similar APIs and copy its structure.

Experimental: This is an experimental technology
Check the Browser compatibility table carefully before using this in production.

Non-standard: This feature is not standardized. We do not recommend using non-standard features in production, as they have limited browser support, and may change or be removed. However, they can be a suitable alternative in specific cases where no standard option exists.

The nameOfTheMethod() method of {{jsxref("Constructor")}} instances does something. This should ideally be 1 or 2 short sentences. Keep this in sync with the constructor's landing page — for example, the landing page should contain lines like this:

- {{jsxref("Constructor.prototype.nameOfTheMethod()")}}
  - : Does something.

Syntax

Fill in a syntax box, according to the guidance in our syntax sections article.

nameOfTheMethod(parameter1)
nameOfTheMethod(parameter1, parameter2)

Parameters

parameter1: Include a brief description of the parameter and what it does here. Include one term and definition for each parameter. If the parameter is not optional, remove the {{optional_inline}} macro call.
parameter2 Optional: etc.

Note: This section is mandatory. If there aren't any parameters, put "None." instead of the definition list.

Return value

Include a description of the method's return value, including data type and what it represents. For example: "A Number representing something."

If the method doesn't return anything, just put "None (undefined).".

If the method returns a promise, use the format "A Promise asynchronously fulfilled with a Number representing something". Rejected promises go into the "Exceptions" section.

Exceptions

TypeError

Thrown in one of the following cases:

Condition 1.
Condition 2.
etc.

RangeError

Throw if...

Be as comprehensive as possible. Generally, don't list exceptions that may be thrown from invoking user code, such as running getters or doing type coercion. Don't list exceptions from type mismatch, such as passing a symbol to a parameter that expects a string, or passing a non-function as a callback.

Description

Most of the description of the method should go here. Be as comprehensive as possible. If there are many pages that share the same description, consider adding a new section to the class's landing page and linking to it from here. For example, Array methods and empty slots is linked to from every array method page.

Readers should be able to understand the API in its entirety from this section without reading the examples section below. Examples presented in this section, should they be necessary, should be concise and do not have to be real-world-relevant.

Examples

Note that we use the plural "Examples" even if the page only contains one example.

A descriptive heading

Each example must have an H3 heading naming the example. The heading should be descriptive of what the example is doing. For example, "A simple example" does not say anything about the example and therefore, not a good heading. The heading should be concise. For a longer description, use the paragraph after the heading. The first example may be called "Using nameOfTheMethod()".

See our guide on how to add code examples for more information.