Альтернатива `return await…` для случаев ожидания некоторого результата, который должен быть возвращен - PullRequest
Новая
       4

Альтернатива `return await…` для случаев ожидания некоторого результата, который должен быть возвращен

0 голосов
/ 23 октября 2019

Я знаю, что правило ESLint / TSLint не может быть «правильным» в 100% случаев. Однако мне нужно решить, какие правила мне действительно не нужны.

В ElectonJS не рекомендуется использовать модули Node.js в Renderer Process. Вместо этого процесс Renderer должен отправить запрос в Main Process и прослушать ответ. Ниже класс TypeScript заботится об этой процедуре. (Я надеюсь, что мои имена переменных делают код не нуждающимся в комментариях, но это трудно понять, пожалуйста, дайте мне знать в комментариях) 

import { ipcRenderer as IpcRenderer } from "electron";

import InterProcessDataTransferProtocol from "@ProjectInitializer:Root/InterProcessDataTransferProtocol";
import CheckingPathForWriteAccess = InterProcessDataTransferProtocol.CheckingPathForWriteAccess;
import MainProcessEvents = InterProcessDataTransferProtocol.MainProcessEvents;

import Timeout = NodeJS.Timeout;


export default abstract class InterProcessFacilitator {

  private static readonly IS_PATH_WRITABLE__RESPONSE_WAITING_PERIOD__MILLISECONDS: number = 10000;

  public static async requestCheckingPathForAccessToWrite(targetPath: string): Promise<boolean> {

    IpcRenderer.send(
        InterProcessDataTransferProtocol.RendererProcessEvents.checkingPathForWriteAccessRequestSent,
        { targetPath }
    );

    const responseWaitingTimeout: Timeout = setTimeout(
        () => { throw new Error("No response from Main Process"); },
        InterProcessFacilitator.IS_PATH_WRITABLE__RESPONSE_WAITING_PERIOD__MILLISECONDS
    );

    return await new Promise<boolean>((resolve: (isWritable: boolean) => void): void => {
      IpcRenderer.on(
          MainProcessEvents.checkingPathForWriteAccessDone,
          (_event: Electron.Event, responsePayload: CheckingPathForWriteAccess.ResponsePayload) =>
          {
            clearTimeout(responseWaitingTimeout);
            if (responsePayload.targetPath === targetPath) {
              resolve(responsePayload.isWritable);
            }
          });
    });
  }
}

В настоящее время метод requestCheckingPathForAccessToWrite нарушает без возврата-wait , правила ESLint. Однако его можно использовать следующим образом: 

async function checkTheDefaultPathForWrightPermission(): Promise<void> {
    try {
        const pickedPathIsWritable: boolean = await InterProcessFacilitator
              .requestCheckingPathForAccessToWrite(DEFAULT_PATH);
      pickedPathIsWritable ?
          this.relatedStoreModule.reportAboutUnableToWriteToDirectoryErrorResolution() :
          this.relatedStoreModule.reportAboutUnableToWriteToDirectoryErrorOccurrence();
    } catch (error) {
        console.error(`unable to check wright permission for path ${DEFAULT_PATH}`);
        console.error(error);
    }
}

Из документации ESLint:

Внутри асинхронной функции функция возврата результата редко бывает полезна. Поскольку возвращаемое значение асинхронной функции всегда заключено в Promise.resolve, return await фактически ничего не делает, кроме добавления дополнительного времени, прежде чем всеобъемлющее Promise разрешит или отклонит. Единственное допустимое исключение, если return await используется в операторе try / catch для перехвата ошибок из другой функции, основанной на Promise.

Можете ли вы критиковать либо мое решение, либо это правило ESLint, и в первом случаеподскажите рефакторинг?

...