Możesz często używać biblioteki narzędziowej javascript dla swojej aplikacji. Albo po to, aby przyspieszyć proces tworzenia aplikacji, albo po prostu po to, aby mieć jakąś funkcję użytkową, która działa i została przetestowana. Niektóre popularne biblioteki użytkowe, które znamy to lodash i underscore.

Czy kiedykolwiek używałeś biblioteki użytkowej do sprawdzenia czy zmienna jest poprawną liczbą? Poprawna oznacza, że wartość nie spowoduje błędu lub nie zwróci nieoczekiwanego wyniku, jak NaN. Jeśli masz zależność od lodash lub underscore, możesz być kuszony, aby użyć tej funkcji isNumber. Wygląda na to, że właśnie to robi, prawda?

Przyjrzyjmy się zarówno implementacji lodash jak i underscore dla funkcji isNumber.

Obydwie popularne biblioteki mają podobną implementację. Porównują one zmienną typu Javascript class name z ciągiem znaków . Dotyczy to nie tylko typu Number, ale również innych typów takich jak Date, function, etc.

Możesz myśleć, że to jest w porządku, ale czy zdajesz sobie sprawę, że NaN jest również Number w Javascript? NaN w javascript jest Liczbą, która reprezentuje wartość: Not-A-Number. Trochę zagmatwane, prawda? Możesz to sprawdzić samemu w konsoli javascript.

toString.call(NaN)
// -> 

Więc, użycie metody isNumber nie jest tak naprawdę poprawnym sposobem dla powyższego przypadku użycia. Potrzebujemy innej walidacji, czyli sprawdzenia czy numer nie jest NaN . W efekcie otrzymamy coś takiego.

const isValidNumber = _.isNumber(obj) && !isNaN(obj)

Co więc z funkcją isDate? Co może potencjalnie spowodować problem?

Próbuj zainicjować nieprawidłowy obiekt Date, Jak new Date("31/1/2019") lub new Date("test123") . Wartość wynikowa nadal będzie obiektem Date, ale będzie to nieprawidłowy obiekt Date. To prawdopodobnie spowoduje, że twoja logika związana z datą będzie wadliwa. Dlatego powinniśmy dodać kolejny krok do walidacji obiektu Date, być może ten jest wystarczający:

const isValidDate = _.isDate(obj) && !isNaN(obj.getTime()) 

Podsumowanie: