It's confusing to have a variable named the same as a type, and have it be of a different type 🙃

why is this necessary?

It is not necessary. I added it in case I could create multiple wallets as in other wallets, for example Daedalus.

what do you think about adding (as documentation) a state diagram showing what triggers redirects and to where? do you think it would be overkill? should it be apparent in the code and we're making it hard to follow?

I think it's a good idea since community developers will understand the source code more easily. I will add it

from what I understand, if there's an error updating the transactions, getting node settings or updating the account state, we'd redirect to the walet page.

But if there's an error redirecting to the wallet, then we'll redirect to the input keys screen.

And if there's an error in ^, then we log the error.

I don't think this is intended.

corrected

If it's always used like this, consider swapping the last two parameters and doing:

.then(curry(initializeKeysAndRedirect)(dispatch, password))

If not, you could curry with a placeholder:

.then(curry(initializeKeysAndRedirect)(dispatch, _,password))

Please see the documentation to see what the _ should be, without importing the whole library.

Creating a function inline makes currying redundant.

I think it is more readable to use all the parameters. Will remain incurry (initializeKeysAndRedirect) (dispatch, keys, unlockWalletPassword)

this name is confusing

The function was renamed to handleSubmit

I would'nt bother creating a new state variable for something which can be easily computed from existing ones.

Deleted

this issue persists

hiddenSpendingPassword and setHiddenSpendingPassword does not exists

don't use Promise.all for a single promise

Promise.all is deleted

same comment about optional parameters applies here

deleted

this is duplicated code from the other restoreWallet component

deleted

use Form.Control.Feedback for this.
Also, research the props of that component to see if you can style it by passing a prop (some have a plaintext prop)

If that's not possible, consider using <span>, which is a more idiomatic way to apply styles to inline text, without implying a semantic distinction (<em> is used for emphasis)

span is used instead em

why the º ?

I think there was an accident using keyboard. Corrected

The same comment about Form.Control.Feedback applies here.

I will use it on all input validation.

It's not necessary to generate the AccountKeys object again, since the AccountKeys object is stored already.

this wasn't addressed yet

.then(() => dispatch(push(routes.WALLET)))
.catch(error => {
  console.error(error);
  dispatch(push(routes.WALLET));
});

could be written as

.catch(console.error);
.then(() => dispatch(push(routes.WALLET)))

which IMO is more idiomatic since you'd want to log the error and continue with the chain regardless

also, this is repeated in the initializeKeysAndRedirect function

The suggestion was applied

According to the form, this should not be optional

now mandatory

the password should not be optional. If we got here without a valid password, we should throw

Now not optional

this shouldn't be optional.

Not optional

this type is only used for a definition in the account actions, it could be defined inline there.

Deleted. Not a necessary type

No reducer uses this

Deleted

just check the lenght, this makes all non-latin-script passwords invalid.

This validation is deleted. Now there is a new component used to validate password only with lenght

this wasn't addressed yet

this hints the parameter is optional when it's not

Either go with:

.then(keys =>
  initializeKeysAndRedirect(dispatch, keys, unlockWalletPassword)
);

or:

.then(
  curry(initializeKeysAndRedirect)(dispatch, curry.placeholder, unlockWalletPassword)
);

or change the function signature to receive the keys last, and do:

.then(
  curry(initializeKeysAndRedirect)(dispatch, unlockWalletPassword)
);

It's confusing to curry a function and execute it right away. It might lead a reader to infer the function receives even more parameters and'll be executed later on.

Why nest the form groups? there should be one group per input AFAIK: https://react-bootstrap.netlify.com/components/forms/

on the called component, the function to be called on a change or other event should be called on{event}, to follow a react naming convention present in, for example, the <input> element with its onChange prop

here, it should be called onValidPassword or something like that.

all this variables and hooks could be typed via flow

this file is now innecessary

due to the aforementioned naming convention, this should probably be called validPasswordHandler or somethin like that.

you could export the type of the callback in the called component and import it wherever it's used, to avoid having to type the handlers manuallly every time

I don't understand this. Shouldn't this if be enough?