1
0
mirror of https://github.com/laurent22/joplin.git synced 2025-01-11 18:24:43 +02:00

ReactNativeClient: Fix some typos (found by codespell)

Signed-off-by: Stefan Weil <sw@weilnetz.de>
This commit is contained in:
Stefan Weil 2018-05-05 16:25:37 +02:00
parent 40a34a7c05
commit feb0c02c9a
3 changed files with 7 additions and 7 deletions

View File

@ -38,7 +38,7 @@ class FileApiDriverWebDav {
}
statFromResource_(resource, path) {
// WebDAV implementations are always slighly different from one server to another but, at the minimum,
// WebDAV implementations are always slightly different from one server to another but, at the minimum,
// a resource should have a propstat key - if not it's probably an error.
const propStat = this.api().arrayFromJson(resource, ['d:propstat']);
if (!Array.isArray(propStat)) throw new Error('Invalid WebDAV resource format: ' + JSON.stringify(resource));

View File

@ -1,9 +1,9 @@
const layoutUtils = {};
layoutUtils.size = function(prefered, min, max) {
if (prefered < min) return min;
if (typeof max !== 'undefined' && prefered > max) return max;
return prefered;
layoutUtils.size = function(preferred, min, max) {
if (preferred < min) return min;
if (typeof max !== 'undefined' && preferred > max) return max;
return preferred;
}
module.exports = layoutUtils;

View File

@ -263,7 +263,7 @@ class Synchronizer {
//
// TODO: assuming a particular sync target is guaranteed to have accurate timestamps, the driver maybe
// could expose this with a accurateTimestamps() method that returns "true". In that case, the test
// could be done using the file timestamp and the potentially unecessary content loading could be skipped.
// could be done using the file timestamp and the potentially unnecessary content loading could be skipped.
// OneDrive does not appear to have accurate timestamps as lastModifiedDateTime would occasionally be
// a few seconds ahead of what it was set with setTimestamp()
remoteContent = await this.api().get(path);
@ -567,7 +567,7 @@ class Synchronizer {
// If user has cancelled, don't record the new context (2) so that synchronisation
// can start again from the previous context (1) next time. It is ok if some items
// have been synced between (1) and (2) because the loop above will handle the same
// items being synced twice as an update. If the local and remote items are indentical
// items being synced twice as an update. If the local and remote items are identical
// the update will simply be skipped.
if (!hasCancelled) {
if (!listResult.hasMore) {