filepicker.makeDropPane and the FPFile "key" attribute

0
votes

According to the filepicker web docs, filepicker.pick will no longer return key as an attribute of the FPFiles passed to the onSuccess callback.

Since filepicker.pick seems like the most general-case api call, it seems like it would be representational of how other api calls might be changing going forward.

This makes me wonder if the FPFiles passed to the onSuccess callback in filepicker.makeDropPane will also no longer be getting a key attribute. The documentation makes no note about it in the filepicker.makeDropPane area.

There is also nothing in the docs that says whether backing up your images to S3 is an option that you can specify when using filepicker.makeDropPane. I actually do want this to happen, and it's working fine, but I'm not specifying any boolean parameter that says filepicker should do this for me. This makes me worry that at some point filepicker may change the default behavior under the hood, breaking my application without warning.

The documentation for filepicker.pick states:

Note: the "key" parameter is deprecated and will be removed soon. If you want to store files immediately after picking, use the filepicker.pickAndStore call.

Well, that's good to know about filepicker.pick, but what about filepicker.makeDropPane? Is there a planned filepicker.makeDropPaneAndStore? Will there be some other way to specify automatic upload to S3? Will filepicker.makeDropPane forever upload to S3 automatically, for no specified reason? Or should we treat filepicker.makeDropPane like filepicker.pick, and assume it doesn't upload to S3, and call filepicker.pickAndStore for each FPFile after they're uploaded? If so, when should we make that change, because right now it'd be redundant since it's already uploading to S3 automatically, and we'd be duplicating each S3 upload?

In addition to these questions, currently the FPFiles being passed to the onSuccess callback of filepicker.makeDropPane have an undocumented id attribute. This id attribute isn't unique - it's the same for every FPFile. Will this change to being unique? Should we avoid using this? Why's it there if it's not documented?

Which FPFile attribute should we use for actually keeping track of FPFiles locally? url?

1
filepicker.io

1 Answers

1
votes

You're correct in interpreting that the makeDropPane needs a more explicit declaration of where to store the uploads - to "future-proof" your implementation, I'd recommend adding a {store_location: "S3"} as an option, which will signal to us that the upload should be stored into your S3 (as opposed to rackspace, etc.), and will guaranteeing that we return a key.

Regarding the id attribute, I'm not seeing this behavior, if you have any more specifics (or a jsfiddle, etc) that would be helpful.