Skip to content

Latest commit

 

History

History
101 lines (64 loc) · 2.9 KB

3-jhipster-rfc-unambiguous-priorities.md

File metadata and controls

101 lines (64 loc) · 2.9 KB

JHipster-RFC-3: Unambiguous priorities API

Summary

This RFC proposes to change priority declaration in a more unambiguous way. Making it easier to understand and allow the generator class to be implemented with a more traditional notation.

Motivation

Priorities are currently implemented as a getter with a non _ prefixed name, and any new function with a non _ prefixed name will be queued as a task at default priority. Javascript standard is that _ prefixed name is private method, and non _ prefixed name are class members instead of tasks. We should try to follow Javascript standards.

JHipster workflow is clear and each priority has it's purpose. This makes tasks outside priorities useless and its drawbacks overcome its benefits. We don't need to queue any tasks outside our declared priorities.

Guide-level explanation

Priorities will be implemented using constants as name, declaring it like get [INITIALIZING_PRIORITY]() {}. The constant INITIALIZING_PRIORITY will have a # prefixed value like #initializing. initializing will be available to be an ordinary class member.

Reference-level explanation

JHipster uses Yeoman's traditional priorities:

  get initializing() {
    return {
      initializingTask() {
        this._sayHello();
      }
    }
  }

  _sayHello() {
    console.log('hello');
  }

  aTaskQueuedAtDefaultPriority() {
    console.log('I am been executed, why? I am a default priority task.');
  }

The result is that developers may be confused with the notation. And the API doesn't follow standards.

While this works, an unambiguous notation would improve understanding of the workflow and improve the API.

  get [INITIALIZING_PRIORITY]() {
    return {
      initializingTask() {
        this.sayHello();
      }
    }
  }

  sayHello() {
    console.log('hello');
  }

  anOrdinaryClassMember() {
    console.log('I am not been executed, why? I am just and ordinary function.');
  }

Drawbacks

?

Rationale and alternatives

Our modular generators are already implemented using the new notation.

This is a breaking change. The traditional generators can switch to use constants, but they must not use the # prefix at JHipster 7.

Blueprints will have to adopt the same pattern.

Unresolved questions

?

Future possibilities

?