jonjamz
Remove `instructions` extension for simple-schema
Now that the {{schema}} helper in Element templates allows all schema fields to be accessible, a package-provided extension to simple-schema fields is unnecessary.
Such an idea could be presented in the docs as part of a section on working with simple-schema.
Already, I can see how instructions is insufficient for some uses--for example, where you want to have placeholder text in an input and an example below the input. It's out of this package's scope to solve for all use cases involving these types of additional fields.
You could do what autoform does and introduce something like a 'forms' field to SimpleSchema. Users could then add whatever fields they need to that. You could provide a pass-through mechanism for parameters, so you don't have to prefix everything with 'forms.'
new SimpleSchema({
name: {
type: String,
label: 'Name',
max: 40
forms: {
placeholder: 'Your name...',
helpText: 'Name is a required field with a maximum length of 40 characters.'
}
}
}
@jcheroske, could you please elaborate? Why is it necessary to add a specific field named 'forms'? Why not just add whatever field I want in the schema and use it from templates:forms?
Wouldn't a specific field represent an extra and unnecessary link with SimpleSchema?
What if I use several form packages: would I need to duplicate my properties in several custom fields like 'forms', 'super-forms' and 'extra-forms'?
Suppose I need a new property in my schema, which I want to use both in my forms and my database. Why would I want to store this in a 'forms' field?
Good questions! It's all just about pros and cons I guess. Your criticisms are pretty much spot on, and I think in general you are correct. The issue really boils down to, "Do I want to just add whatever to my core schema, or do I want that info in a sub object?" And also, "Is the info tied to a specific library?" I don't really have much problem with putting placeholder text in the schema, but if there was a bunch of view-related stuff, I think putting it in a 'view' sub-object would make things cleaner. But, like you alluded to, that can be left up to the developer. In autoForm, there were a handful of config options that could be tied to a specific field via an 'autoForm' object in the schema. Maybe Forms doesn't need it now, but going forward it might be something to keep in mind as a possibility. Like, maybe you want to be able to specify the validationEvent on a per-field basis. Being able to say:
new SimpleSchema({
name: {
type: String,
label: 'Name',
max: 40
forms: {
validationEvent: 'keyup'
}
}
}
might come in handy. Idk.
I think the amount of things you should specify in SimpleSchema should be fairly limited--even specifying placeholder text there might be a bad design practice. I'm all for reusability and simplification, though.
Fields relating to createElement or createFormBlock should probably not be specified at the schema-level. In the case of validationEvent, one element might respond on keyup and another might respond when you click a button and then use validationValue to get a combination of a text input and a select box and form the data a certain way.
Aside from it being impractical to write this kind of logic in the schema, an implementation that allows such functionality would also create additional coupling between this package and SimpleSchema, which I want to keep to a minimum.
Happy to see any other examples that might be useful though!
Just had a surprise realising that it is not a blackbox. :+1: for removal.
