feature(storage): add storage API to app element

[locomuco]

adds storageURL support to firebase-app

[locomuco]

partly fix for #10

[rickymarcon]

.bind(this) :)

[mbleigh]

Thanks for the PR! Can you give me an example of how you'd expect people to use the storage behavior here? I'm still pondering the best way to bring storage into the mix and I'm not saying you don't have it just that I'm not sure what you're aiming at 😄

[locomuco]

@mbleigh since I think there won't be the "one" upload UI interface, I thought it might be a good idea, to provide a very generic low level interface as a base layer.. elements including the behaviour could just use the upload functionality, makes sense?

[bvhme]

At least this way we could just use the bare firebase.js with the App we instantiated in our firebase-app

[ghost]

I've forked a file-upload polymer element to work with the storage functionality added here

https://github.com/paultdf/firebase-upload

[locomuco]

@mbleigh just added a very basic demo to upload files, let me know, what you think about the general structure, and I'll move forward extending functionality

[tograd]

What's standing in the way of this merge?

[mbleigh]

I'm still evaluating what I think is the best way to incorporate storage,
so until I feel confident I don't want to merge an implementation only to
change it shortly afterwards.

On Wed, Jul 6, 2016, 5:26 AM reads [email protected] wrote:

What's standing in the way of this merge?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAAD_hKWkvwyiU072imoTYeuw3UBjifmks5qS58FgaJpZM4IuL2v
.

[tograd]

@mbleigh I understand that and I'm sorry to breath down your neck but I'd be remiss if i failed to mention how big of a feature this is, "polymerfire" is definitively feature-incomplete until it's in (even if just basic behavior)

[mshockwave]

Maybe we could merge the essential part of storage API(i.e storage-url in firebase-app) first and postpone storage operations(i.e firebase-storage) part? I agree with @mbleigh 's opinion but I also believe that there are lots of developers who use storage API are glad to hack their own storage operations logic but first they need to initialize storage url in Firebase App, which is impossible if there is no storage-url in firebase-app element.

[43081j]

Yes, you definitely should merge the storage-url in at least.

Currently, there is no way to use the storage API directly because you can't change an app after it has been instantiated. So this should be merged (the property only), and the (possible) addition of a storage element added in a separate PR.

The addition of the storage-url property will not change, so there should be no question/doubt about adding it.

[43081j]

This should have a default empty value, shouldn't it? the other properties are required for a functioning firebase app, this one is not. If we don't default it, I guess the app property is never computed unless we set storageUrl.

[locomuco]

👍 I'll add it

[tjmonsi]

I would like to check up on this as well. I was planning to have a firebase-storage that also works like firebase-document (and hopefully uses the same attributes/properties). What i had in mind though is this:

<firebase-storage
  id="storage-cloud"
  path="/cloud/[[dynamic_path]]"
  files="[[file_array]]"
  data="{{upload_tasks_array}}"
  ></firebase-storage>

The idea of the file_array is that it comes from input.files or an array of Files.

This is where it gets a bit tricky though... Do we save the files once it has been passed to the element or do we call a method like .save() to do the saving.

Regardless it will return an array of uploadTasks objects.. Each object is like this:

{
  progress: 0
  pause: function()
  load: function()
  dataUrl: 'url.jpg'
}

Either that or just return an array of uploadTasks and then people can do whatever they want...

Would it be possible to fork this PR and play with it and see what happens?

[mbleigh]

I've gone ahead and added storageBucket to firebase-app and released 0.9.4 -- this should unblock those who want to experiment without forcing me to early-merge. Thanks for bearing with me!

[tjmonsi]

@mbleigh Thanks. will create an issue and a PR once I have done my own experiments and let you see if it fits with the vision of the polymer element for firebase

[locomuco]

@tjmonsi you can fork from https://github.com/locomuco/polymerfire/tree/polymerfire-storage-api

[jaaki]

@tjmonsi , regarding whether to save files once it's passed to the element or to call a method like .save(),
both would be usefull. I'm thinking about how iron-ajax works, where we can set the 'auto' attribute for automatic execution or leave the 'auto' attribute out to allow manual execution.

[tjmonsi]

@jaaki already added that. I added an attribute called 'auto-upload' that if it exists, will auto-upload the files put in the files attribute.

There's a working system already here: https://github.com/tjmonsi/polymerfire/tree/adding-firebase-storage

and a demo here: https://practice-play-for-polymer-tjmonsi1.c9users.io/

I'm just adding one more case and I'm going to create some tests and will do a pull request for review

[polinom]

@jaaki demo is not working.. Try to load it in incognito mode, and you'll see what I see.

[tjmonsi]

@jaaki: Whoops i forgot... made it public now

[tjmonsi]

@polinom: my demo is public now for a bit (until I turn off the server).

[stemuk]

I don't want to push anybody but is their anything that prevents a merge? I tested @tjmonsi implementation and it worked just fine. Would be really helpful to know whats going on.

[woisme]

Would love to use the fork in a demo. Is there any reason I shouldn't?

[locomuco]

The fork is working, let me know if you find something unexpected or missing

[locomuco]

closed in favor of #69