Skip to content
This repository has been archived by the owner on Apr 6, 2022. It is now read-only.

2019 03 15 Synchronicity

Endre Bock edited this page Mar 16, 2019 · 1 revision

Synchronicity: Be or not to be?

... that is here the question!

To quote here Shakespeare, we can think about your calls of the interactors.
It will be come, that the interactor call APIs. That APIs of course we will run asynchronous. So we shall do also your interactors in asynchronous way.

Why we should do that? If not, the interactors have to be synchronize the calls and need to do error handling too. But that will lead into optical lags, when our interactors start to be complex.
To avoid that we decouple the controller calls, which are mostly in main thread of the browser running, from the API interactivity. Also the controller can take over the handling of error output or error reaction, which always depend on case.

So instead to do:

export default class Change {

  /**
   * @param {Request} request
   * @param {Response} response
   */
  interact(request, response) {
    // *** snip ***
  }
}

And in controlling:

  /**
   * @param {string} newLanguage
   */
  changeLanguage(newLanguage) {
    const request = new LanguageChangeRequest(newLanguage);
    const response = new LanguageChangeResponse();

    this.props.languageChangeInteractor.interact(request, response);
  }

We shall do that asynchronous:

export default class Change {

  /**
   * @param {Request} request
   * @param {Response} response
   */
  async interact(request, response) {
    // *** snip ***
  }
}

And in controlling:

  /**
   * @param {string} newLanguage
   */
  changeLanguage(newLanguage) {
    const request = new LanguageChangeRequest(newLanguage);
    const response = new LanguageChangeResponse();

    this.props.languageChangeInteractor
        .interact(request, response)
        .then(() => this.someThingsAfterwards())
        .catch(error => this.callTheErrorHandlingOrPresenter())
    ;
  }