In terms of how to use these methods, they have not changed. The only difference is that it has the capability to take a File object grabbed from the DOM (i.e. `<input type="file" />`).
File, Blob, and FileList are all valid in the model. Once set it will be uploaded when ready.
As the file is being uploaded, a trigger `progress` fires as the browser sends chunks of data. The `progress` trigger sends a progress status in percents.
If you want to force not using FormData, add the option `{ formData: false }` and the whether or not you have a file object in the model, it'll try to send it as part of the JSON object. Opposite is true (for whichever circumstance) is that if you set `{ formData: true }`, it will force the usage of FormData. Not setting it will leave it automatic and it'll try to detect if there is the file in the model.
This plugin will use the FormData class to wrap all the attributes in. That basically means it's making what we used to know as the old-fashioned "form" into a data object. The old-fashion "form" only took key-value pairs, so the same applies here. The attributes gets converted into a FormData object then is sent through as a "multipart/data-form". So it is recommended to use a flattened model for easier parsing as Jeremy Ashkenas himself usually recommends for all scenarios.
In the "test" folder (not finished yet), I included a PHP uploader just for testing purposes, but feel free to extend that. You have to figure out the file upload limitations, however.
## What happens to a model with nested objects/arrays?
The model will be flattened and the nested value will be separated with it's own unique composite "breadcrumb" key. The key parsing will reflect the array or object with the index or property respectively.
The plugin is non-destructive to the existing behaviors. When a file object is detected, then the method is tweaked and converted to a FormData object.