Forms, inputs and validation about guide HOT 24 CLOSED

I did just realize that with 1.3 having better support for NPM, it might be better to suggest a file upload solution from the NPM community.

from guide.

@tmeasday the action items from this should be added as separate issues if we are sure they should actually be done.

from guide.

👍 I've been having second thoughts about deprecating check as being the right call for this iteration of the guides however. What do you think?

from guide.

My only reservation is that then you won't be able to easily check stuff like the length of a string in a method argument, right?

from guide.

In a world where the method "checks" form the validate part of the method?

I guess I'm more thinking of trying to re-implement audit-argument-checks based on SS might be non-trivial. I'm not sure what the best approach is if we don't do it though.

from guide.

Proposed outline

1. How to write a method with proper permissions and validation (using methods package #54 and simple-schema)
2. How to call that method from the client side in various ways
3. How to build a simple form that calls the method
4. How to use autoform to build the form + show errors as they appear
5. How to do as-you-type error validation
6. How to handle optimistic form submission + it's implications (see UX chapter).
7. How to build a form automatically from a schema using autoform
8. How to handle file uploads:
   1. Over DDP
   2. Using CFS?
   3. w/ a 3rd party upload solution
   4. manually client side w/ something like S3?

from guide.

@stubailo not sure about

1. Using a method to call external APIs. It feels a little out of place...maybe we should have that APIs chapter after all?
2. Saving intermediate state if a user closes a tab -- do people do this? I've not done it before. Does autoform make it easy?

from guide.

1. Yeah I think that external integration article is starting to feel necessary. It could be a short one.
2. GitHub and Asana both do it. It's not easy, I just figured it's something a lot of apps would benefit from. Autoform already persists form content across hot reloads, perhaps it could be extended to do the same across longer periods? Maybe this goes in a section at the bottom like "things we would like to be easy, please build a package for this"

from guide.

Wow, I appreciate the love @stubailo. :)

Regarding check/ss, this has been supported for a long time:

check(obj, new SimpleSchema({ ... }))

(And gives more helpful errors than basic check patterns.) But if check method were built into SS, I guess it could be shortened to check(obj, {}) with the SS object instantiation being automatic.

AutoForm thoughts/roadmap:

• There are currently some sticky issues that require some backward-incompatible restructuring, so I'm hoping to release a major version update before the end of this year. This should finally get it to a point that I'm relatively happy with.
• Move bootstrap dependency to a separate package. Use plain templates as default.
• Add a better API for working with form state, etc., like AutoForm.form(id).field('name').isValid / isDirty / hasChanged / etc.
• As part of the one above, input types will now decide when they have changed. Currently the core pkg tries to guess when an input changes using change handler, but it is very buggy on certain types of inputs. This will fix issues with getFieldValue, etc.
• Decouple various pieces so that you can auto-render any component (input, quick field, etc.) without needing an autoForm wrapper or even a schema. This will allow use in places where you just want to render a field, a selection box, etc. using the same template you use elsewhere in the app, but you don't need full validation, submission, or any of that. You can just drop the component in the template and use reactive getFieldValue to adjust view as value changes.

After all that, I'm going to investigate either a release or a port to support React.

from guide.

major version update before the end of this year

What does this mean for the huge library of autoform plugins?

Move bootstrap dependency to a separate package. Use plain templates as default.
After all that, I'm going to investigate either a release or a port to support React.

Could this be accomplished as kind of a refactor to move the core logic into a place independent of the view layer somehow? I don't know exactly what that would mean, but it probably boils down to a consistent JS API for the different form components.

from guide.

I've attempted several times to figure out a way to separate form rendering, validation, and submission concerns into their own packages, but it's pretty impossible right now. That said, every change I make is with an eye toward that eventual goal.

I don't think there will be huge impacts on the add-on pkgs when releasing 6.0, but any that provide custom input types with tricky values will need to implement the new API for change tracking, basically emitting some custom event when the input value should be considered changed. And they will all have to update their dependencies to || 6.0.0

from guide.

@aldeed I think the love is totally warranted.

I should publish and point you at the react form component lib we built for Galaxy. I'll do that sometime soon. It's in no way as full-featured as autoform[1] but I suspect it has a lot of the same ideas, perhaps leaning more in the direction that we'd love to see autoform go in (and you are probably leaning also by the sounds of it).

[1] I actually don't think it's "correct" in the way it passes data between the form and the inputs, but that's a hugely technical discussion that is out-of-band here.

from guide.

Outline merged https://github.com/meteor/guide/blob/master/outlines/forms.md!

from guide.

I've written a tutorial on Constraint Validation in a Plain JS App, and I'd like to propose taking a similar approach in the Meteor Guide. The most important points are:

• Constraints have to be defined in the model (classes), and not in the UI
• Constraints have to be checked multiple times:
  • in the UI on input/change and before submit
  • in the model (class) code before save
  • possibly also in the DBMS before commit
• Responsive constraint validation in the UI should be done with the HTML5 constraint validation API using the two methods setCustomValidity and checkValidity.

Although I don't know much about Meteor (yet), I'd like to contribute material from my tutorial and co-author a corresponding Meteor validation tutorial.

from guide.

@tmeasday thanks for pointing me here in reference to files. Is CollectionFS still considered the best solution? My concerns with the package are the number of outstanding issues it has and that it doesn't seem to be maintained.

from guide.

@merlinpatt, honestly, I'm not sure. We wrote this outline a few months ago before the maintainer of CollectionFS decided to move on. What are other people doing?

from guide.

Looking up "file" or "upload" on Atmosphere returned the below, which I picked because they had the most downloads. I also just put a poll up on the forums about what people are using. I suspect most will say they're still using CollectionFS.

• orionjs:filesystem
• vsivsi:file-collection
• ostrio:files
• tomi:upload-server

from guide.

Are there full-stack npm file upload packages? FWIW, I chose https://github.com/CulturalMe/meteor-slingshot and works well for me

from guide.

Hi! Was article outline removed / relocated? The link goes to 404 now.

from guide.

Here's what it had: https://github.com/meteor/guide/blob/06094c8374a4f5b9035c23be5abdbf15b26e65e0/outlines/forms.md

Not too much stuff unfortunately.

from guide.

@stubailo I'd like to contribute if there are some guidelines on proper contribution )

from guide.

that would be amazing! first step is writing up an outline, perhaps based on that one, and submitting a PR for it.

from guide.

Yeah @romaroma that would be great! We have https://github.com/meteor/guide/blob/master/CONTRIBUTING.md
but it's not relevant for the outline stage – the file to edit for now is: meta/outlines/forms.md

from guide.

I'm closing this issue because it's too old.

We are going to make many updates to the guide in the next weeks and it's better to focus on issues with recent activity. If you think this issue is still relevant please open a new one.

from guide.