Exposing properties and other entry information

entityData

With Kanka 2.4, a partial JavaScript dump was added for properties and a handful of other information. As of 2.7, this object now includes most of the entry’s information relevant to a character sheet, with the notable exception of abilities. You can access it via the entityData object, which contains the following fields (further detailed on the official Helper pagearrow-up-right):

console.log(entityData)
{
  "name": "...",
  "is_private": true|false,
  "type": { ... },
  "attributes": { ... },
  "tags": [ ... ],
  "type_field": "...",
  "is_dead": true|false, // Characters and Creatures only
  "is_extinct": true|false, // Races and Creatures only
  "is_completed": true|false, // Quests only
  "is_defunct": true|false, // Organizations only
  "is_destroyed": true|false, // Locations only
  // The rest are only included for Character entries:
  "gender": "...",
  "pronouns": "...",
  "title": "...",
  "age": "...",
  "traits": [ ... ], // and appearances
  "races": [ ... ],
  "families": [ ... ],
  "location": { ... }
}
circle-exclamation

Axios API

Kanka 2.7 introduced tools to access the API via axios methods that interact with an entry’s properties and abilities. This allows us to generate a far more thorough property dump (including, for instance, property types and their pinned status) with names that match those used in Blade, as well as a detailed dump of ability information.

However, because axios is only initialized after the page is fully loaded, unlike our character sheet scripts, window.onload is necessary to defer execution until axios is ready. Any processing that relies on the property/ability dumps must therefore also be deferred. Since you have to wait until the page finishes loading to make the API request, then wait for the data to be returned by the API, this introduces a significant delay to your data processing. If you try building an empty layout in Blade and filling it with content using axios-provided data in JavaScript, you will see that it can take more than a second before your layout gets populated, resulting in a poor user experience.

Therefore, it is advisable to do any time-sensitive initial processing and content-building with entityData or Blade – though again, since property names differ between entityData and the API, you have to be vigilant about your references, and cross-references between the two are more or less impossible unless you are targeting specific properties for which you know the exact form of both slugs (forget running a forEach in one using properties passed by the other!).

All of that said, here is some boilerplate that will fetch properties and abilities from the API, format the former to match Blade variable names, and either run any API-dependent code or log an error if something goes wrong.

Each property value can then be accessed with a simple attributes.slug.value, where slug matches the property’s corresponding Blade variable:

circle-exclamation

Several other details are available via attributes.slug, beyond what is accessible in Blade; for example:

Most notably, the apis object provides the necessary URLs to implement our own live-editing for properties.

We also get a ton of information about abilities, grouped by their parent field like in the Abilities page of the entry; for example:

arrow-up-right

Last updated