lion/docs/guides/principles/subclasser-apis.md
Pavlik Kiselev 11bbc5fff5
feat: migrated the navigation metadata from inline MD title decorations to frontmatter
* feat: migrated the navigation metadata from inline MD title decorations to frontmatter

* fix: fixed frontmatter metadate for api-table MDs

* fix: fixed frontmatter eslint issue
2025-03-19 10:08:22 +01:00

40 lines
1.2 KiB
Markdown

---
parts:
- Principles
- Subclasser apis
title: 'Principles: Subclasser apis'
eleventyNavigation:
key: 'Principles: Subclasser apis'
order: 50
parent: Principles
title: Subclasser apis
---
# Principles: Subclasser apis
In order to make it easy for Subclassers to extend our components, we follow a certain set
of best practices naming conventions to make our code predictable.
## Templates
### Template naming conventions
For templates that do need access to the instance of the web component there is a prefix `_render/__render`.
Examples are `__renderHeader` and `__renderData`.
### Separation of concerns
Our components should make it possible to override markup and styling, without having to redefine
functionality.
By using the spread directive, we can achieve this. For more info, see [explanation](https://github.com/ing-bank/lion/issues/591).
## Node references
As a Subclasser, you sometimes need access to a protected node inside the shadow dom.
Most functional nodes have their own getters. A Subclasser can access those in his extension and
in some cases, override these getters.
### Node naming conventions
A node reference will have an underscore prefix and always ends with `Node`.
Examples are `_inputNode` and `_formNode`.