Plugins are used to extend KASKO frontend with additional functionality. Most commonly they will be used to create custom components. For this WEB Components are used. Any frontend framework can be used to create custom components as long as they are correctly transformed to web components. Most frameworks (including Angular, React, Vue) have wrapper modules that allow this functionality out-of-the-box. Note that this will have impact on performance. Hence it is recommended to use native WEB Components or LitElement.
Creating plugins
Demo plugins in the most popular frameworks can be viewed in the kasko-demo-plugins repository.
Either a factory method or a plain object containing the plugin configuration.
Examples
// With plain objectwindow.registerKaskoPlugin('my-plugin', { components: [ { type:'my-custom-component', component: MyCustomComponent, } ],});// With factory methodwindow.registerKaskoPlugin('my-plugin', (kasko) => ({ components: [ { type:'my-custom-component', component:myComponentFactory(kasko), } ],}));// Registering new validator with plain objectwindow.registerKaskoPlugin('my-plugin', { validators: [ { name:'my_custom_validator', validate: myCustomValidator, }, ],});// Registering new validator with factory methodwindow.registerKaskoPlugin('my-plugin', (kasko) => ({ validators: [ { name:'my_custom_validator', validate:myCustomValidator(kasko), }, ],}));
KASKO public service
When registering components or other attributes to KASKO frontend framework, a kasko public service is exposed via the factory method. This public service can be used to access translations, state slices, dispatch events and much more.
Interface
interfaceKaskoPublicService {/** * Retrieve a translation by the given translation key. */getTranslation(key:string, params:Object= {}):string;/** * Get the whole state or a slice of the state. */getState(slice?:string):any;/** * Get the current form state. */getFormState():any;/** * Retrieve a referrer URL. */getReferrerUrl():string;/** * Run a JsonLogic schema. * * @see: http://jsonlogic.com/ */evaluateJsonLogic(schema:Object, args:Object= {}):any;/** * Creates Kasko compatible date out of string or other values. */createDate(value:Date|string|number):Date;/** * Dispatch an event. * * Available events: * set-form-input: set local form state; config: `{ first_name: 'John' }` * set-state-input: set global input state + trigger requests (if input valid); config: `{ first_name: 'John' }` * go-to-screen: go to a specific screen (using this should be a last-resort, preferably use `go-forward` event and manifest `next` definition); config: `{ screen: 'start' }` * go-to-field: go to a screen which contains a specified field; config: `{ field: 'first_name' }` * go-forward: validate + trigger requests + proceed to next screen * go-back: proceed to previous screen * set-flag: set a specific flag to a global state; config: { editing: true } * set-validation-errors: set error; config: `[{ field: 'first_name', path: '', code: 'required' }]` * remove-validation-errors: remove error; * config: `[ * { field: 'first_name', path: '', code: 'required' }, * { field: 'first_name' }, * ]` * request-payment: triggers payment request * trigger-requests * validate-form: config: `(isValid) => {}` * submit-form: config: { input: { 'foo': 'bar' } } * save-quote: trigger lead request * request-item: config: load different item `{ item_id: 'item_id_123123', shouldOverwrite: false, shouldNavigate: false }` * - pass `shouldOverwrite: false` to preserve current state upon item change, optional * - pass `shouldNavigate: false` to skip initial_screen navigation upon item change, optional * add-upload: add a new media file to a global state; config: `{ file: File, field_name: 'upload', id: 8, callback: (error, payload) => {} }` * remove-upload: remove a media file with a specified id from a global state; config: `{ id: 8 }` * search-for-data: fetch data from Data Service; * config: { * field_name: 'test_field', * data_field_name: 'data_field', * source_field_name: 'source', * filter: [{ * filter_param: 'filter_param', * }], * field_map: { * map_param: 'map_param', * }, * value: 'value', * sort: 'desc', * options_limit: 2000, * callback: () => {}, * } */dispatchEvent(name:string, config?:any):void/** * Listen to an event. * * Available events: * field-validation: monitors field validity; example output: `false` (false = field is invalid) * validation-error: validation error occurred; example output: `{ required: true }` * validation-success: validation success occurred; output: `void` * state-changed: when state (or state slice) changed; example output: `123` * route-changed: when route has changed; example output: `{ previous: { path: '/start' }, current: { path: '/end' } }` * form-changed: when form has changed; example output: `{ previous: { duration: 'P1Y' }, current: { duration: 'P3Y' } }` * is-loading: when requests are made; example output: `true`; * is-loading-leads: when lead request is made; example output: `true`; * is-error-leads: when lead request fails; example output: `true`; * default-input-set: when default_values are set from manifest to input state; * item-loaded: when item data is loaded; output is item data */addEventListener( name:string,callback:Function, options?:Object, ):void;/** * Remove all event listeners with the same name & callback. * * The `callback` function passed here must have the same function reference * as with the one registered. * * @example * // OK: * kasko.addEventListener("state-changed", handleStateChange); * kasko.removeEventListener("state-changed", handleStateChange); * * // Wrong (exception): * kasko.addEventListener("state-changed", handleStateChange); * kasko.removeEventListener("state-changed", handleOtherStateChange); */removeEventListener(name:string,callback:Function):void;}
Using plugin components in manifest
All plugin components registered to the KASKO frontend framework become available for use in the manifest. Reference them in the manifest the same way how any internal component would be used.
All plugin validators registered to the KASKO frontend framework become available for use in the manifest and field definition. Reference them in the manifest the same way how any internal validator would be used.
Almost all components need to implement some dynamic functionality that can be configured via the manifest. This can be achieved with WEB Component attributes.
Sometimes custom components need to allow various content sections to be defined via manifest. For example, a panel component could have a header, body and footer section. This functionality can be achieved with slots.