Add support for Redux DevTools via a plugin

[arturi]

• Sends state updates to DevTools; Subscribes to DevTools and sets Uppy state to state provided by DevTools for time traveling; supports replaying all actions, step by step, persisting state, jumping to specific state
• Works without modifying everything else, which is cool. Though I’m not saying adopting Redux would be too hard (see Redux initial work [proof of concept] #338), and it might provide better structure, but we are just not sure yet;
• We could add support for custom action type names, and then we’ll get actions like UPPY_ADD_FILE and such (see this comment https://news.ycombinator.com/item?id=15342850);
• Implemented as a separate plugin

(Try by installing and activating: https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd?hl=en)

And the second commit is useful regardless:

Don’t store function references in state to keep state serializable
Instead of storing methods in state, find plugin and add methods to the object that we pass to render, when it’s needed.

This might be useful for parsing/stringifying JSON, so we don’t forget: https://www.npmjs.com/package/jsan

done P.S. This could probably be a plugin 🤔

[goto-bus-stop]

this is neat!

Implemented as a separate plugin

🎉

Don’t store function references in state to keep state serializable

AwsS3 also stores functions in state to configure the XHRUpload plugin. That one's a bit harder to avoid I think :(

[kvz]

AwsS3 also stores functions in state to configure the XHRUpload plugin. That one's a bit harder to avoid I think :(

Would it help if we'd AwsS3 extends XHRUpload? It always felt slightly off to me that we make people .use two plugins and then they temper with each other (like, what if you have another plugin that wants to temper with XHRUpload). It could be that it's just me, with my OOP hammer in hand everything looks like a nail, and maybe there are good reasons not to do it?

[arturi]

@kvz I have no good reasons from experience, but I’ve heard warnings that double-extending is a path to madness. We could do what Dashboard does and .use() internally:

uppy/src/plugins/Dashboard/index.js

Lines 423 to 433 in 5ee0a13

	if (!this.opts.disableStatusBar) {
	this.core.use(StatusBar, {
	target: this
	})
	}
	if (!this.opts.disableInformer) {
	this.core.use(Informer, {
	target: this
	})
	}

But Renee @goto-bus-stop would know more, cause he designed the flow, and there might be other parts, like encoding plugins, involved.