Better automatic (passed through) options for a select, radio, checkboxes

[zeroasterisk]

For example, here's a standard Enum based "select" field with allowedValues & autoform.options

{ ...
  fileType: {
    type: Number,
    label: 'File Type (Upload, processing, tmp, log, etc)',
    optional: true,
    allowedValues: Enums.Buckets.fileTypes.values(),
    autoform: {
      options: Enums.Buckets.fileTypes.options(),
    },
  },
... }

I have this functionality somewhere -- I'll see if I can dig it up...

[radekmie]

Currently, props can be declared in SimpleSchema (it's covered here) within uniforms key.

Idea:

{ ...
  fileType: {
    type: Number,
    label: 'File Type (Upload, processing, tmp, log, etc)',
    optional: true,
    allowedValues: Enums.Buckets.fileTypes.values(),
    uniforms: {
      options: Enums.Buckets.fileTypes.options(),
    },
  },
... }

Yes, I've just changed autoform to uniforms.

But to keep compatibility with existing SelectField components, it will be interpreted as:

if (_.isObject(options)) {
    options = Object.keys(options).map(label => ({label, value: options[label]}));
}

transform = value => (options.find(option => option.value === value) || {label: value}).label;

So it will be easier to transition from aldeed:autoforms to uniforms and create another SelectField components, without special logic.

What do you think, @zeroasterisk?

[zeroasterisk]

I think that sounds fine...

For ease of use, for people migrating from aldeed:autoforms to uniforms I think supporting whatever they support would be ideal, but limited scope is reasonable. (omitting helpers support)

I also think it (and all ported config) should be a cascading config:

pseudocode: options = uniforms.options || autoform.options || undefined

[radekmie]

Yes, that options: function () { ... } option is quite neat.

---

I thought about allowing autoform key in schema (with some warning of course), but it should be discussed. If you really need it - create another issue and let's discuss it.

[serkandurusoy]

I think naming consistency is important. If we are using the component as <AutoForm ..../> then the corresponding key on the schema should be the same. If we use uniforms on the schema, then we should probably name the component <UniForms ... />

[radekmie]

@serkandurusoy: <UniForm />?

Ha, I thought the same at the beginning! But if you are new and want to know, what each form is doing... What <UniForm ... /> or <Uniform ... /> is doing, while there are <BaseForm ... />, <QuickForm ... /> and other, well named ones?

[serkandurusoy]

I don't see an example that uses anything other than AutoForm, so why not call it Uniform:

// These are equivalent:

const FullAutoForm = () =>
    <AutoForm schema={PostSchema} onSubmit={doc => console.log(doc)} />
;

const SemiAutoForm = () =>
    <AutoForm schema={PostSchema} onSubmit={doc => console.log(doc)}>
        <AutoField name="category" />
        <AutoField name="authors" />
        <AutoField name="publishedDate" />
        <AutoField name="published" />
        <ErrorsField />
        <SubmitField />
    </AutoForm>
;

const ExplicitAutoForm = () =>
    <AutoForm schema={PostSchema} onSubmit={doc => console.log(doc)}>
        <SelectField name="category" />
        <ListField name="authors">
            <ListItemField name="$">
                <NestField>
                    <TextField name="name" />
                    <NumField  name="age" />
                </NestField>
            </ListItemField>
        </ListField>
        <DateField name="publishedDate" />
        <BoolField name="published" />
        <ErrorsField />
        <SubmitField />
    </AutoForm>
;

I believe quickform is just redundant and should not be used. Baseform is a "developer" friendly component that should be used to creat custom top level form components. and UniForm should be our official top level component "implementation" and not be named autoform

[radekmie]

Yes, that would make sense if uniforms would be Meteor-only packages, but they're not. I'm a fan of semantic naming, so every form component is named after his role.

Yes, those intermediate forms are mostly unused, but in my first draft were only Base, Quick and Validated forms - Auto is just a helper, that is the easiest to use (that's why others are described only on inheritance graph).

[serkandurusoy]

Ok, then the question is, what's your suggested best practice? Do you
suggest that we use quickform, validatedform etc?

Using helper/shorthand names is not always a great thing due to the
abstraction it creates.

But if the separate components don't offer much value out of the context of
Meteor, than perhaps we should document this and the usecases.

(Now that I'm thinking about the docs site and examples, I think we should
hear more about your reasonings behind your choices anyway)

On Thu, Jun 9, 2016 at 8:27 PM, Radosław Miernik notifications@github.com
wrote:

Yes, that would make sense if uniforms would be Meteor-only packages, but
they're not. I'm a fan of semantic naming, so every form component is named
after his role.

Yes, those intermediate forms are mostly unused, but in my first draft
were only Base, Quick and Validated forms - Auto is just a helper, that
is the easiest to use (that's why others are described only on
inheritance graph).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#23 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AEbz3GZ4SwPI3aAB61040dDMML_ZIq-Dks5qKEz3gaJpZM4IyJse
.

[radekmie]

Use what you need, really.

About other forms... In short (I want to write more about it in the documentation, or maybe in some Medium post...) - every *Form (without BaseForm) exposes a static method called * (Quick for QuickForm, etc.). It can be used to extend functionality of given component (look at ValidatedQuickForm source!). That's why they are completely separated.

[zeroasterisk]

Thanks @radekmie -- so to use this, it should be a simple as changing autoform.options to uniforms.options in my schema, right?

[radekmie]

Yes.