Archives/gristlabs_grist-core
1
0
Fork 0
mirror of https://github.com/gristlabs/grist-core.git synced 2026-03-02 04:09:24 +00:00
Code Issues Projects Releases Wiki Activity

Correct spelling mistakes

Browse Source
This commit is contained in:
Edward Betts
2022-02-19 09:46:49 +00:00
parent bf7c46c3cd
commit d6e0e1fee3
69 changed files with 87 additions and 87 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
app/client/lib/SafeBrowser.ts
View File

@@ -3,7 +3,7 @@
* of a plugin.
*
* A plugin's safeBrowser component is made of one main entry point (the javascript files declares
* in the manifest), html files and any ressources included by the html files (css, scripts, images
* in the manifest), html files and any resources included by the html files (css, scripts, images
* ...). The main script is the main entry point which uses the Grist API to render the views,
* communicate with them en dispose them.
*
@@ -18,13 +18,13 @@
*
* The grist API available to safeBrowser components is implemented in `app/plugin/PluginImpl.ts`.
*
* All the safeBrowser's component ressources, including the main script, the html files and any
* other ressources needed by the views, should be placed within one plugins' subfolder, and Grist
* All the safeBrowser's component resources, including the main script, the html files and any
* other resources needed by the views, should be placed within one plugins' subfolder, and Grist
* should serve only this folder. However, this is not yet implemented and is left as a TODO, as of
* now the whole plugin's folder is served.
*
*/
// Todo: plugin ressources should not be made available on the server by default, but only after
// Todo: plugin resources should not be made available on the server by default, but only after
// activation.
// tslint:disable:max-classes-per-file
@@ -131,7 +131,7 @@ export class SafeBrowser extends BaseComponent {
// it's ok to leave it for now: (1) fixing this would require (yet) another refactoring of
// SafeBrowser and (2) at this point it is not sure wether we want to keep `render()` in the
// future (we could as well directly register contribution using files directly in the
// manifest), and (3) plugins are only developped by us, we only have to remember that using
// manifest), and (3) plugins are only developed by us, we only have to remember that using
// `render()` is only supported from within the main process (which cover all our use cases so
// far).
}

2
app/client/lib/dispose.d.ts vendored
View File

@@ -1,4 +1,4 @@
// TODO: add remaining Disposable methode
// TODO: add remaining Disposable method
export abstract class Disposable {
public static create<T extends new (...args: any[]) => any>(
this: T, ...args: ConstructorParameters<T>): InstanceType<T>;

2
app/client/lib/uploads.ts
View File

@@ -146,7 +146,7 @@ export async function uploadFiles(
}
/**
* Fetches ressource from a url and returns an UploadResult. Tries to fetch from the client and
* Fetches resource from a url and returns an UploadResult. Tries to fetch from the client and
* upload the file to the server. If unsuccessful, tries to fetch directly from the server. In both
* case, it guesses the name of the file based on the response's content-type and the url.
*/