npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@tradle/models

v4.10.12

Published

models for tradle apps

Downloads

11

Readme

Tradle Data Modeling syntax

Introduction

Tradle software is divided into two parts, the code and the data models. The code uses the data models to display data on the screen, to transmit data, to store data and to search for data. Each data model defines a set of properties. Any object of this model will have properties defined there. Some properties are listed as ‘required’. There are many other annotations, which are used to create rich definition of data and its handling.

We use Json Schema as a basis for the data modeling language, but Json Schema is not rich enough for our purposes, so we have extended it.

Models are like blueprints. “Resources” are like buildings created from those blueprints, and adhere to the model’s spec.

Below is the reference on data models. See some of the currently used models on github.

To validate your models, use: https://github.com/tradle/validate-model To validate resources built from models, use: https://github.com/tradle/validate-resource

Example:

{
  "id": "tradle.Name",
  "title": "Name",
  "subClassOf": "tradle.Form",
  "type": "tradle.Model",
  "properties": {
    "givenName": {
      "title": "Given name(s)",
      "type": "string"
    },
    "surname": {
      "type": "string"
    }
  },
  "required": [
    "givenName",
    "surname"
  ],
  "viewCols": [
    "givenName",
    "surname"
  ]
}

A resource built from this model would like this:

{
  “_t”: “tradle.Name”, // the model this resource is built from
  “givenName”: “Joe”,
  “surname”: “Schmo”
}

Model Attributes

properties

list of properties, each separately described. No other properties can be used in the objects of this model.

There is one exception to this rule, a special property that represents json. It allows to include any type of structured data into the object without modeling it upfront, which is very useful for integration purposes.

type

must be set to ‘tradle.Model’

id

namespaced id of the model, e.g. ‘tradle.Organization’

title

how you want the name of this model to appear in UI. This is useful for evolving UI without affecting the code that may be referencing that id.

subClassOf

optional, specifies this model as an extension of another model. This is when you absolutely need a strong rigidity in the data model. Current models you can subclass:

  • tradle.Form: the only way to specify in model that you want it to use for entering structured data.
  • tradle.Enum: for when you can list all possible values of the property, e.g. marital status, gender, etc. This mechanism is also used for longer lists, which are predefined, like currencies, countries, etc. See for example, the Country model.
  • tradle.FinancialProduct: to define products to put in your channel’s product list. This must have a corresponding model that subclasses tradle.MyProduct. If you have a product com.example.Insurance that subclasses tradle.FinancialProduct, you must have a corresponding model com.example.MyInsurance that subclasses tradle.MyProduct. This is the product certificate the customer receives after their application for a.b.Insurance is approved.
  • tradle.MyProduct: see tradle.FinancialProduct
  • tradle.Check: subclasses of this represent checks carried out during the application process, via third parties (tradle.TruefaceCheck, tradle.CentrixCheck, etc.), or otherwise.

interfaces

optional, array of interface models. They are more like markers. We don't enforce/check inheritance of their properties. We might consider it in the future but not at this moment

Example of the Intersection implementor:

{
  "id": "tradle.TaggedIssue",
  "type": "tradle.Model",
  "interfaces": [
    "tradle.Intersection"
  ],
  "properties": {
    "tag":  {
      "type": "object",
      "ref": "tradle.Tag"
    },
    "issue": {
      "type": "object",
      "ref": "tradle.Issue"
    }
  },
  ...
}

and then in tradle.Issue it'll be referred like this:

{
  "id": "tradle.Issue",
  "type": "tradle.Model",
  "subClassOf": "tradle.Form",
  "properties": {
    "tags":  {
      "type": "array",
      "backlink": "issue"
      "items": {
        "ref": "tradle.TaggedIssue"
      }
    },
    ...
  },
  ...
}

We have the following interfaces.

  • tradle.Document - to better group and display the resources on Profile. They will appear in the Profile's Documents tab. Some of the implementors are: tradle.PhotoID, tradle.Selfie, tradle.MediaSnippet, etc.
  • tradle.Item - to display them only in the parent resource. The resources of implementor type can be added on parent resource page
  • tradle.Intersection - to make a soft connection between two or more resources or different types. We use it for example here:

required

optional, array of properties. Server and UI both are making sure user enters all of them.

softRequired

optional, array of properties. UI is making sure user enters all of them in case they are displayed.

viewCols

restricts the set of properties that are displayed to the user when the resource is viewed on its own page. The order defines the order in which properties are displayed.

editCols

optional, restricts the set of properties that are displayed to the user in edit mode. The order defines the order in which properties are displayed.

inlined

optional, set to true on models like Money, whose values are not persisted to storage separately, but only when inlined into another object.

plural

title that is used in plural contact, like geese, to avoid saying gooses. But if you insist on saying gooses, we love you too.

icon

optional, displayed in various UI elements accompanying objects of this type. Icon names should be taken from this list: http://ionicframework.com/docs/v2/ionicons/

notShareable

optional. If true, it prevents the customer from sharing this object with other providers. For example tradle.Selfie is used for authentication in real time, and must always be taken fresh, thus it has nonShareable: true.

notEditable

optional, objects of this type could not be modified. Once again, tradle.Selfie fits this description

indexes

optional, to speed up the searches. Check tradle.Application to see how to add them

Property Attributes

title

optional, to specify a name different from the property’s uncamelcased name. Useful for evolving property names without changing all the references to them in the code.

type

used to specify what values the property can hold: string, number, date, boolean, array, object

ref

only used for type object. This specifies the model for that object, e.g. tradle.Organization

range

optional, when type is string, this specifies the category of values to accept, e.g. email, phone, url. This improves validation, formatting, the keyboard type shown to the user, etc. When type is object, and ref is tradle.Photo, range should be set to photo

inlined

optional, set to true if the value for this property is a resource rather than a link to a resource. When inlined is true, the value will be inlined and will not be stored separately in the database / object storage. Can also used for properties with type array.

readOnly

optional, set to true if this property cannot be modified by the user

immutable

optional, once the property value is set, the property can not be modified

description

optional, shown in UI during data entry to give the user an additional hint / instructions

displayName

optional, helps UI. When a resource is shown in a list or in the nav bar, its title is displayed. Set displayName to true if you want this property to be part of the object’s displayed title.

format

optional, dates only. Shown in UI in view mode. For example:

...
"expirationDate": {
  "type": "date",
  "format": "mmmm, yyyy"
}

numberFormat

optional, numbers only. Shown in UI in view mode. For example:

...
"zScore": {
  "type": "number",
  "numberFormat": {
    "maximumFractionDigits": 2
  }
},

It has only one property for now: maximumFractionDigits. It means to round the value to the value with 2 fraction digits.

pattern

optional, a regular expression (regexp) that defines the pattern for property value validation.

keyboard

possible values include: default, numeric, email-address, phone-pad

backlink

defines a one-to-many relationship. Specifies by which property the "many" links to the "one." Many must be type array. For an example, take a look at the relationship between tradle.PhotoID and tradle.Verification. In this case, many tradle.Verification resources can link to one tradle.PhotoID

showIf/hideIf

optional, a formula that will be executed to make a decision if the property is going to be displayed.

For example:

{
  "id": "tradle.XXX",
  "type": "tradle.Model",
  ...
  "properties": {
    "a": {
      "type": "string"
      "showIf": "country"
    },
    "b": {
      "type": "string"
      "hideIf": "country.id.endsWith('US')"
    },
    "country": {
      "type": "object",
      "ref": "tradle.Country"
    },
    ...
 }

It means:

  • the property country will be displayed
  • when it is set the a text field will be displayed - but not before
  • hide property b if the country is US, but show for all other countries or until it set