filepicker.makeDropPane和FPFile "key“属性

Question

根据文件管理器web文档，filepicker.pick将不再将key作为传递给onSuccess回调的FPFiles的属性返回。

由于filepicker.pick似乎是最通用的api调用，它似乎代表了其他api调用的未来变化。

这让我怀疑FPFiles传递给filepicker.makeDropPane中的onSuccess回调函数是否也将不再获得key属性。文档在filepicker.makeDropPane区域中没有注意到这一点。

文档中也没有任何内容说明将图像备份到S3是否是在使用filepicker.makeDropPane时可以指定的选项。我确实希望这样的事情发生，而且它运行得很好，但我并没有指定任何布尔参数来表示filepicker应该为我做到这一点。这让我担心，在某个时候，文件报警器可能会改变引擎盖下的默认行为，在没有警告的情况下破坏我的应用程序。

filepicker.pick的文档声明：

注意："key“参数被取消，并将很快被移除。如果要在选择后立即存储文件，请使用filepicker.pickAndStore调用。

好吧，很高兴了解filepicker.pick，但是filepicker.makeDropPane呢？有计划的filepicker.makeDropPaneAndStore吗？会有其他方法来指定自动上传到S3吗？filepicker.makeDropPane将永远自动上传到S3，没有指定的原因？或者我们应该像对待filepicker.makeDropPane一样对待filepicker.pick，假设它没有上传到S3，然后在每个FPFile上传之后调用filepicker.pickAndStore？如果是这样的话，我们什么时候应该做这个改变，因为现在它已经被自动上传到S3了，所以现在它是多余的，而且我们会复制每个S3上传？

除了这些问题之外，当前传递给FPFiles的onSuccess回调的filepicker.makeDropPane具有一个无文档的id属性。这个id属性并不是唯一的--对于每个FPFile都是一样的。这会改变到独一无二吗？我们应该避免使用这个吗？如果没有记录的话，为什么会在那里？

我们应该使用哪个FPFile属性来实际跟踪本地的FPFiles？url

Answer 1

正确的解释是，makeDropPane需要更明确的声明来存储上传到“未来验证”的实现，我建议添加一个{store_location: "S3"}作为选项，这将向我们表明上传应该存储到S3中(而不是S3，等等)，并保证返回key。

关于id属性，如果您有更多有用的细节(或篡改等)，我将不会看到这种行为。