根据filepicker网站文档，filepicker.pick将不再返回key作为传递给onSuccess回调的FPFiles的属性。
由于filepicker.pick似乎是最常见的api调用，因此它似乎代表了其他api调用可能会如何改变。
这让我想知道传递给FPFiles中的onSuccess回调的filepicker.makeDropPane是否也将不再获得key属性。该文档未在filepicker.makeDropPane区域中对其进行说明。
文档中没有任何内容表明将图像备份到S3是否可以在使用filepicker.makeDropPane时指定。我确实希望这种情况发生，它工作正常，但我没有指定任何布尔参数，说filepicker应该为我做这个。这让我担心，在某些时候，filepicker可能会改变引擎盖下的默认行为，在没有警告的情况下破坏我的应用程序。
filepicker.pick州的文档：
注意：“key”参数已弃用，很快就会删除。如果 你想在挑选后立即存储文件，使用 filepicker.pickAndStore call。
嗯，关于filepicker.pick很了解，但是filepicker.makeDropPane呢？是否有计划filepicker.makeDropPaneAndStore？是否还有其他方法可以指定自动上传到S3？ filepicker.makeDropPane会永远自动上传到S3，没有特定原因吗？或者我们应该将filepicker.makeDropPane视为filepicker.pick，并假设它不会上传到S3，并在上传后为每个filepicker.pickAndStore致电FPFile？如果是这样，我们应该何时进行更改，因为现在它已经是多余的，因为它已经自动上传到S3，我们将复制每个S3上传？
除了这些问题之外，目前传递给FPFiles onSuccess回调的filepicker.makeDropPane还有一个未记录的id属性。此id属性不是唯一的 - 每个FPFile都是相同的。这会变成独一无二的吗？我们应该避免使用它吗？如果没有记录，为什么会出现呢？
我们应该使用哪个FPFile属性来实际跟踪FPFiles本地？ url？
答案 0 :(得分：1)
你在解释makeDropPane需要更明确地声明存储上传的位置时是正确的 - 为了“面向未来”的实现，我建议添加{store_location: "S3"}作为选项，这将是告诉我们上传应该存储到您的S3中（而不是机架空间等），并保证我们返回key。
关于id属性，我没有看到这种行为，如果你有任何更多细节（或jsfiddle等）会有所帮助。