Uppy is a sleek, modular JavaScript file uploader that integrates seamlessly with any application. It’s fast, has a comprehensible API and lets you worry about more important problems than building a file uploader.
Fetch files from local disk, remote URLs, Google Drive, Dropbox, Box, Instagram or snap and record selfies with a camera
Preview and edit metadata with a nice interface
Upload to the final destination, optionally process/encode
Lightweight, modular plugin-based architecture, light on dependencies ⚡
Resumable file uploads via the open tus standard, so large uploads survive network hiccups
Supports picking files from: Webcam, Dropbox, Box, Google Drive, Instagram, bypassing the user’s device where possible, syncing between servers directly via @uppy/companion
Works great with file encoding and processing backends, such as Transloadit, works great without (all you need is to roll your own Apache/Nginx/Node/FFmpeg/etc backend)
Sleek user interface ✨
Optional file recovery (after a browser crash) with Golden Retriever
Speaks several languages (i18n) 🌍
Built with accessibility in mind
Free for the world, forever (as in beer 🍺, pizza 🍕, and liberty 🗽)
Cute as a puppy, also accepts cat pictures 🐶
Installation
npm install @uppy/core @uppy/dashboard @uppy/tus
Add CSS uppy.min.css, either to your HTML page’s <head> or include in JS, if your bundler of choice supports it.
Alternatively, you can also use a pre-built bundle from Transloadit’s CDN: Edgly. In that case Uppy will attach itself to the global window.Uppy object.
⚠️ The bundle consists of most Uppy plugins, so this method is not recommended for production, as your users will have to download all plugins when you are likely using only a few.
If you’re using a bundler, you need to import them before Uppy:
import'core-js'import'whatwg-fetch'import'abortcontroller-polyfill/dist/polyfill-patch-fetch'// Order matters: AbortController needs fetch which needs Promise (provided by core-js).import'md-gum-polyfill'importResizeObserverfrom'resize-observer-polyfill'window.ResizeObserver??=ResizeObserverexport{default}from'@uppy/core'export*from'@uppy/core'
If you’re using Uppy from CDN, those polyfills are already included in the legacy
bundle, so no need to include anything additionally:
Having no JavaScript beats having a lot of it, so that’s a fair question! Running an uploading & encoding business for ten years though we found that in cases, the file input leaves some to be desired:
We received complaints about broken uploads and found that resumable uploads are important, especially for big files and to be inclusive towards people on poorer connections (we also launched tus.io to attack that problem). Uppy uploads can survive network outages and browser crashes or accidental navigate-aways.
Uppy supports editing meta information before uploading.
Uppy allows cropping images before uploading.
There’s the situation where people are using their mobile devices and want to upload on the go, but they have their picture on Instagram, files in Dropbox or a plain file URL from anywhere on the open web. Uppy allows to pick files from those and push it to the destination without downloading it to your mobile device first.
Accurate upload progress reporting is an issue on many platforms.
Some file validation — size, type, number of files — can be done on the client with Uppy.
Uppy integrates webcam support, in case your users want to upload a picture/video/audio that does not exist yet :)
A larger drag and drop surface can be pleasant to work with. Some people also like that you can control the styling, language, etc.
Uppy is aware of encoding backends. Often after an upload, the server needs to rotate, detect faces, optimize for iPad, or what have you. Uppy can track progress of this and report back to the user in different ways.
Sometimes you might want your uploads to happen while you continue to interact on the same single page.
Not all apps need all these features. An <input type="file"> is fine in many situations. But these were a few things that our customers hit / asked about enough to spark us to develop Uppy.
Why is all this goodness free?
Transloadit’s team is small and we have a shared ambition to make a living from open source. By giving away projects like tus.io and Uppy, we’re hoping to advance the state of the art, make life a tiny little bit better for everyone and in doing so have rewarding jobs and get some eyes on our commercial service: a content ingestion & processing platform.
Our thinking is that if only a fraction of our open source userbase can see the appeal of hosted versions straight from the source, that could already be enough to sustain our work. So far this is working out! We’re able to dedicate 80% of our time to open source and haven’t gone bankrupt yet. :D
Does Uppy support S3 uploads?
Yes, please check out the docs for more information.
Can I use Uppy with Rails/Node.js/Go/PHP?
Yes, whatever you want on the backend will work with @uppy/xhr-upload plugin, since it only does a POST or PUT request. Here’s a PHP backend example.
And you’ll need @uppy/companion if you’d like your users to be able to pick files from Instagram, Google Drive, Dropbox or via direct URLs (with more services coming).
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'?
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.
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)
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.
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)
There are some circumstances a button/possibility to manually pause a large, long time running upload and resume it afterwards would be really helpful:
total upload bandwidth is limited and one need it for other things
one is leaving office/home and change the network (WIFI->3G) and had to pay for traffic/has limited traffic per month
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
other uploads have higher prio and should use it's bandwidth
as a possibility to communicate that an upload is able to be resumed
(to the user who does not know that this is possible)
...
don't know exactly if this kind of button/possibility may be also interesting for other "not from local" uploads (for other reasons)
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 ;-)
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.
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
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)
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.
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.
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
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
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.
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
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 :-)
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.jsdist 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.
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?
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...
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.
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. 🐙
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 😄)
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.
User calls uppy.use(DropboxPlugin)
User calls DropboxPlugin.connect('#target', optionalCustomRenderFunction) to start the plugin on a target DOM element.
If enduser is auth'd, fetch their Dropbox root '/' directory. If not, do oAuth.
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.
Add event listeners for fetching a directory's contents or for selecting a file to upload.
On file select, plugin call DropboxPlugin.addFile method to add file to list of files to upload internally.
User calls uppy.start()
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.
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?
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?