Skip to content

Discuss a refactoring for connection status on constants.js #522

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
alexruzenhack opened this issue Aug 8, 2024 · 3 comments
Closed

Discuss a refactoring for connection status on constants.js #522

alexruzenhack opened this issue Aug 8, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@alexruzenhack
Copy link
Contributor

Pedro has started the discussion in this comment.

Refer to the following snippet:

export const NETWORKSETTINGS_STATUS = {
  READY: 'ready',
  FAILED: 'failed',
  LOADING: 'loading',
  WAITING: 'waiting',
  SUCCESSFUL: 'successful',
};

export const NANOCONTRACT_REGISTER_STATUS = {
  READY: 'ready',
  FAILED: 'failed',
  LOADING: 'loading',
  SUCCESSFUL: 'successful',
};

export const WALLETCONNECT_NEW_NANOCONTRACT_TX_STATUS = {
  READY: 'ready',
  FAILED: 'failed',
  LOADING: 'loading',
  SUCCESSFUL: 'successful',
};

export const NANOCONTRACT_BLUEPRINTINFO_STATUS = {
  READY: 'ready',
  FAILED: 'failed',
  LOADING: 'loading',
  SUCCESSFUL: 'successful',
};

See the snnipet in place.

@alexruzenhack
Copy link
Contributor Author

Abadesso has implemented something in this direction. See the following comment on his PR #528.

@alexruzenhack alexruzenhack moved this from Todo to In Progress (WIP) in Hathor Network Aug 27, 2024
@alexruzenhack
Copy link
Contributor Author

alexruzenhack commented Sep 18, 2024

Despite the generalization applied by @andreabadesso at #528 it is not enough. I propose to create a model for each redux state that uses a status and implement a status inspection in the model itself, this way we can get rid of any particular status constant and improve code cohesion.

Let's take by example the state blueprint, which can be the following model:

class BlueprintInfo {
  #status;
  constructor({ status }) {
    #status = new StatusState(status);
  }

  get status() {
    return #status;
  }
  // other properties...
}

This way we can instantiate the blueprint state from select using a handler:

/**
 * @example
 * const blueprintInfo = yield select(getBlueprintInfo);
 */
const getBlueprintInfo = (state) => new BlueprintInfo(state.nanoContract.blueprint);

And we can use the instance of the model in the logic like this:

if (blueprintInfo.status.isSuccessful) {
  // Do something...
}

This way we can eliminate the need for the constants and only implement status getters in the model that makes sense for the model. With this approach we strengths code cohesion and readability.

StatusState model:

class StatusState {
   static possibleStates = {
    ready: true,
    failed: true,
    loading: true,
    waiting: true,
    successful: true,
  };
  #currentState;

  constructor (state) {
    if (!state) {
      #currentState = possibleState.ready
    } else {
      #currentState = state;
    }
  }

  get isSuccessfull() {
    return #currentState === possibleStates.successfull;
  }
  
  // other gets...
}

@alexruzenhack
Copy link
Contributor Author

The proposed solution agreed was to create a status control file with an enum and helper methods like isSuccess to be used in the components.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Archived in project
Development

No branches or pull requests

1 participant