transloadit / uppy Goto Github PK

The user uploads his own, maybe private data.
So they have to trust the website and the things going on there during upload procedure.

For giving them this feeling he need the information

• what is going on - see #62
• are the right things going on / done by them - see #61

and in addition
they need to have the feeling -and for this the possibility to control the things going on.
every time.

This could be achieved by

• giving/showing a possibility to cancel the upload during the uploading process
• giving/showing a possibility to delete uploaded files (of not already processed further e.g because of waiting for other uploads)
• giving/showing a possibility to delete files chosen but not uploaded yet (if this is possible in uploading procedure)

Maybe one could adopt / learn some interesting things
from https://github.com/enyo/dropzone
e.g.regarding

• drag & drop
• abort function
• progress visualisation
• showing previews
• and useful config options:
  http://www.dropzonejs.com/#configuration-options

may help to reinvent the wheel in all details again...

Would be perfectly match to other awesome planned features of uppy!!!

Currently, Hexo will take sass/css, html, etc files from ./website/src, transpiles, and injects them into ./website/public.

Then we have a watch-examples.js file, that takes ./website/src/examples/*/src/js/*.js, transpiles, and injects them into ./website/src/examples/*/static/js/*.js.

I just found this hexo plugin: https://github.com/townewgokgok/hexo-renderer-babel/blob/master/index.js

It would allow us to use es6 code inside ./website/src/examples/*/js/*.es6 which would then be transpiled into ./website/public/examples/*/js/*.js. This way we could:

• only keep '1 tab open' as hexo could do all the watching and transpiling of example code(?),
• remove ./website/src/examples/*/static/ folders
• have building in line with how we're already handling the other assets (html/sass and even markdown/ejs I suppose).

My proposal would be trying to see if we can let hexo take care of babel, instead of a custom local script for examples.

If needed I could try to get this to work myself, seeing as how @arturi is focussing other website improvements and @hedgerh on the server component now.

+1 / -1 ?

It would be cool if preview would automatically trigger a watch, but the problem is that preview is blocking. The workaround currently is having 2 tabs open - but maybe there's something smarter we could do?

hmm I'm sure I did opened it in different browsers yesterday.
When I wanted to look in more details in it today, it doesn't open any more (FF,IE,Opera)

• Npm scripts
• ES6->5 transpiling
• package.json
• sass

The 'surroundings' (html etc) could be in ./examples/X. It should use a transpiled version of the project. .travis.yml needs to upload both so we can easily review online as well as locally.

Fast iterations are paramount here. No manual steps

possibility to restrict upload form same client in an easy way

for

• usability (make user know what is expected),
• load handling and
• security reasons

possible restrictions:

• allowed filetypes (whitelist)
• max number of file size (each) - if already know at start of upload
• max number of files simultaneously

and maybe also

• max number of files within a defined period (e.g. 10 per hour)
• parts of filename: blacklisted words and unwanted characters like " ", "ü"...
  (not that user-friendly but sometimes necessary because of system restrictions...)
• min number of file size (each)
  e.g. for first instance image quality check (no one wants to print a 1kb jpeg) and of course for security (no upload of tiny scripts is need)

give always a message why upload is not working anymore

6b10341#diff-a5d451cf6049b41234206c1ad2a59f94R6 — to add action attribute to a form, I need to know where the form will submit its data. In this case only Tus plugin knows about that, since it’s the uploader.

Could be solved via the separate form data plugin? If not, let's forget about form data in this plugin for now and make it work via files only.

I wanted to make sure forms can be submitted even when JavaScript is disabled / not yet loaded. But now that I think about it, we handle the markup with JS already. Is it a right thing to do? Slow connections exist, if we add <form> markup by hand it’s not that pretty for developers, but better for semantics and users.

It would be cool if the community could add support for additional languages beyond English easily.

How to best approach this with the plugin-based architecture is an unanswered question. Maybe we can research how do other similar projects do it? (I'm suspecting Vue.js may have support for Chinese for instance 😄)

Currently, when Uppy is run, it runs a waterfall of series of plugins — waits for some files to be selected from, say Instagram and DragDrop — and then exits. How do we make it continue accepting files after it has finished it’s initial run? The way it’s usually done is that there is a permanent event listener set up.

Made some interesting progress on the Dropbox plugin.

Flow

So here is the flow that I have in mind for the plugin to be used. oAuth authentication is still a question mark.

1. User calls uppy.use(DropboxPlugin)
2. User calls DropboxPlugin.connect('#target', optionalCustomRenderFunction) to start the plugin on a target DOM element.
3. If enduser is auth'd, fetch their Dropbox root '/' directory. If not, do oAuth.
4. On successful fetch of root directory, pass the result array to a built-in render method or a custom render function provided by the user to display folders/files.
5. Add event listeners for fetching a directory's contents or for selecting a file to upload.
6. On file select, plugin call DropboxPlugin.addFile method to add file to list of files to upload internally.
7. User calls uppy.start()
8. Uppy calls on a method like DropboxPlugin.getUploadInstructions() to get the necessary interface for being able to fetch the file.

To get a file from Dropbox, you make a GET request to content.dropboxapi.com to a /files endpoint, so somehow we're going to need to have the upload target server make that request.

Some type of names of uploaded files may potentially break something.

For these filenames a procedure is need to optimize problematic file names
(if not wanted to be caught by possibility to restrict upload #69)

At least two cases:

• containing characters that may break something (depending on systems used...)
  (like " " or "ü" or one of these ! * ' ( ) ; : @ & = + $ , / ? % # [ ])
• having a length that may break something e.g. longer than 255 characters

for ideas see
https://stackoverflow.com/questions/146134/how-to-remove-illegal-characters-from-path-and-filenames

this should work hand in hand with #71

Enable on existing forms, just like the jquery-sdk

What is everyone's thoughts about browser sync? It will be useful when we need to check our CSS in multiple browsers/devices. I went ahead and added it to the project in my PR, but if anyone feels strongly against it we can switch back. 🐙

PR: #16

Forked from #9 - Create an example Instagram plugin (doesn't have to work well, just for the structure).

tus at the core of uploading (see https://github.com/tus/tus-js-client)

Feedback on things going on is always important.

When uploading a file at least these points are interesting:

• how long will it take until complete (most important)
• how big is the file in total I'm uploading (important, if you're paying for mobile data or have a limit per month)
• how big is the part already uploaded (interesting/motivating)
• how fast is it loading (only interesting)

some ideas on implementing progress bars in an efficient way:
https://css-tricks.com/html5-progress-element/

Consider the following scenario:
http://hedgerh.github.io/fileupload-demo/

A template is generated on the fly when the user selects which option they want to use. For the case of the drag n drop plugin, it needs a target element to designate the drop area, but that target does not exist statically on the page.

So if we used something like:

Transloadit
  .use(dragdrop, { target: 'dragarea' })
  .use(instagram)
  .use(dropbox)

it's not going to work. We'll need to apply the drag drop plugin to the element every time it regenerates.

Thoughts?

Repo link:
http://github.com/hedgerh/fileupload-demo

I found out that we can use a --standalone Transloadit flag with browserify to easily create a UMD module. That means our transloadit-js-client.js dist file would be used globally like so:

<script src="transloadit-js-client.js"></script>
<script>
  var transloadit = new Transloadit();
  transloadit
    .use(Transloadit.InstagramPlugin)
    .use(Transloadit.DragDropPlugin)

  // or
  transloadit
    .use(Transloadit.TransloaditBasic)
</script>

Keep in mind this is only if someone downloads the distributable file, rather than using the lib build through npm. The lib build is simply a transpiled version of all of the core / plugins files. Will be pushing a PR soon, but wanted to open this up for any discussion regarding the build system so everyone was on the same page.

Currently, the client is going to use a pluggable architecture that allows integration from third party APIs like so:

transloadit
  .use(dropbox)
  .use(googleDrive)

There are two major use cases for the transloadit client:

1. Upload files to Transloadit with the help of the transloadit client UI
2. Upload files to Transloadit with a custom UI

What will the transloadit plugins need to provide in both of these cases?

It seems the process can be abstracted as follows:

input file -> modifications/configuration -> uploading -> server-side processing -> output

there is a problem on http://uppy.io/examples/dragdrop/index.html
drag & drop a file to right box, press upload button and you see an error

for things like "possibility to restrict upload" #69 (and many others)
it would be great to have a possibility
to define these things global per website and per each uploader instance visible on the site

Sometimes there maybe even be 2-3 uploader instances on a single url
where each need different settings...

Subtodos:

• Improve layout on Mobile (#37)
• Get it in line with our Contributors Guide (sass)
• Get comfortable changing any aspect
• Screenshot sounds great
• Improve homepage content (also the feature/icons)
• Fix Guide content (remove pages that aren't about Uppy)
• A generator for API docs too (research what exists already)
• Pick a nice new font
• Pick some nice new colors (we might revise with M ilan but that's easy to change (see $primary color in .styl files for instance)
• Slap new logos on top (we'll wait on M ilan for this)

It's always nice to have some visual feedback, if one is doing right (choosing right file)

Of course a preview of a file after upload is nice,
but it's more important to have a confirmation for doing right as early as possible in upload process.

This could done by showing

• file name
• file type
• file size (this also helps to have a feeling needed upload time...)

To enhance visualisation of filetye and have a good fitting, nice looking "symbol" for a file during (from very first start) and after successful upload
maybe one can make it easy to use font awesome icons for this.

e.g.

zip, rar,... https://fortawesome.github.io/Font-Awesome/icon/file-archive-o/

mp4,mov,... https://fortawesome.github.io/Font-Awesome/icon/film/

mp3, wav,... https://fortawesome.github.io/Font-Awesome/icon/file-audio-o/

photos, images,... https://fortawesome.github.io/Font-Awesome/icon/file-image-o/

pdf https://fortawesome.github.io/Font-Awesome/icon/file-pdf-o/

txt https://fortawesome.github.io/Font-Awesome/icon/file-text-o/

php, html,... https://fortawesome.github.io/Font-Awesome/icon/file-code-o/

excel https://fortawesome.github.io/Font-Awesome/icon/file-excel-o/
word https://fortawesome.github.io/Font-Awesome/icon/file-word-o/
powerpoint https://fortawesome.github.io/Font-Awesome/icon/file-powerpoint-o/

Modal upload: text is invisible on first open
coming back it's there

With this I couldn't get that I'm not directly on the page/tab to drag&drop files...

http://uppy.io/examples/modal/index.html

Would be very handy at this state of project if one would release new minor versions very often (e.g roughly once per week or every 25 commits) and keep demo up to date to latest released version.

With this one could easily comment on new things happen and report ideas/issues.

If needed because v1.0 is coming to fast, one could ad a digit in numbering -> x.xx.x ;-)

at this time there are 47 commits to master

=> what do you think?

I'm thinking a bit about how the processing/transform plugins are going to need to work. The following API (just an example) is not going to suffice:

Uppy
  .use(DragDrop, { target: 'foo' })
  .use(UppyResize)
  .use(UppyRotate)
  .use(UppyCrop)

Given that transforms need to run in a very specific order, I think the best approach is to turn processing plugins into functions, rather than classes, unless there is some reason we actually need classes in the instance, which I don't think we do. We can then provide the developer with the following API:

Uppy.apply(resize(800,600))

Where .apply(), or whatever we want to call it, chains together all of the transform functions in the order in which they are provided.

If our file uploader has a photo editor that allows the user to make changes to an image before uploading, the transforms need to be ran in a very specific order to get the desired processed image.

Consider the following image:

If I run:

Uppy.apply(resize(800, 600))
.apply(rotate(90))

I get:

If I run:

Uppy.apply(rotate(90))
.apply(resize(800,600))

I get:

This is also the best approach to the API because some transforms will need to be applied more than once, like if you resize, crop, rotate, then resize an image.

Many operations will take time. Sometimes we can't estimate accurately how much. We need to have a UI component that all plugins can use, that signals to the user we're happily processing their data.

I think this could be one of the 'utilities' exposed by 'core'?

Deploys all branches somewhere on every push, so we have a central place to look at and discuss.

I noticed post-css used them. Is it helpful?

There are some circumstances a button/possibility to manually pause a large, long time running upload and resume it afterwards would be really helpful:

1. total upload bandwidth is limited and one need it for other things
2. one is leaving office/home and change the network (WIFI->3G) and had to pay for traffic/has limited traffic per month
3. a combination of 1) and 2): one is leaving office/home and change the network (WIFI->3G) and the upload bandwidth is smaller but one need t for other things
4. other uploads have higher prio and should use it's bandwidth
5. as a possibility to communicate that an upload is able to be resumed
   (to the user who does not know that this is possible)
6. ...

don't know exactly if this kind of button/possibility may be also interesting for other "not from local" uploads (for other reasons)

Can we have the option to know the progress of each file uploading?

Of course it's a very early stage, but at this time in modal upload there is no single sign of a file visible.
After drag&drop a file everything still looks the same as if there is no file.
But upload seem to work :-)

If not already implemented a procedure to handle uploads with same name is need.
This may occur
by uploads

• from different users e.g. very common things like "christmas-2015.mp4"
• from same user e.g. when he/she uploads an image and after that he noticed something is wrong with it, corrects the problem and uploaded it again (without changing file name)

Tests on all main browsers from the start (see https://github.com/tus/tus-js-client)

Maybe have a look at dropzone - many of their users have coincidentally asked for Transloadit integration already

Discussion began here: 6b10341#commitcomment-15725322

Should Formdata object be available in every selector plugin like DragDrop and passed to uploaders which might use it or not, or should we use some Formdata-forming function in plugins like Multipart that actually need it?

It would be cool if the sandbox looked a bit prettier. It would also be cool if our css adhers to some standard.

What are your opinions on using / compatibility with:

• bootstrap
• foundation
• skeleton
• something else?

I would propose creating an architecture branch that adds an ARCHITECTURE.md and perhaps some code already. This could then be turned into a PR that we could all comment on to evolve this

As discussed in #19 and #9 and in Slack, we finally agreed on the following structure: https://github.com/transloadit/transloadit-js-client/blob/f1aa1072d5159c372624a57d5a8edaad2119efa9/classes.es6#L71

Meaning: TransloaditBasic is a plugin - that applies a convenient set of other plugins so novices won't have to do much wiring together to get basic jquery-sdk-like (#6) functionality.

Ideas for functionality:

• tus 1.0 uploading to Transloadit (you can use master.tus.io:8080 for testing)
• drag & drop enabled
• modal by default
• progress bar(s) enabled

Discussion began here: 6b10341#commitcomment-15725370

We need an option to only advance to files uploads when certain event occurred — like a button has been pressed, rather than just “any number of files have been selected”. Kevin suggested we call it autoNext. Should it accept some sort of trigger selectors or maybe events?

Example implementation here: 6b10341#diff-951c517b9354c6fbc4e9fc87e2344d45R139.

I think for simple file uploading - we may not want to default to using modals.

Look at this example of someone integrating with Transloadit with minimal impact / blocking UI:

https://github.com/pamelafox/bootstrap-transloadit-plugin <-- it has a link to an example, but the bootstrap layout is broken. normally you'd see a progress bar right on the page

For instance, this should have been caught by the test:

I would propose making a branch that deliberately tries to make Travis unhappy - until it does. Then remove the failure and merge the test plumbing back into master