gatewayapps / cradle Goto Github PK

./src/lib/PropertyTypes/PropertyType.spec.ts has a linting error on line 20. We need a tslint-ignore comment in there

I'm a big fan of our prettier style from https://github.com/gatewayapps/grayskull. I would like to have prettier and prettier-tslint installed as dev dependencies and our prettier.config.js copied over.

The ModelReferencePropertyType does not have any tests written. Tests should go in src/lib/PropertyTypes/ModelReferencePropertyType.spec.ts. Please reference other *.spec.ts files for conventions.

Cradle 0.2 introduced Operations on models. These just define the method signatures available on a model and do not dictate the implementation.

In the cradle spec, we need the ability to create 1 to N and 1 to 1 references between models.

For example, give a User model and a Group and a Territory model. A User has many Groups and a User has one Territory.

User:
  properties:
    _id: uniqueidentifier auto unique
    deleted: boolean delete
    ...
  references:
    groups: multiple of Group
    territory: single of Territory

in the references section, we need to be able to specify:
for 1-n relationship: property: multiple of X where X is the Model
for a 1-1 relationship: property: single of X where X is the Model

The referenced Model will be required to have a unique identifier but the onus will be on the spec creator.

Would be nice to have Intellisense for emitter options. To do that, we need to expose the final emitter options.

We should build a library of type mappings in a new package:

@gatewayapps/cradle-type-mappings

Should define mappings like:

{
  "typescript": {
    "UniqueIdentifier": "string"
  }
}

We should have a good introduction and documentation about what cradle is. It should discuss the spec, but also discuss how external loaders and emitters work.

Should include some sample commands, sample SPEC file, and an example of output. Links to the sql-loader, react-emitter, and template-emitter as well.

We need further testing around the spec parser. There are a number of tests written, but they don't cover everything. Check out src/lib/SpecPropertyTypeParser.spec.ts

Any additional tests here would be much appreciated

Support defining operations (mutations/functions/actions/etc...) on models.

What this means

• Operations should define what arguments they will take in, and what the operation will return as a result

What this DOES NOT mean

• Operations should not explicitly define HOW an operation will perform. Only that this operation will exist

Right now we have different properties available depending on the property types.

For instance, IntegerPropertyType has a min, max, default, and a custom IntegerAutogenerateOptions auto field.

That means we have to handle parsing different properties for different property types.

I propose we move to following these rules for spec properties:

• Nothing has custom properties, emitters can publish what properties they desire, but the PropertyTypes themselves do not have hard-coded properties on them
• Any token followed by a parentheses and a value or values would assign the tokens name as a property with those values. Example:

id: integer fun(123) notFun(456)  
//Results in:
{
    type: 'Integer',
    'fun': 123,
   'notFun': 456
}

• Any token that is not followed by a parentheses receives the value of true. Example:

id: integer amazing unique primaryKey 
//Results in:
{
    type: 'Integer',
    amazing: true,
    unique: true,
    primaryKey: true
}

The ObjectPropertyType does not have any tests written. Tests should go in src/lib/PropertyTypes/ObjectPropertyType.spec.ts. Please reference other *.spec.ts files for conventions.

The IntegerPropertyType does not have any tests written. Tests should go in src/lib/PropertyTypes/IntegerPropertyType.spec.ts. Please reference other *.spec.ts files for conventions.

types:
graphql:
UniqueIdentifier: ObjectID
mongoose:
UniqueIdentifier: ObjectID

Should merge in replacements on top of the type mappings loaded from @gatewayapps/cradle-type-mappings