From 68853c3fc2219033a6f9522248ac4619abb46ef1 Mon Sep 17 00:00:00 2001 From: Martius Lim Date: Sun, 31 Dec 2017 18:24:46 +0800 Subject: [PATCH 1/2] Fixed several typos in docs/server and docs/uppy as well as made parentheses and paragraph formatting more consistent --- website/src/docs/server.md | 16 ++++++---------- website/src/docs/uppy.md | 10 +++++----- 2 files changed, 11 insertions(+), 15 deletions(-) diff --git a/website/src/docs/server.md b/website/src/docs/server.md index 6dc60ef18..1321113a5 100644 --- a/website/src/docs/server.md +++ b/website/src/docs/server.md @@ -83,8 +83,7 @@ Please ensure that the required env variables are set before running/using uppy- $ uppy-server ``` -If you cloned the repo from gtihub and want to run it as a standalone server, you may also run the following command from within its -directory +If you cloned the repo from github and want to run it as a standalone server, you may also run the following command from within its directory ```bash npm run start:production @@ -204,7 +203,7 @@ See [env.example.sh](https://github.com/transloadit/uppy-server/blob/master/env. - protocol - `http | https` - host(required) - your server host (e.g localhost:3020, mydomain.com) - path - the server path to where the uppy app is sitting (e.g if uppy server is at `mydomain.com/uppy`, then the path would be `/uppy`). - - oauthDoamin - if you have multiple instances of uppy server with different(and maybe dynamic) subdomains, you can set a master domain(e.g `sub1.mydomain.com`) to handle your oauth authentication for you. This would then redirect to the slave subdomain with the required credentials on completion. + - oauthDoamin - if you have multiple instances of uppy server with different (and maybe dynamic) subdomains, you can set a master domain (e.g `sub1.mydomain.com`) to handle your oauth authentication for you. This would then redirect to the slave subdomain with the required credentials on completion. - validHosts - if you are setting a master `oauthDomain`, you need to set a list of valid hosts, so the master oauth handler can validate the host of the uppy instance requesting the authentication. This is basically a list of valid domains running your uppy server instances. The list may also contain regex patterns. e.g `['sub2.mydomain.com', 'sub3.mydomain.com', '(\\w+).mydomain.com']` 5. **sendSelfEndpoint(optional)** - This is basically the same as the `server.host + server.path` attributes. The major reason for this attributes is that, when set, it adds the value as the `i-am` header of every request response. @@ -235,8 +234,7 @@ The default value simply returns `filename`, so all files will be uploaded to th ### Adding Custom Providers -As of now, uppy-server supports **Google Drive**, **Dropbox** and **Instagram** out of the box, but you may also choose to add your custom providers. You can do this by passing the `customProviders` -option when calling the uppy `app` method. The custom provider is expected to support Oauth 1 or 2 for authentication/authorization. +As of now, uppy-server supports **Google Drive**, **Dropbox** and **Instagram** out of the box, but you may also choose to add your custom providers. You can do this by passing the `customProviders` option when calling the uppy `app` method. The custom provider is expected to support Oauth 1 or 2 for authentication/authorization. ```javascript let options = { @@ -272,8 +270,8 @@ To work well with uppy server, the **Module** must be a class with the following - `options` - is an object containing the following attributes - token - authorization token(retrieved from oauth process) to send along with your request. - id - id of the file being downloaded. - - `onData (chunk)` - a callback that should be called with each data chunk received on download. This is useful if the size of the downloaded file can be pre-determined. This would allow for pipelined upload of the file(to the desired destination), while the download is still going on. - - `onResponse (response)` - if the size of the downloaded file can not be pre-determined by uppy-server, then this callback should be called in place of the `onData` callback. This callback would be called after the download is done, and would the downloaded data(response) as argument. + - `onData (chunk)` - a callback that should be called with each data chunk received on download. This is useful if the size of the downloaded file can be pre-determined. This would allow for pipelined upload of the file (to the desired destination), while the download is still going on. + - `onResponse (response)` - if the size of the downloaded file can not be pre-determined by uppy-server, then this callback should be called in place of the `onData` callback. This callback would be called after the download is done, and would take the downloaded data (response) as the argument. ## Development @@ -305,9 +303,7 @@ It also expects the [uppy client](https://github.com/transloadit/uppy) to be run An example server is running at http://server.uppy.io, which is deployed via [Frey](https://github.com/kvz/frey), using the following [Freyfile](infra/Freyfile.toml). -All the secrets are stored in `env.infra.sh`, so using `env.infra.example.sh`, you could -use the same Freyfile but target a different cloud vendor with different secrets, and run your own -uppy-server. +All the secrets are stored in `env.infra.sh`, so using `env.infra.example.sh`, you could use the same Freyfile but target a different cloud vendor with different secrets, and run your own uppy-server. ## Logging diff --git a/website/src/docs/uppy.md b/website/src/docs/uppy.md index 1aa091a2c..9dab16878 100644 --- a/website/src/docs/uppy.md +++ b/website/src/docs/uppy.md @@ -5,7 +5,7 @@ title: "Uppy" permalink: docs/uppy/ --- -Core module that orchistrated everything in Uppy, exposing `state`, `events` and `methods`. +Core module that orchestrates everything in Uppy, exposing `state`, `events` and `methods`. ## Options @@ -35,7 +35,7 @@ A site-wide unique ID for the instance. If multiple Uppy instances are being used, for example on two different pages, an `id` should be specified. This allows Uppy to store information in `localStorage` without colliding with other Uppy instances. -Note that this ID should be persistent across page reloads and navigation—it shouldn't be a random number that's different every time Uppy is loaded. +Note that this ID should be persistent across page reloads and navigation — it shouldn't be a random number that's different every time Uppy is loaded. For example, if one Uppy instance is used to upload user avatars, and another to add photos to a blog post, you might use: ```js @@ -118,7 +118,7 @@ locale: { } ``` -As well as the pluralization function, which is used to determin which string will be used for the provided `smart_count` number. +As well as the pluralization function, which is used to determine which string will be used for the provided `smart_count` number. For example, for Icelandic language the pluralization function will be: @@ -174,7 +174,7 @@ uppy.addFile({ }) ``` -`addFile` attemps to determine file type by [magic bytes](https://github.com/sindresorhus/file-type) + the provided `type` + extension; then checks if the file can be added, considering `uppy.opts.restrictions`, sets metadata and generates a preview, if it’s an image. +`addFile` attempts to determine file type by [magic bytes](https://github.com/sindresorhus/file-type) + the provided `type` + extension; then checks if the file can be added, considering `uppy.opts.restrictions`, sets metadata and generates a preview, if it’s an image. If `uppy.opts.autoProceed === true`, Uppy will begin uploading after the first file is added. @@ -225,7 +225,7 @@ uppy.setState({ }) ``` -We don’t mutate `uppy.state`, so internally `setState` creates a new copy of state and replaces uppy.state with it. However, when updating values, it’s your responsibility to not mutate them, but instead create copies. See [Redux docs](http://redux.js.org/docs/recipes/UsingObjectSpreadOperator.html) for more info on this. Here’s an example from Uppy.Core that updates progress for a particular file in state: +We don’t mutate `uppy.state`, so internally `setState` creates a new copy of state and replaces `uppy.state` with it. However, when updating values, it’s your responsibility to not mutate them, but instead create copies. See [Redux docs](http://redux.js.org/docs/recipes/UsingObjectSpreadOperator.html) for more info on this. Here’s an example from Uppy.Core that updates progress for a particular file in state: ```js const updatedFiles = Object.assign({}, uppy.getState().files) From 8f5683b03b1d1deb7e5252a1b2972cd2d7c0168a Mon Sep 17 00:00:00 2001 From: Martius Lim Date: Tue, 9 Jan 2018 00:00:18 +0800 Subject: [PATCH 2/2] updated typo fixes according to comments --- website/src/docs/server.md | 10 +++++----- website/src/docs/uppy.md | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/website/src/docs/server.md b/website/src/docs/server.md index 1321113a5..be6f496b0 100644 --- a/website/src/docs/server.md +++ b/website/src/docs/server.md @@ -62,7 +62,7 @@ const options = { app.use(uppy.app(options)) ``` -[See](#Options) for valid configuration options. +See [Options](#Options) for valid configuration options. To enable uppy socket for realtime feed to the client while upload is going on, you call the `socket` method like so. @@ -77,7 +77,7 @@ This takes your `server` instance and your uppy [options](#Options) as parameter ### Run as standalone server -Please ensure that the required env variables are set before running/using uppy-server as a standalone server. [See](#Configure-Standalone). +Please ensure that the required environment variables are set before running/using uppy-server as a standalone server. See [Configure Standalone](#Configure-Standalone) for the variables required. ```bash $ uppy-server @@ -196,19 +196,19 @@ See [env.example.sh](https://github.com/transloadit/uppy-server/blob/master/env. 2. **redisUrl(optional)** - URL to running redis server. If this is set, the state of uploads would be stored temporarily. This helps for resumed uploads after a browser crash from the client. The stored upload would be sent back to the client on reconnection. -3. **providerOptions(optional)** - An object containing credentials (`key` and `secret`) for each provider you would like to enable. Please [see](#Supported-Providers) for supported providers. +3. **providerOptions(optional)** - An object containing credentials (`key` and `secret`) for each provider you would like to enable. Please see [here for the list of supported providers](#Supported-Providers). 4. **server(optional)** - An object with details mainly used to carry out oauth authentication from any of the enable providers above. Though it is optional, it is required if you would be enabling any of the supported providers. The following are the server options you may set - protocol - `http | https` - host(required) - your server host (e.g localhost:3020, mydomain.com) - path - the server path to where the uppy app is sitting (e.g if uppy server is at `mydomain.com/uppy`, then the path would be `/uppy`). - - oauthDoamin - if you have multiple instances of uppy server with different (and maybe dynamic) subdomains, you can set a master domain (e.g `sub1.mydomain.com`) to handle your oauth authentication for you. This would then redirect to the slave subdomain with the required credentials on completion. + - oauthDomain - if you have multiple instances of uppy server with different (and maybe dynamic) subdomains, you can set a master domain (e.g `sub1.mydomain.com`) to handle your oauth authentication for you. This would then redirect to the slave subdomain with the required credentials on completion. - validHosts - if you are setting a master `oauthDomain`, you need to set a list of valid hosts, so the master oauth handler can validate the host of the uppy instance requesting the authentication. This is basically a list of valid domains running your uppy server instances. The list may also contain regex patterns. e.g `['sub2.mydomain.com', 'sub3.mydomain.com', '(\\w+).mydomain.com']` 5. **sendSelfEndpoint(optional)** - This is basically the same as the `server.host + server.path` attributes. The major reason for this attributes is that, when set, it adds the value as the `i-am` header of every request response. -6. **customProviders(optional)** - This option enables you add custom providers along with the already supported providers. [See](#Adding-Custom-Providers) for more. +6. **customProviders(optional)** - This option enables you to add custom providers along with the already supported providers. See [Adding Custom Providers](#Adding-Custom-Providers) for more information. 7. **uploadUrls(optional)** - An array of urls (full path), which uppy-server should only upload to. diff --git a/website/src/docs/uppy.md b/website/src/docs/uppy.md index 9dab16878..cd60b95b9 100644 --- a/website/src/docs/uppy.md +++ b/website/src/docs/uppy.md @@ -35,7 +35,7 @@ A site-wide unique ID for the instance. If multiple Uppy instances are being used, for example on two different pages, an `id` should be specified. This allows Uppy to store information in `localStorage` without colliding with other Uppy instances. -Note that this ID should be persistent across page reloads and navigation — it shouldn't be a random number that's different every time Uppy is loaded. +Note that this ID should be persistent across page reloads and navigation—it shouldn't be a random number that's different every time Uppy is loaded. For example, if one Uppy instance is used to upload user avatars, and another to add photos to a blog post, you might use: ```js @@ -313,7 +313,7 @@ uppy.upload().then((result) => { ### `uppy.on('event', action)` -Subscribe to an uppy-event. See full list of events below. +Subscribe to an uppy-event. See below for the full list of events. ## Events