What we need from the new Property Descriptor design:

We want it to be extremely easy to add a new property type. This has two parts. a) defining the property as a data type b) designing the UI to view and edit the type. See #63
We want to be able to think clearly about how data is stored in the database, versus how it is displayed and edited on screen
We want it to be easy to filter on new property types. For that, we need to know how the data is stored in the database. Optionally the property definer might want to tweak the possible filtering operations, but out of the box, filtering should work
We want to be able to round trip between json schema and cozemble models.
We want to be able to round trip between json and cozemble records
Generation of random data should be easier when we base property types on basic json schema types (string, number, boolean, date etc), so we can drop that from the property definition
Custom property types - lets say Phone number, Email address, Currency - should automatically participate in the json schema and json round tripping

Considerations/Options

Instead of the core property types (string, number, decimal etc) being defined in Typescript, if we had one base type of JsonDefinedPropertyDescriptor, and it’s configuration was based on a json schema, then the approach to defining core property types would be the same as that to define custom property types. See #70
It will take quite some time before developers come to cozemble to define their own property types (if at all) so while we should not do anything to prevent us getting to the point of this being easy, we should not invest our time and UX into getting this perfect right now, because it will only be us for a while to come.
When it does come to moment of a developer unknown to cozemble adding a custom property type, there will need to be some kind of (per tenant?) registry of custom types, and the app, frontend and backend, will need to load these custom property types into the core property types

Reasons

Adding a new property type right now is effectively impossible for a noob to achieve, so it will not happen. A user should be able to open a repl and create a new type quickly
Storing data in the postgres database is effectively writing into a json document, so it will help us if we are explicit that the data is json. Right now, a Property Descriptor describes its underlying data type as a Typescript type. There will be benefits by consolidating on the base json schema types
We want filtering and sorting to “just work” for custom property types, due to the fact that we know their underlying json schema type
We want to be able to generate cozemble models using Generative AI, and we think round tripping json schema is a way to do this
Round tripping json schema and json opens the door to automatic REST and GQL apis. See #39

What we want to retain

Ability to define new property types, in terms of data structure and ui
Ability to define property type configuration options, and the ui to set them
Ability to define global system configuration options on a property type basis
Ability to validate property definitions
Ability to validate data against property definitions
Event sourcing, both in terms of the model definition and also in terms of data editing

Example 1: Core property type defined as JsonDefinedPropertyDescriptor

Instead of this:

export interface StringProperty extends Property {
  propertyType: { _type: 'property.type'; value: 'string.property' }
  validations: RegexValidation[]
  multiline: boolean
}

export interface RegexValidation {
  _type: 'regex.validation'
  regex: string
  message: string
}

Definition of the core string property type would be extension of a String type with a json schema defining the extra config of regex validations and multiline support

We would lose the nice type checking in tests that we have now, but may be we could retain that by writing a companion typescript definition that wraps the underlying json schema driven type.

Example 2: We want to be able to generate cozemble models using Generative AI

I prompted ChatGTP with: Generate jsonschema for this project. Use json schema "ref" to express relationships: I run a bicycle repair shop. People book repairs via my website so they can come to my shop at an agreed time, drop off their bike, and collect it at an agreed time on the same day. I call this service Bike Check. The booking part of my website works fine and I am happy with that. What I need is a system to manage what goes on behind the website. I want to be able to: Enter customer data: first name, last name, email and mobile number. I want emails and mobile numbers to be unique. I want to be able to enter data for a Bike Check: customer, drop off date, make and model of bike, and general notes about the booking. I want to be able to upload pictures of the bike into the Bike Check record when the bike arrives. I want be to able to find customers using free text search I want to be able to find Bike Check records by date, and using free text search of all fields, but especially: make, model, customer name and notes. When adding a new Bike Check, if the customer is not already in the database, I want to be able to enter a new one

And it returned me this:

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "definitions": {
        "Customer": {
            "type": "object",
            "properties": {
                "firstName": {"type": "string"},
                "lastName": {"type": "string"},
                "email": {
                    "type": "string",
                    "format": "email",
                    "uniqueItems": true
                },
                "mobileNumber": {
                    "type": "string",
                    "pattern": "^(\\+[0-9]{1,4})?[0-9]{7,14}$",
                    "uniqueItems": true
                }
            },
            "required": ["firstName", "lastName", "email", "mobileNumber"]
        },
        "BikeCheck": {
            "type": "object",
            "properties": {
                "customer": {"$ref": "#/definitions/Customer"},
                "dropOffDate": {
                    "type": "string",
                    "format": "date-time"
                },
                "bike": {
                    "type": "object",
                    "properties": {
                        "make": {"type": "string"},
                        "model": {"type": "string"}
                    },
                    "required": ["make", "model"]
                },
                "notes": {"type": "string"},
                "images": {
                    "type": "array",
                    "items": {
                        "type": "string",
                        "format": "uri"
                    }
                }
            },
            "required": ["customer", "dropOffDate", "bike"]
        }
    },
    "type": "object",
    "properties": {
        "Customers": {
            "type": "array",
            "items": {"$ref": "#/definitions/Customer"}
        },
        "BikeChecks": {
            "type": "array",
            "items": {"$ref": "#/definitions/BikeCheck"}
        }
    }
}

If I can round trip between json schema and cozemble models then we can provide existing model state to prompts via json schema, and create new models in response to the prompts via the generated json schema.

cozemble / monorepo

Property Descriptor Design V2 #77