Guide
Essentials
- Installation
- Introduction
- The Kdu Instance
- Template Syntax
- Computed Properties and Watchers
- Class and Style Bindings
- Conditional Rendering
- List Rendering
- Event Handling
- Form Input Bindings
- Components Basics
Components In-Depth
- Component Registration
- Props
- Custom Events
- Slots
- Dynamic & Async Components
- Handling Edge Cases
Transitions & Animation
- Enter/Leave & List Transitions
- State Transitions
Reusability & Composition
- Mixins
- Custom Directives
- Render Functions & JSX
- Plugins
- Filters
Tooling
- Single File Components
- TypeScript Support
- Production Deployment
Scaling Up
- Routing
- State Management
- Server-Side Rendering
- Security
Internals
- Reactivity in Depth
Migrating
- Migration to Kdu 2.7
Meta
- Meet the Team
Mixins
Basics
Mixins are a flexible way to distribute reusable functionalities for Kdu components. A mixin object can contain any component options. When a component uses a mixin, all options in the mixin will be “mixed” into the component’s own options.
Example:
|
Option Merging
When a mixin and the component itself contain overlapping options, they will be “merged” using appropriate strategies.
For example, data objects undergo a recursive merge, with the component’s data taking priority in cases of conflicts.
|
Hook functions with the same name are merged into an array so that all of them will be called. Mixin hooks will be called before the component’s own hooks.
|
Options that expect object values, for example methods
, components
and directives
, will be merged into the same object. The component’s options will take priority when there are conflicting keys in these objects:
|
Note that the same merge strategies are used in Kdu.extend()
.
Global Mixin
You can also apply a mixin globally. Use with caution! Once you apply a mixin globally, it will affect every Kdu instance created afterwards. When used properly, this can be used to inject processing logic for custom options:
|
Use global mixins sparsely and carefully, because it affects every single Kdu instance created, including third party components. In most cases, you should only use it for custom option handling like demonstrated in the example above. It’s also a good idea to ship them as Plugins to avoid duplicate application.
Custom Option Merge Strategies
When custom options are merged, they use the default strategy which overwrites the existing value. If you want a custom option to be merged using custom logic, you need to attach a function to Kdu.config.optionMergeStrategies
:
|
For most object-based options, you can use the same strategy used by methods
:
|
A more advanced example can be found on Kdux
‘s 1.x merging strategy:
|