Skip to content

Remove store usage related to ledger from wallet.js - #2422

Open
marcinbodnar wants to merge 17 commits into
masterfrom
issue-2416
Open

Remove store usage related to ledger from wallet.js#2422
marcinbodnar wants to merge 17 commits into
masterfrom
issue-2416

Conversation

@marcinbodnar

Copy link
Copy Markdown
Contributor

With this PR we are removing all usage of store related to ledger from wallet.js.

@render

render Bot commented Jan 28, 2022

Copy link
Copy Markdown

@marcinbodnar marcinbodnar linked an issue Jan 28, 2022 that may be closed by this pull request
@marcinbodnar marcinbodnar changed the title [WIP] Remove store usage related to ledger from wallet.js Remove store usage related to ledger from wallet.js Feb 5, 2022
@marcinbodnar

Copy link
Copy Markdown
Contributor Author

@stefanopepe
Could you please test it regarding the ledger? The most important things are:

  • does ledger related functionalities are working well
  • does ledger modals appears and hides properly
  • does disable request on the ledger device is properly closing ledger modals.
    Thank you.

@andy-haynes andy-haynes left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good, just a few comments inline.

throw e;
},
() => {
dispatch(checkAndHideLedgerModal());

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this have an await? I see that the createAsyncThunk call that creates checkAndHideLedgerModal has synchronous logic in its payloadCreator argument but since that function is declared async it will still return a Promise. If an await were added to that payloadCreator body later on, an await would need to be added here anyway to avoid fire-and-forgetting a Promise that needed to be waited on. Even worse would be if an error were thrown from checkAndHideLedgerModal then this would potentially lead to an unhandled Promise rejection.

Alternatively we could omit createAsyncThunk for synchronous thunks if we don't think they'll be extended in the future and it doesn't introduce inconsistencies in our action handling.

Comment thread packages/frontend/src/redux/slices/ledger/index.js
async ({ path } = {}, { dispatch }) => {
const { createLedgerU2FClient } = await import('../../../utils/ledger.js');
const client = await createLedgerU2FClient();
dispatch(handleShowLedgerModal({ show: true })).unwrap();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the .unwrap() necessary here if we're not interested in the return value?

`${SLICE_NAME}/handleShowLedgerModal`,
async ({ show }, { dispatch, getState }) => {
const actionStatus = selectStatusActionStatus(getState());
const actions = Object.keys(actionStatus).filter((action) => actionStatus[action]?.pending === true);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can pending be truthy without being explicitly true? Just curious if the explicit true check is required here

@Patrick1904

Copy link
Copy Markdown
Contributor

@marcinbodnar are these changes still relevant after the new Ledger connection implementation?

@marcinbodnar

Copy link
Copy Markdown
Contributor Author

@marcinbodnar are these changes still relevant after the new Ledger connection implementation?

@Patrick1904 yes, but I will probably have to do it again because there are too much conflicts now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Remove store usage related to ledger from wallet.js

3 participants