|
|
@@ -247,9 +247,9 @@ Some things to note here:
|
|
|
3. The `Remote` plugin example linked above extends `Remote` from a module I created called `uppy-base`. I created `uppy-base` while trying to figure out how to make Uppy work with React. I took the bare functionality of Uppy that could be used universally (vanilla, React, Angular, anywhere) and put it into its own module. The `uppy-base` plugins are stateless and not concerned with the UI. Here is the `Remote` plugin from `uppy-base`: https://github.com/hedgerh/uppy-base/blob/master/src/plugins/Remote.js
|
|
|
|
|
|
## React
|
|
|
-I'd like to give React users the freedom to manage their own Uppy state, whether they use internal state, or a state management lib like Redux. The proposed solution of syncing the user's state to Uppy's internal state via event listeners, ie. `uppy.on('file-added', (file) => this.props.dispatch({ type: 'ADD_FILE', payload: file }))` is problematic because it violates the "single source of truth" principal, in that our state exists in two separate locations. If we add a file, then roll back the add file action with time-travel debugging, the file will be removed from Redux's state, but still present in Uppy's state, causing de-synchronization between the two.
|
|
|
+I'd like to give React users the freedom to manage their own Uppy state, whether they use internal state, or a state management lib like Redux. The proposed solution of syncing the user's state to Uppy's internal state via event listeners, ie. `uppy.on('file-added', (file) => this.props.dispatch({ type: 'ADD_FILE', payload: file }))` is problematic because it violates the "single source of truth" principal, in that our state exists in two separate locations. If we add a file, then roll back the add file action with time-travel debugging, the file will be removed from Redux's state, but still present in Uppy's state, causing de-synchronization between the two. We have discussed to get around this is allowing the user to pass their Redux store instance into Uppy. I think this is a possible solution to the issue.
|
|
|
|
|
|
-The easiest solution I've found is to just use the `uppy-base` plugins directly in React, without Uppy's core. Here is a comparison of core vs. no core: https://gist.github.com/hedgerh/9ad63f467ce816246044f3f9e83bd7e7
|
|
|
+Another solution I've found, that is not as ideal, is to just use the `uppy-base` plugins directly in React, without Uppy's core, and have the user manage their own state. Here is a comparison of core vs. no core: https://gist.github.com/hedgerh/9ad63f467ce816246044f3f9e83bd7e7
|
|
|
|
|
|
For ease of use, we'd write a React container/wrapper component that abstracted away all of that from the user. I've started on something like that here (bear in mind it's a bit messy): https://github.com/hedgerh/uppy-react/blob/master/src/containers/UppyContainer.js
|
|
|
|
Harry Hedger