Proposed API change for mappings

[mike-marcacci]

I'm finally getting a moment to work on my form builder, and one of its core goals is to closely integrate with schema-form whenever possible. One challenge I've come across is that while form elements (both standard and custom) are extremely flexible, they do not provide any metadata on how they are configured or used. This makes it quite difficult to create a builder or extension that's naive to the infinite possibilities of form elements.

As I quickly suggested in this issue, I'd like to formally propose that we switch a form element mapping declaration from a string to an object. In addition to the required type property, it should contain a json-schema of its possible configuration under the schema, and an optional form declaration under the form (defaulting to "*"), optional title, and optional description. This would elegantly solve #113, and would give the spec room to grow without further drastic API changes.

// old style (should maintain backwards-compatibility)
schemaFormDecoratorsProvider.addMapping(
    'bootstrapDecorator',
    'datepicker',
    'directives/decorators/bootstrap/datepicker/datepicker.html'
);

// new style defining title, description, schema, and form for configuration
schemaFormDecoratorsProvider.addMapping(
    'bootstrapDecorator',
    {
        type: 'datepicker',
        title: 'DatePicker',
        description: 'Datepicker add-on for Angular Schema Form using pickadate!',
        form: ['*'],
        schema: {
            type: 'object',
            properties: {
                minDate: {
                    type: ['string', 'null']
                },
                maxDate: {
                    type: ['string', 'null']
                }
            }
        }
    },
    'directives/decorators/bootstrap/datepicker/datepicker.html'
);

There's still more to think through, but I think this is a good starting point. I'd love to get feedback, as I'll probably be working on a fork of schema-form as I make the builder, and can play around with any suggestions.

Cheers! Mike

[davidlgj]

I like it! The same schema could be used for more than just the builder, maybe for docs generation, optional validation of the form etc.

Since the schema and form definition could end up being a bit large we might want to enable "runtime" builds that don't have them. Uglify has support for removing "dead" code which could be used. But that is an optimization we can make when needed.

[mike-marcacci]

Great! Glad to hear it. I had actually been thinking about that as well. In particular, there seem to be so many shared/standard fields in form definitions (like title, description, etc). I've been struggling with how to avoid repeating these in every form field, especially without schema-form support for allOfand anyOf (those won't totally solve this problem, but are probably the best place to start).

I'll definitely keep thinking about this!

[davidlgj]

Just a heads up @mike-marcacci, I'm trying to build more of the form upfront instead of relying on ng-repeat and <bootstrap-decorator> directives. It's in the development branch, It shouldn't affect you, I'm going for full backwards compatibility.

The plan is to deprecate addMapping (and add a new function) or make it so that it can take different sets of arguments. Your changes are of course still valid :)

[Anthropic]

@mike-marcacci Have you seen the builder functions that @davidlgj built that are available in the alphas?

Do you know how this would work best with them? Could this be handled in comment annotations or in some way that could be stripped out by a minifier or left in when used by a builder tool?