Expand on the set of pre-built elements

[steph643]

This would be great, but could also bring confusion. There could be hundreds of pre-built elements, using several UI packages (bootstrap, etc). People could get to see your package as "yet another UI component library", overlooking the fact that they can easily customize each element if the want to.

Ideally, jonjamz:form would be kept as a thin form package, and element libraries would appear as separated entities ("extensions", "plugins", "external packages", I don' know).

I think you should keep the term 'pre-built' for basicIntput and basicFormModel.

[jonjamz]

I was thinking perhaps these would be good to include as well:

• Select element that can use SimpleSchema's allowedValues.
• Check box element.
• Radio button element.

They would be really basic. Of course, there should be separate packages for Bootstrap components and other more complex/complete offerings.

[steph643]

If you provide UI elements as part of the package, people will tend to see your package as a "UI component library". If provided elements are too basic, people will think your library sucks. If provided elements are sophisticated, people will think your library is too complex and/or does not fit their need.

Keep in mind that:

• Element implementation is tied to specific features you add to a schema (such as 'label', 'instructions', etc).
• There are hundreds of possible implementations, and yours will probably not satisfy most people. Will you add an "instructions" field and use it in the elements? Or an "smallInstruction" field to put on the right of the label and an "largeInstruction" one to put in a popover?

With a very basic use of your package, I already have something very specific:

<template name="bootstrapInput">
    <div class="form-group  {{#unless valid}}has-error{{/unless}}">
        <label class="control-label">{{label}}{{#if th_isMandatory}}<span style="font-weight: normal">*</span>{{/if}}</label>
        <input name="{{field}}" class="form-control reactive-element" value="{{value}}" style="{{style}}" maxlength="{{#if schema.max}}schema.max{{/if}}">
        <p class="help-block">{{#if valid}}{{instructions}}{{else}}{{errorMessage}}{{/if}}</p>
    </div>
</template>

function fieldIsMandatory(fieldSchema)
    {
    // If schema contains 'optional', then field is not mandatory
    if (fieldSchema.optional)
        return false;

    // If schema type is String and there is no 'min' in the schema (or min===0), then field is not mandatory
    if (fieldSchema.type === String && !fieldSchema.min)
        return false;

    return true;
    }

Template.bootstrapInput.helpers(
    {
    th_isMandatory: function()
        {
        return fieldIsMandatory(Template.parentData().context.schema._schema[this.field]);
        }
    });

See where this can lead you?

The more I think about it, the more I feel this is a trap, that will mislead users and bloat your package with schema extensions and specific design choices.

Here is my current conclusion: 1- I think your package should contain no built-in elements beyond basicInput. 2- Your documentation could point to a web site where everyone (including you) can propose their own component libraries, in the form of html/javascript code to copy/past and screen captures to show the result.

[Sivli-Embir]

:+1: to @steph643's thoughts. You could also provide a solution like useraccounts:core or even kestanous:herald. Where you provide core as a basic usage but have styles or logic as extension packages. I have found that to be a really nice way to have complex drop in logic that does not polite the core idea.

[jonjamz]

Thanks for your feedback guys. I really appreciate it. I will mark this issue as closed, and I will not add any more pre-built components. After all, basicInput is supposed to be an example, not something people actually use in their apps. Further examples could even exist in a blog post, and components meant for real use can be in external packages. There are so many possibilities with this package--that's part of what makes it so cool. I don't want to limit people.

[jonjamz]

@steph643 by the way, now that all schema fields are accessible inside an element, it makes adding the instructions field to simple-schema unnecessary. Of course this type of enhancement could always be in some sort of "recommendations" section in the docs, along with some other ideas for improving form UX.