Modals by default? about uppy HOT 35 CLOSED

I think this really depends. I am sure a lot of people want the Dropbox, Drive, etc. functionality by default.

Not sure how we build this in, but it's easiest with a modal box sort of like Filepicker has it. Then there is one way of integrating things ... one button, one modal, several plugins shown there.

I think if we make this all too complicated with several ways of integration, people will get confused and turn away from the js client.

This is one of the most important discussions here. Let's decide this one very carefully. Maybe we can do without a modal and still provide useful plugins by default via additional buttons or so.

from uppy.

What about this flow:

• no modal
• click "Upload"/"Pick file" button
• modal with many different source options
• user picks the file
• configuration dictates if modal now also handles the progress bar etc, or that the modal closes and you return to the sites UI for dealing with progress and including finished files as they come in

from uppy.

What @kvz said. Though maybe drag & drop should optionally work right there on the button area, without the need for a modal.

from uppy.

Good point.. Agreed

from uppy.

I am an advocate for imposing as little as possible on the user by default. I think SDKs/libs/plugins feel much less "magical" when I can express exactly what I want and what I want to opt-in for. It would be great if we could take this approach while still making it easy for users who are all for drop-in solutions.

from uppy.

Agreed as well. So how would this work? Considering you could turn on modal for the dragdropplugin, or maybe you want to enable it on an existing div on the page.

Something like

.useAcquire(dragdrop, {target: transloadit.modal})
// vs
.useAcquire(dragdrop, {target: '#myDiv'})

?

Modal is a think that should be provided by core I think. As it could hold different plugins

from uppy.

Thinking some more.. It could also be a plugin:

.use(transloaditModal, {some: 'config'})
.use(dragdrop, {target: transloaditModal})
.use(instagram, {target: transloaditModal})

from uppy.

that's a good idea, definitely.

from uppy.

Modal feels like a core thing for me, not a plugin. It’s a ui component that all plugins will use, like progress, like spinner.

from uppy.

We could surely use more examples of pluggable architecture, tested in the real world. PostCSS, Markdown-It, what else?

from uppy.

So something I've been thinking about is how this client could be used in a React project. Kevin and Tim, I'm not sure if you've looked into React at all, but you're not supposed to have outside influences on the DOM when rendering UI with React.

from uppy.

We should make a separate component for React, I think.

from uppy.

Generally DOM manipulation is not a good idea, as well.

from uppy.

Modal feels like a core thing for me, not a plugin. It’s a ui component that all plugins will use, like progress, like spinner.

That would mean though that people not interested in Modal are still hogging that weight around. As for the spinner, it could be a plugin as well, with a target of either transloaditModal() of '#myDiv'?

React

I'd like this to work really well - but I can't offer any ideas here, I have 0 experience

We could surely use more examples of pluggable architecture, tested in the real world. PostCSS, Markdown-It, what else?

If you find anything better let's hear it - I'm actually pretty happy with our current markdown-it approach.

from uppy.

I like the idea of the modal being a plugin. If we focus on providing functionality primarily and make everything else pluggable, I think that'd be the way to go.

from uppy.

What worries me is this is getting harder to use for normal people, who just wanna like:

thansloadit({target: '.my-button'});

from uppy.

What worries me is this is getting harder to use for normal people, who just wanna like:

I think that's also a big concern of Tim's.. Maybe we can architect it in the modularized way, but expose that as transloaditLowlevel. Then transloadit is reserved for 'common joe', and actually wires the components together using modals, full-blown-ui, etc.

function transloadit(cfg) {
   transloaditLowlevel.use(transloaditModal)
   transloaditLowlevel.use(defaultTheme)
}

There should be prettier words for this though - couldn't think of any

from uppy.

Yeah, that sounds good. We might be discussing this prematurely though, I’d make a working prototype first with some of these ideas in mind and then iterate on that, since we’ll see real world problems in the process.

from uppy.

@arturi: Of course. That's equally as important. I'm not actually aware of what our customer base is like, so this could even be overkill :D

from uppy.

While I agree it's impossible to plan ahead - I feel the choices we make here could affect greatly how the end product looks like.

If we need the end the back & forth, I would like to build this in a modular way (modal is a plugin too). And we can add convenient shortcuts for noobish users easily later on. The other way around: Having a heavy core and trying to strip it for advanced users - is not that easy.

from uppy.

I just remembered, Babel 6 does nothing without plugins now. They removed ES6/React transforms from the core. They made it so every single es2015 feature (classes, arrow exps, etc) needs its own plugin. To make it less ridiculous, they introduced "presets" for es2015, react, and others, which let you add add them all with a single line.

from uppy.

I like that - it seems to me it offers the best of both worlds. People could have no modal. They could substitute their own. While still having syntax high on sugar for novice folk

from uppy.

You are right. This is how both Babel and PostCSS do it now: it’s naked from the start, there are many plugins and then there is es2015-preset for Babel and PreCSS for PostCSS — they include quite a few plugins by default, so you don’t have to worry about it if you don’t want to. Atom and Sublime editors do similar — everything is a plugin, some are just bundled in from the start.

from uppy.

Same with drag n drop. Instead of being dependent on a third party lib, we could easily plug in any drag n drop library.

from uppy.

I though drag n drop will be our own library.

from uppy.

well i was saying that we could provide our own drag n drop plugin, but if they dont want to use it, they can plug their own in

from uppy.

@arturi: good point about postcss, atom, sublime, etc.

from uppy.

So our API should in theory support any plugin? I though this kind of plugins have to be aware of transloadit to work.

from uppy.

ah no, i meant that a plugin could be written to support another drag n drop library, for instance.

from uppy.

Right, like you could write a wrapper around DropZone, for transloadit. I like that

from uppy.

Ok, got it.

from uppy.

Alright - please cement what we agreed upon in the markdown doc of #9 - and I'll be closing this issues

from uppy.

How will the default plugin work with settings, if it includes a few other plugins? Will there be no settings, or minimal like target: '.my-upload'?

This is how it could work:

transloadit
  .set({ wait: true })
  .use(transloaditBasic, {some: 'config'})

from uppy.

I think how we'll build it, is that there is not a default plugin. Every plugin has a name and is optional.

Then we add some convenient functions later to string the pieces together in a novice-friendly way. One of those could just accept wait:false indeed:

supereasyTransloadit({wait:false});

But this would under the hood do:

transloadit
  .set(uploader, { wait: true })
  .use(transloaditBasic, {some: 'config'})

As would people who are power users and want customization

from uppy.

This has been settled. Modal will be a plugin. It will be enabled by default in the TransloaditBasic preset plugin like so https://github.com/transloadit/transloadit-js-client/blob/f1aa1072d5159c372624a57d5a8edaad2119efa9/classes.es6#L71

from uppy.