color: purple
header_image: api-notation.gif
description: "API notation is a simple way to document the public
-contract of your componentsA"
+contract of your components"
---
-When writing specifications and trying to figure out how components will interact, an important part is to define the public API as the contract others can depend on: So if you have a complex feature where several people are collaborating, you can ease up the integration woes by properly defining the contract they'll be using to communicate. This means that I usually end up having to write APIs in text files constantly, and over the years I've come up with a notation for this.
+When writing specifications and trying to figure out how components will interact, an important part of my workflow is to define the public API as the contract others can depend on: So if we have a complex feature where several people are collaborating, we can ease up the integration woes by properly defining the methods, properties and events they'll be using to communicate. This means that I usually end up having to write APIs in spec files constantly, and over the years I've been using and developing a notation for this.
The API notation is very simple and encodes what public properties, methods and events an object/class provides. It looks like this:
[vim]: https://github.com/rbdr/api-notation.vim
[atom]: https://github.com/rbdr/api-notation-atom
-[sublime]: https://github.com/rbdr/api-notation.tmLanguage
\ No newline at end of file
+[sublime]: https://github.com/rbdr/api-notation.tmLanguage
git.r.bdr.sh / rbdr / r.bdr.sh / blobdiff