Documentando componentes

Padrões

• Todos componentes devem ter um arquivo .md demonstrando como utilizar e o que pode ser feito com ele.
• A documentação deve ser criada no seguinte padrão de diretório ./docs/guide/<nome_do_componente_em_minusculo>/index.md.
• A nomenclatura dos componentes de exemplo devem seguir o mesmo padrão de nomenclatura do componente origem, seguida por algum dos sufixos Example ou Playground.
• Tente ser o mais objetivo possível na documentação, utilize a documentação existente como referencia.

Template Padrão

Para guiar na documentação, foi criado um template para seguir. Ele está localizado na pasta ./docs/ com o nome de _template.md. Podem haver excessões, mas via de regra toda a documentação deve ter a seguinte estrutura:

Visão geral

• Essa seção deve conter uma breve descrição do componente e como ele ajuda o usuário a realizar uma determinada tarefa.
• Essa seção deve conter um ou até dois casos de uso básicos de como o componente é utilizado.
• Essa seção deve conter também o code snippets da(s) implementação(ções) para mostrar ao desenvolvedor como realizar o uso.

Variações (opcional)

• Variações diferentes do componente com alterações visuais ou de interação significantes. Ex: Combobox vs Selectlist vs Select.
• Alterações menores, como por exemplo o tamanho, deve ser considerada apenas como propriedades.
• Deve incluir uma tabela com o nome das variantes e o seu objetivo. Deve ter o link para a documentação da variante.

Propriedades

Nome	Descrição	Tipo	Padrão
id		String	-

Eventos (opcional)

Nome	Atributos	Listener	Descrição
open	(id)	@open

Playground (recomendado)

• Essa seção deve conter a implementação do componente e as propriedades devem ser dinâmicas.
• Essa seção tem como objetivo demonstrar em maior detalhes o funcionamento do componente.
• As propriedades devem ser organizadas em uma tabela, onde contenha a label e o input para alterar a mesma.

Veja o LxDatePicker para um exemplo.