Best Practices: Property IDs
Every component must have a unique Property ID. A Property ID is the unique field ID used by Unqork to identify, track, and link components in your module. Linking components gives you the ability to create logic-based configurations and API (application programming interface) calls.
If your Property IDs are too similar or not well planned out, your application can run into issues. In this
This image shows where you'll find the Property ID in the component settings window.
Components reference other components by their Property IDs. For example, let's say you configure a Decisions component. Property IDs assigned as Inputs and Outputs in the Decision tell the system which components to reference. The Decisions component works based on these connections. This image shows how you reference Property IDs in a logic component.
What You'll Learn
In this article, you'll learn:
It's important to learn the best practices for structuring Property IDs. Property IDs should be unique and descriptive but also clear and concise. If they're too similar, your application can run into issues or even fail. If Property IDs are too long, you can run into snags when linking components.
It's helpful to pre-plan your Property IDs before configuring your first application. Develop a component naming convention and follow this across your application building process.
Here are a few more best practices:
Use camel case without spaces or punctuation between words for all Property IDs. Camel case (stylized as camelCase) means that compound words or phrases must have a lowercase first letter in the first word. Then, each next word starts with a capital letter. For example: firstName, middleName, and lastName. Using camel case make Property IDs easier to read.
Use descriptive Property IDs rather than generic versions. For example, use addressHome or addressWork rather than addressA, or addressB.
Keep your Property IDs short for a cleaner display and smaller payloads.
Prefix the Property IDs of operational-type components with the component type. For example, use calcCommission for a Commission Calculator component. Or, use initXxx for an Initializer or ruleXxx for a Decisions component.
Use the same Property ID and Label Text when labeling your non-visual components. For example, use calcTemperature for a Calculator establishing a Fahrenheit temperature conversion. This makes it easy to find the components in your module.
Keep your Property IDs unique per module.
For certain components, you can use standard prefix abbreviation. For example, let's say you have an Advanced Datagrid naming multiple beneficiaries. You can shorten the Property ID to adgBene.
WARNING We don't recommend the use of the ( . ) period character in Property IDs. Periods present in a Property ID might adversely affect dot notation functionality.
Here are some Property ID examples following best practices:
The Property ID for a Text Field labeled "Insured First Name" can be insuredFirst.
The Property ID for "Insured Middle Name" can be insuredMiddle.
The Property ID for "Insured Last Name" can be insuredLast.
Here's a list of recommended Property IDs for naming components:
|Intl Phone Number
Display & Layout
|Rich Text Editor
Data & Event Processing
Charts & Graphs