Custom Field Renderers¶

Create a snippet¶

Field renderers are JavaScript snippets that can be created from the App Composer.

1. Click the JavaScript tab in the Elements pane.

2. Click add Add Javascript resource and configure

   • Resource type: Field Renderer.
   • Custom field renderer name: Enter an appropriate name describing your field renderers.
   • Snippet body: Edit to include your field renderer JavaScript code.

By creating a snippet in this way, Skuid supplies the boilerplate code with all necessary parameters for a functioning field renderer. This code may be altered as needed as long as the snippet returns a FieldRenderer with the return keyword.

Assign the field renderer¶

To assign a field renderer to a field within a component:

1. Click the field within the target component within the canvas.
2. Change the Display as property to Custom.
3. Select the field renderer you wish to assign within the Custom field renderer field.

The fieldComponent parameter and context¶

Regardless of render strategy, the read and edit mode methods both receive fieldComponent as their parameter. This is the actual field element within the Form or Table component.

One of the most important functions available within the fieldComponent’s CPI is getContext(). This retrieves the context object of the current field. Using the information available in this object is the key to creating a dynamic, custom field renderer.

• context.element: The DOM element displayed when the element rendering strategy is used
• context.field: The field itself as a JavaScript object
• context.model: The model of the field, as a skuid.model.Model object
• context.row: The row of the field, as a JavaScript object
• context.value: The value of the field

It can often be helpful to assign these to variables using destructuring in read and edit functions:

1
2
3
4
5
6
7

read: function (fieldComponent) {
  let h = fieldComponent.h,
    context = fieldComponent.cpi.getContext();
    // Destructure one or more of these variables this way.
    let { element, field, model, row, value } = context;
    console.log(value); // This would be now be equivalent to context.value.
    ...

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

dataGridOptions: {
  needsFocusToEdit: true,
  onCopy(fieldComponent) {
    // Custom copy logic code
  },
  onCut(fieldComponent) {
    // Custom cut logic code
  },
  onPaste(fieldComponent, text) {
    // Custom paste logic code
  }
}

1
2
3
4
5
6

onCopy(fieldComponent) {
  throw new Error("Can't copy passwords");
},
onCut(fieldComponent) {
  throw new Error("Can't cut passwords");
}

When using the virtual rendering strategy¶

If using the virtual rendering strategy, functions must be written in HyperScript syntax and then must return the result of that HyperScript function.

CSS definitions are passed in as key-value pairs in the styles object. These keys can be camelCase or strings that reflect the kebab-case name of the CSS property. For example, the following styles settings will result in the same CSS values.

1
2
3
4
5
6

styles: {
  fontSize: "20px",
}
styles: {
  "font-size": "20px",
}

Using the element rendering strategy¶

In contrast to virtual rendering, which requires a HyperScript node be returned, element rendering instead looks to the fieldComponent’s context.element attribute, which is by default an empty div.

Changes to this DOM element must be made using standard DOM element APIs and properties. Additional elements must be made using other DOM manipulation APIs like document.createElement() or jQuery functions a la skuid.$, and then appended to the context.element.

After creating the DOM element, the context.element parameter must then be set to that newly created node. Style variants are not applied.