RFC: deprecate Robodog in favor of presets

Problem

We want to market Uppy as an easy to integrate product. When we look at competitors of Uppy, they showcase a couple of lines for the integration to get a UI and upload experience. When people visit Uppy, one of the things they will likely see first is the dashboard example. The integration code shown below the dashboard is extensive.

Integration code from examples/dashboard

const Uppy = require('@uppy/core')
const Dashboard = require('@uppy/dashboard')
const GoogleDrive = require('@uppy/google-drive')
const Dropbox = require('@uppy/dropbox')
const Box = require('@uppy/box')
const Instagram = require('@uppy/instagram')
const Facebook = require('@uppy/facebook')
const OneDrive = require('@uppy/onedrive')
const Webcam = require('@uppy/webcam')
const ScreenCapture = require('@uppy/screen-capture')
const ImageEditor = require('@uppy/image-editor')
const Tus = require('@uppy/tus')
const Url = require('@uppy/url')
const DropTarget = require('@uppy/drop-target')
const GoldenRetriever = require('@uppy/golden-retriever')

const uppy = new Uppy({
  debug: true,
  autoProceed: false,
  restrictions: {
    maxFileSize: 1000000,
    maxNumberOfFiles: 3,
    minNumberOfFiles: 2,
    allowedFileTypes: ['image/*', 'video/*'],
    requiredMetaFields: ['caption'],
  }
})
.use(Dashboard, {
  trigger: '.UppyModalOpenerBtn',
  inline: true,
  target: '.DashboardContainer',
  showProgressDetails: true,
  note: 'Images and video only, 2–3 files, up to 1 MB',
  height: 470,
  metaFields: [
    { id: 'name', name: 'Name', placeholder: 'file name' },
    { id: 'caption', name: 'Caption', placeholder: 'describe what the image is about' }
  ],
  browserBackButtonClose: false
})
.use(GoogleDrive, { target: Dashboard, companionUrl: 'https://companion.uppy.io' })
.use(Dropbox, { target: Dashboard, companionUrl: 'https://companion.uppy.io' })
.use(Box, { target: Dashboard, companionUrl: 'https://companion.uppy.io' })
.use(Instagram, { target: Dashboard, companionUrl: 'https://companion.uppy.io' })
.use(Facebook, { target: Dashboard, companionUrl: 'https://companion.uppy.io' })
.use(OneDrive, { target: Dashboard, companionUrl: 'https://companion.uppy.io' })
.use(Webcam, { target: Dashboard })
.use(ScreenCapture, { target: Dashboard })
.use(ImageEditor, { target: Dashboard })
.use(Tus, { endpoint: 'https://tusd.tusdemo.net/files/' })
.use(DropTarget, {target: document.body })
.use(GoldenRetriever)

uppy.on('complete', result => {
  console.log('successful files:', result.successful)
  console.log('failed files:', result.failed)
})

This might be daunting for potential users, and the pattern of repeating target andcompanionUrl might seem off to some. (Note that this is partly a documentation problem, but we’ll come back to that). This is what brought Robodog to life. An alternative with the same features, but with a more ergonomic and minimal API.

However, it didn’t come with its own set of new problems.

• It tries to do the exact same, but it looks like an entirely different product
• It’s confusing for users whether they want to use Robodog or Uppy directly.
• Documentation is scarce, and the tradeoffs are unclear
• It’s not marketed, you need to stumble on it in the docs.
• Extra maintenance burden
• Extra hosting effort and costs

I never really understood Robodog, and I have been working on Uppy for half a year, so what will it be like for new users?

It is understandable how Robodog came to be, but we are not the first one to fall for the fallacy of uncoordinated good ideas. This reminded me of some lessons from the The Mythical Man-Month, a book with essays about software engineering and what people succeeded or failed to do after many years of experience:

• Simplicity and straight-forward-ness proceed from conceptual integrity
• It is better to have one good idea and carry it through the project than having several uncoordinated good ideas
• It is important that all the aspects of the system follow the same philosophy and the same conceptual integrity throughout the system. Thus, by doing so, the user or the customer only needs to be aware of or know one concept

Case in point: part of the problem is the lack of a shared definition of what Uppy does and wants to be. Is it the most easy to integrate product? Does it have the most features? Does it have the most flexibility? It can’t be all at once.

Solution

I think Uppy is the option with a lot of great tightly-coupled features and flexible APIs to let the users build the rest they want. It will not be the integration with the least lines of code. But that doesn’t mean we can’t do a bit better. So let’s deprecate Robodog, take the confusion away, and own the strengths of Uppy and tweak its integration pain point a bit. The latter is what brings us to ‘presets’.

Presets

Let’s look at the difference at a glance.

const Uppy = require("@uppy/core");
const Dashboard = require("@uppy/dashboard");
const GoogleDrive = require("@uppy/google-drive");
const Dropbox = require("@uppy/dropbox");
const Box = require("@uppy/box");
const Instagram = require("@uppy/instagram");
const Facebook = require("@uppy/facebook");
const OneDrive = require("@uppy/onedrive");
const ImageEditor = require("@uppy/image-editor");

const uppy = new Uppy()
  .use(Dashboard, {
    inline: true,
    target: ".DashboardContainer",
  })
  .use(ImageEditor, { target: Dashboard })
  .use(GoogleDrive, { target: Dashboard, companionUrl: "https://companion.uppy.io" })
  .use(Dropbox, { target: Dashboard, companionUrl: "https://companion.uppy.io" })
  .use(Box, { target: Dashboard, companionUrl: "https://companion.uppy.io" })
  .use(Instagram, { target: Dashboard, companionUrl: "https://companion.uppy.io" })
  .use(Facebook, { target: Dashboard, companionUrl: "https://companion.uppy.io" })
  .use(OneDrive, { target: Dashboard, companionUrl: "https://companion.uppy.io" });

const Uppy = require("@uppy/core");
const Uppy = require("@uppy/preset-providers"); // @uppy/preset-dashboard-providers?

const uppy = new Uppy().use(PresetProviders, {
  target: ".DashboardContainer",
  inline: true,
  companionUrl: "https://companion.uppy.io",
  providers: ["drive", "dropbox", "box", "instagram", "facebook", "onedrive"],
});

Another example of a preset could be @uppy/preset-transloadit (less impressive, but would align with what Robodog currently offers):

const Uppy = require("@uppy/core");
const Dashboard = require("@uppy/dashboard");
const Transloadit = require("@uppy/transloadit");
const ImageEditor = require("@uppy/image-editor");

const uppy = new Uppy()
  .use(Dashboard, {
    inline: true,
    target: ".DashboardContainer",
  })
  .use(ImageEditor, { target: Dashboard })
  .use(Transloadit, { params: { auth: { key: "" }, template_id: "" })

const Uppy = require("@uppy/core");
const Uppy = require("@uppy/preset-transloadit");

const uppy = new Uppy().use(PresetTransloadit, {
  target: ".DashboardContainer",
  inline: true,
  params: { auth: { key: "" }, template_id: "" },
});

Presets

• …are new plugins which compose existing plugins
• …are familiar as it’s just a plugin as you’re used to
• …are for people who want a lot of functionality at once
• …are not for people who want to exactly compose what they want
• …share settings like companionUrl, but only pass unique settings to the right plugin
• …have the dashboard (and the image editor) build-in. A lot of plugins are tightly coupled to the dashboard anyway. But you could of course also create presets with @uppy/drag-drop
• …are technically easy to implement

---

Note that this probably has to be combined with a small redo of the documentation. We currently have a lot of ‘documentation islands’ per plugin, but if the examples/dashboard integration code is still the first thing people see, the problem partly remains. There should be a build up, from this is all you get in a couple of lines, to this is all the custom things you could do.

Alternatives

• Keep Robodog, but drastically improve the documentation
• Deprecate Robodog with no alternative

---

cc @kvz @goto-bus-stop @arturi @aduh95 @mifi

[kvz]

This is problematic because you are introducing ‘global’ methods on core that are in fact only meant and sensible for presets.

There seems to be a misunderstanding here maybe. They operate on plugins and it isn’t any different than what .use() does? These methods are not Preset specific. I think if you can add plugins with .use() (and we may as well call it add), it is not outrageous if core can also remove or modify them. And as Artur indicated this is already supported via the current but slightly less wieldy core.getPlugins().setOptions(). So functionally just deleting a plug-in from core would be new, tho I guess could maybe also already be done

[aduh95]

I don’t know if this has been suggested, here’s a syntax that could let us define plugin options in Uppy constructor.

const uppy = new Uppy({
    defaultPluginOptions: { target: Dashboard, companionUrl: "https://companion.uppy.io" },
  })
  .use(Dashboard, {
    inline: true,
    target: ".DashboardContainer",
  })
  .use(ImageEditor)
  .use(GoogleDrive)
  .use(Dropbox)
  .use(Box)
  .use(Instagram)
  .use(Facebook)
  .use(OneDrive);