Feat/number input 2

[M-i-k-e-l]

Description

NumberInput - a new take on the component
Update the UI in onBlur
Removed tests from the npm package

WOAUILIB-2640

Changelog

NumberInput - new component (⚠️ also removed tests from the npm package)

[lidord-wix]

@M-i-k-e-l
Just before I'll review the code:

1. Looks very good!
2. When entering a large number the NumberInput stretches its width to the screen width (and more) and in the guidelines they ask to keep an s5 margin from each side.
3. Just to make it easier to review - how different is this PR's implementation from the previous one? should I review all the files? is there something I should focus on more?

[M-i-k-e-l]

@M-i-k-e-l Just before I'll review the code:

Please ping me in another way if you think you are blocked from reviewing because when I get an email with a comment I assume you've already reviewed it and I may not immediately look at the comments themselves, this delays the release on the component...

1. Looks very good!
2. When entering a large number the NumberInput stretches its width to the screen width (and more) and in the guidelines they ask to keep an s5 margin from each side.
3. Just to make it easier to review - how different is this PR's implementation from the previous one? should I review all the files? is there something I should focus on more?

1. 10x!
2. Fixed (partly in the component and partly in the screen); there's still a bug with a long text where the trailingAccessory is pushed, this is a bug in TextField see here.
3. Very different.

[lidord-wix]

I wrote some comments on the code (it looks like a lot but many of them are about naming and small stuff), and more general comments:

1. I still see an issue with a long input - you can't see the last char you typed (it's cut), you can also see that the left margin is kept when the right one is not.
2. If you do keep the two example screens, consider adding another file for all the shared code (processInput, onChangeNumber, validation functions, and so on).
3. If doing changes as I suggested, don't forget to update the relevant API files.
4. BTW, I already wrote some of the comments I added here in the previous PR.. that's why I asked about the diffs before I did the review :)

[M-i-k-e-l]

I wrote some comments on the code (it looks like a lot but many of them are about naming and small stuff), and more general comments:

1. I still see an issue with a long input - you can't see the last char you typed (it's cut), you can also see that the left margin is kept when the right one is not.

Yes, I wrote about this in the previous section (number 2 here)

2. If you do keep the two example screens, consider adding another file for all the shared code (processInput, onChangeNumber, validation functions, and so on).

I think we want to change the screens, but I am not sure about shared code in screens, it can make the example less clear which might be more important.

3. If doing changes as I suggested, don't forget to update the relevant API files.

ok

4. BTW, I already wrote some of the comments I added here in the previous PR.. that's why I asked about the diffs before I did the review :)

ok

[M-i-k-e-l]

@lidord-wix - I've changed the screen according to the requests

@ethanshar - could you please take a look at these two commits 🙏
They add a little support for function component in our ExampleScreenPresenter (is there a better way to do it?) and support centered for TextField's validationMessage, add some memoization and fix typescript

[lidord-wix]

I wrote some comments on the code (it looks like a lot but many of them are about naming and small stuff), and more general comments:

1. I still see an issue with a long input - you can't see the last char you typed (it's cut), you can also see that the left margin is kept when the right one is not.

Yes, I wrote about this in the previous section (number 2 here)

Oh I thought you only wrote about the case with a trailingAccessory

2. If you do keep the two example screens, consider adding another file for all the shared code (processInput, onChangeNumber, validation functions, and so on).

I think we want to change the screens, but I am not sure about shared code in screens, it can make the example less clear which might be more important.

3. If doing changes as I suggested, don't forget to update the relevant API files.

ok

you forgot :)

4. BTW, I already wrote some of the comments I added here in the previous PR.. that's why I asked about the diffs before I did the review :)

ok

[lidord-wix]

@M-i-k-e-l
I think you missed some of my comments, please take a look again :)

[ethanshar]

Raising another option here..
What if instead of creating the same methods for function components, you'll add options object for state, setState.
if the user pass them, you will use them, otherwise you'll use this.state, this.setState

[M-i-k-e-l]

Done

[lidord-wix]

Approved, see my last two comments :)