Skip to content

Latest commit

 

History

History
90 lines (56 loc) · 3.88 KB

dev-article-template.md

File metadata and controls

90 lines (56 loc) · 3.88 KB
Raw

Instructions to authors:

  • Copy this template into your repo.
  • Replace text <in angle brackets> with the appropriate items from your component.
  • Follow the instructions in each section—see the accompanying examples for futher guidance.

<Component name>

Start with a concise (1-2 sentence) description of the component.

  • Copy the exact summary from the design article.
  • Do not use the name of the component's class or implementation.
  • Link the first mention of the component (e.g., "Button") to the design article.
  • If the component is known by an alias on your platform, include that in the description, e.g. "... Ripples are known as 'Ink' in MDC-iOS."

If there are any component types, list them here in an unordered bulleted list.

  • Use the same ordering as in the design article.
  • Link each item in the list to the corresponding type section below. (If a section is called "Foo The Bar", then the anchor to link to is #foo-the-bar.)

Insert an image showing the component or all the component types.

  • If no such image exists, file a bug and add a TODO with the bug in an HTML comment in the source.

Using <Component name>

Include any usage instructions that are common to all types. If your platform includes more complete documentation elsewhere, (e.g., a "Getting Started" page), include a link to it here.

If installation instructions are required, first summarize the requirement in 1-2 sentences and then give detailed instructions in a collapsable section.

If all types use exactly the same list of API docs/source location links, or if there is a common set of links due to a superclass/etc, then include them here instead of repeating them in each type section.

<First component type>

Start with a concise (1-2 sentence) description of the component type.

  • If possible, copy the exact summary from the design article.
  • Link the first mention of the component type to the appropriate section of the design article.

Include a list of links to API documentation and source location of the component.

  • Use the class/implementation names when linking to the API docs.
  • Add other links as necessary if they would help using the component.

Describe how to use this component type in as much detail as necessary.

  • If your platform does not support a particular type, include the type but explicitly state that it isn't supported.
  • If support is planned, link to the issue tracking that feature request.

Key properties

List the key properties/attributes/CSS classes of the component in a table.

  • The first column is the property's name as used in the design article.
  • The second column is the property's identifier in code.
  • The third column is a short description of the property.
  • If there are several related classes used together for the component, list their properties in separate tables.
  • Only list the most important properties for configuring and theming the component—the full list of properties should be in the component's API docs.

<First component type> example

Describe the example in 1-2 sentences.

Include an image of the rendered example.

Include a snippet of source code illustrating the example.

  • Remove boilerplate code that is not necessary to understand the example.
  • Consider highlighting the most important lines of the example.

<Second component type>

...

Key properties

...

<Second component type> example

...

Continue describing the rest of the component types as necessary.