1
00:00:00,184 --> 00:00:04,752
Let's talk about testing numbers. Here in

2
00:00:04,752 --> 00:00:06,360
the getLoanApplicationDataFromInputs

3
00:00:06,360 --> 00:00:08,946
function, I take data from the input

4
00:00:08,946 --> 00:00:11,433
fields in the page and create a

5
00:00:11,433 --> 00:00:13,497
LoanApplication object with it. This

6
00:00:13,497 --> 00:00:16,174
function is used in here in the

7
00:00:16,174 --> 00:00:18,253
validateApplication function. It gets the

8
00:00:18,253 --> 00:00:20,748
loan application and checks if all the

9
00:00:20,748 --> 00:00:23,411
fields are inputted correctly, for

10
00:00:23,411 --> 00:00:25,253
instance, by looking at the application

11
00:00:25,253 --> 00:00:28,043
date of birth. If that is undefined, the

12
00:00:28,043 --> 00:00:30,867
date wasn't entered, and the user can't

13
00:00:30,867 --> 00:00:34,144
save the application. Let's try that. I'll

14
00:00:34,144 --> 00:00:36,884
modify an existing application. Let's type

15
00:00:36,884 --> 00:00:39,532
letters in here instead of numbers and try

16
00:00:39,532 --> 00:00:43,087
and save it. Oh, that worked. It has been

17
00:00:43,087 --> 00:00:46,065
added to the list. Let's see that. Oh, it

18
00:00:46,065 --> 00:00:49,114
didn't really work. The date is scrambled,

19
00:00:49,114 --> 00:00:51,554
and the fields are filled with not a

20
00:00:51,554 --> 00:00:54,134
number values. Let's try something else.

21
00:00:54,134 --> 00:00:57,126
I'll clear the fields, and I'll type in a

22
00:00:57,126 --> 00:01:00,151
date with letters. This also calls the

23
00:01:00,151 --> 00:01:01,904
validateApplication function. This is

24
00:01:01,904 --> 00:01:05,003
actually seen as a valid date once all the

25
00:01:05,003 --> 00:01:07,468
fields are filled in. Okay, well, let's

26
00:01:07,468 --> 00:01:11,522
see why that happens. That should be here

27
00:01:11,522 --> 00:01:14,455
somewhere. This is it. I get the values

28
00:01:14,455 --> 00:01:17,131
for month, date, and year from the input

29
00:01:17,131 --> 00:01:19,654
fields here, and then I check if they are

30
00:01:19,654 --> 00:01:22,928
empty or not. And if not, I create a date

31
00:01:22,928 --> 00:01:25,512
regardless of what's in the values. That's

32
00:01:25,512 --> 00:01:29,124
what is going wrong. Okay, let's fix this.

33
00:01:29,124 --> 00:01:30,935
Instead of checking if the string is

34
00:01:30,935 --> 00:01:34,104
empty, I can check if it contains a number

35
00:01:34,104 --> 00:01:37,561
with Number.isInteger, like this. This

36
00:01:37,561 --> 00:01:40,737
returns true if the number is actually an

37
00:01:40,737 --> 00:01:43,893
integer and false if it isn't. And I'll do

38
00:01:43,893 --> 00:01:46,498
that for all the values. Okay, let me make

39
00:01:46,498 --> 00:01:50,121
it a bit more readable and save it and

40
00:01:50,121 --> 00:01:52,895
test it. Let's type in a date with letters

41
00:01:52,895 --> 00:01:55,659
and see if that works. And no, the

42
00:01:55,659 --> 00:01:58,639
validation message doesn't go away, so

43
00:01:58,639 --> 00:02:02,683
this isn't valid. What if I save it? Let's

44
00:02:02,683 --> 00:02:05,804
see. No, it isn't in the list, so it isn't

45
00:02:05,804 --> 00:02:09,542
saved. That worked! So what does

46
00:02:09,542 --> 00:02:12,223
Number.isInteger test? Let's take a look

47
00:02:12,223 --> 00:02:14,467
at it in the developer tools console. In

48
00:02:14,467 --> 00:02:17,194
Chrome, I can get to this by pressing F12.

49
00:02:17,194 --> 00:02:21,164
Let's test Number.isInteger on the string.

50
00:02:21,164 --> 00:02:23,771
That is false because that's not an

51
00:02:23,771 --> 00:02:26,623
integer. And what if I test it on 25? That

52
00:02:26,623 --> 00:02:29,750
is true because that is an integer. And

53
00:02:29,750 --> 00:02:34,028
25.3. That is not an integer. And what

54
00:02:34,028 --> 00:02:37,124
about 25.0? That is also an integer

55
00:02:37,124 --> 00:02:41,613
because 25.0 is stored as 25 without the

56
00:02:41,613 --> 00:02:44,310
decimal. And what about something else

57
00:02:44,310 --> 00:02:47,728
like null? Also not an integer. And

58
00:02:47,728 --> 00:02:51,904
infinity. That's also false. Okay, this is

59
00:02:51,904 --> 00:02:54,882
very reliable. In JavaScript, all numbers,

60
00:02:54,882 --> 00:02:57,681
so integers and also floats, are all

61
00:02:57,681 --> 00:02:59,859
stored in the same way. They are all

62
00:02:59,859 --> 00:03:02,369
stored as double-precision floating-point

63
00:03:02,369 --> 00:03:04,708
numbers. Because of this storage

64
00:03:04,708 --> 00:03:06,837
mechanism, some larger numbers can lose

65
00:03:06,837 --> 00:03:09,164
precision. For instance, if I take this

66
00:03:09,164 --> 00:03:12,235
number and add 1 to it, it is still the

67
00:03:12,235 --> 00:03:14,144
same because of the rounding that happens

68
00:03:14,144 --> 00:03:17,777
because of its storage mechanism. And if I

69
00:03:17,777 --> 00:03:19,978
add 5 to the same number, you'd expect

70
00:03:19,978 --> 00:03:22,787
something else than this, right? When we

71
00:03:22,787 --> 00:03:24,807
use integers, we can prevent losing

72
00:03:24,807 --> 00:03:26,766
precision by using numbers that fall in

73
00:03:26,766 --> 00:03:29,515
between the MAX_SAFE_INTEGER value, which

74
00:03:29,515 --> 00:03:31,803
is this one, and the MIN_SAFE_INTEGER

75
00:03:31,803 --> 00:03:35,134
value, which is this one. And we can

76
00:03:35,134 --> 00:03:37,624
easily test if an integer falls in between

77
00:03:37,624 --> 00:03:41,126
these values with the Number.isSafeInteger

78
00:03:41,126 --> 00:03:44,039
function. We don't need to test for safe

79
00:03:44,039 --> 00:03:45,891
integers in our application, but just for

80
00:03:45,891 --> 00:03:49,134
fun I'll implement it here instead of

81
00:03:49,134 --> 00:03:51,614
Number.isInteger. It works the same. It

82
00:03:51,614 --> 00:03:53,722
only does an additional check to see if

83
00:03:53,722 --> 00:03:55,821
the value falls between the safe max and

84
00:03:55,821 --> 00:03:58,883
min values. And let's see if it still

85
00:03:58,883 --> 00:04:01,953
works. Yep, it works. So you can easily

86
00:04:01,953 --> 00:04:06,144
test to see if something is an integer by

87
00:04:06,144 --> 00:04:08,283
using Number.isInteger. And if you want to

88
00:04:08,283 --> 00:04:10,664
work with big integers and don't lose

89
00:04:10,664 --> 00:04:17,000
precision, you should check if they are safe with Number.isSafeInteger.

