To keep the core codebase as simple and clean as possible, all edge-case (80/20 rule) functionality is added through extensions. There are many different types of extensions which we'll cover, but first let's clarify why extensions are displayed in the App but located in the API codebase.
Despite being an App resource, the Directus extensions are actually stored in the API codebase and repository. This seems counter-intuitive, but is neccesary because the Directus App supports multitenancy (you can connect to multiple APIs from one App). If you install a custom interface, like a "Seating Chart", you'll want that interface to be available within your project no matter which App you connect through.
Because of this, we store all custom extensions in the API Instance, and to keep things organized, we decided to also serve all core extensions from the same place.
Reporting Extension Issues
If you're adding a GitHub issue related to an extension, you still add it to the App since that is the logical place to discuss GUI components.
You can include an extension in your project but disable it from being used by prepending its container directory with an underscore (
_). For example, the demo Page is included in the API codebase but is disabled by default:
Interfaces customize how a field is presented to the user. For example a
STRING datatype would be shown as a text-input by default, but an interface could instead show that as a dropdown, Map, WYSIWYG Editor, or Color Picker.
Each interface also describes how a field's data should be shown on the Browse Items page. For example, you might want to show a boolean as a
× instead of
Layouts are custom designs for the Browse Items page. The core layouts are the List view (system default), which shows items in a tabular format, and a Card view (default for Users and Files) for image-based collections.
Pages handle everything not covered by Interfaces and Layouts. Pages allow anything to be built inside of Directus: custom dashboards, reports, point-of-sale systems, etc. Each page is protected within the auth gateway and can easily access instance data or global variables (eg: current user).
Storage Adapters allow you to save Directus files anywhere. The default storage adapter is the API server's filesystem, but other adapters are available for other popular options. If you need to implement a proprietary or custom option, that is possible too.
Users can use their Directus password to authenticate, or any enabled Single Sing-On (SSO) services.
- Link to Install Wiki/Docs for getting up and running
- How to create a new one (write from scratch, copy existing)
- Maybe explain that the
valueis the important variable to save to? (should be obvious, but might help)
- How to work with validation, conditionals for styling, etc
- Options! What are they? How to set them, how to fetch/use them in the code
- Include link to full styleguide (Google Doc for now)
- Maybe explain the Core components they can use? (eg:
- Quick explanation of each item in meta.json
- Rules for using/including external libraries (size, how to, license, etc)
- Can they write code tests for these interfaces?
- "Building" the interfaces... is this needed? When does it happen?
npmcommands... for some reason aI can't find them 😕
- End with quick info on where/how to properly submit an interface PR to us