feat(BigNumberInput): Extendable component

[fernandomg]

Closes #26

Description:

This PR includes a modification of big-number-input library.

The original idea was to include it as it is, and then modify it to avoid using "BigNumber" dependencies. It was impossible as its current implementation relies on that library to handle max/min values.

Thus, I modified it to use viem's parseUnit and formatUnit, which use the native BigInt behind the scenes.

I also added a couple of missing functionalities, so we don't need to always rely on a personalized component:

1. disabled attribute is now supported
2. an error callback function was added to inform the consumer of any validation error
3. min/max values are now working properly
4. now decimals prevent the user from typing more than the valid amount of decimals.

Also, tests were added to ensure consistency in the functionality.
To be able to test a react component, some dependencies were added:

1. @testing-library/react
2. @testing-library/user-event
3. @testing-library/jest-dom
4. jsdom

Also, vitest configuration was slightly modified.

Steps:

You can test it in /tokens, there's ADemoInput component being rendered with default values

Type of change:

• New feature
• Bug fix
• Breaking change
• Enhancement
• Refactoring
• Chore

How Has This Been Tested?

• Manual testing
• Automated tests
• Other (explain)

Remember to check that:

• Your code follows the style guidelines of this project
• You have performed a self-review of your code
• You have commented your code in hard-to-understand areas
• You have made corresponding changes to the documentation
• Your changes generate no new warnings

Screenshots

Screen.Recording.2024-06-06.at.8.17.41.PM.mov

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
dappbooster	✅ Ready (Inspect)	Visit Preview	Jun 7, 2024 4:41pm

[gabitoesmiapodo]

Just checked the functionality (not the code), it seems to work all right.

Let's wait for a more technical review from @luchobonatti before merging.

[luchobonatti]

@fernandomg Nice job, the code is clean and understandable and has tests! :D !
I have some doubts about this component:

• I'm not sure about the component name "BigNumberInput". What about CurrencyInput, TokenInput, AssetInput?
• Is there a way to format the number in the input? like changing the thousand separator and decimal separator?
• What happens in a real use case when the user changes the decimals prop and the input has a previous value with another decimals?
• Shouldn’t handling the input with bigInt instead of number-as-string be better?

4. now decimals prevent the user from typing more than the valid amount of decimals.

• In uniswap, you can put any amount of decimals in any token. I guess that we can take a similar approach here and handle the decimal amount behind the scenes. What do you think?

[luchobonatti]

In a real use case this value can change by the user.

[fernandomg]

hey @luchobonatti, thanks for the thorough feedback!

• I'm not sure about the component name "BigNumberInput". What about CurrencyInput, TokenInput, AssetInput?

With those names, you're restricting the component's use. I'm not a fan of that approach. At most "BigInput" or "BigIntInput" but both seem to be a bit off.

• Is there a way to format the number in the input? like changing the thousand separator and decimal separator?

Yes, there is, on a different task. As we talked in Slack.

• What happens in a real use case when the user changes the decimals prop and the input has a previous value with another decimals?

That must be something that the user implementing the state around the component should handle, why the component must reset its state on those conditions?

Maybe you're trying to build an "AmountInput" with all that functionality, but that shouldn't be part of a base component.

• Shouldn’t handling the input with bigInt instead of number-as-string be better?

Well, my reasoning was: If I'm giving the control to the "implementer", that "implementer" will have the necessary information to cast the value to bigInt or BigNumber, or Big, or whatever they want.

With all that said, what will be the most common case? Because if everybody is casting the value back to a BigInt, we can change the returned value. Even more, we can give the option to opt for BigInt or HumanReadable. WDYT?

4. now decimals prevent the user from typing more than the valid amount of decimals.

• In uniswap, you can put any amount of decimals in any token. I guess that we can take a similar approach here and handle the decimal amount behind the scenes. What do you think?

We shouldn't allow more than the required amount of decimals. That's why I copied the behavior from the gnosis-bridge implementation.

I'll wait for your feedback before moving fw with the modifications.

Thanks again and keep them coming!

[luchobonatti]

wait for your feedback before moving fw with the modifications.

Thanks again and keep them coming!

Well, I think all is there. Thank you for your time to well-answer my doubts!
I think you are right with the current approach. In custom cases the user should create a Wrapper component to handle another use cases around this base component, so, is OK for me.