Formatter ip input.

Question

Witam,

tworzę aplikację w której będę wprowadzał adresy ipv4, i chciałbym zrobić formmatter w inpucie (automatyczne dodawanie kropki np 192.168.1.1) problem w tym że adres ip jest dość nieregularny, i np gdy będę podawał adres którego oket zawiera mniej niż 3 cyfry to tę kropkę będę dodawał ręcznie, a gdy oktet będzie składał się z 3 cyfr to kropka ma być dodawana automatycznie, mam nadzieje że jasno opisałem problem, proszę o podpowiedź jak się do tego problemu zabrać, z góry dziękuje za pomoc.

Answer 1

Problem w tym, że nie masz jak sprawdzić, czy user chce podać w danej części jedną, dwie czy trzy cyfry, musi Ci to zasygnalizować ręcznie. Nigdy nie bawiłem się w takie coś z ip, ale taki mój jeden z pierwszych pomysłów na szybko to może zrobić cztery inputy i gdy user wpisze trzy cyfry to z automatu przechodzisz do kolejnego, a gdy dwie to musi ręcznie wpisać kropkę lub tabem się przesunąć.

Widziałbym to np. tak, że masz cztery inputy i między nimi już ustawione kropki (np. po prostu znaczniki <span> między inputami, oczywiście wystylowane tak jakgdyby był to jeden duży input z miejscami na numery i kropami, ale layut to już najmniejszy problem i zakładam, że nie to jest przedmiotem pytania) i przejście do kolejnego inputa byśmy wyzwalali na tab (standardowo) oraz dodatkowo na próbę wpisania kropki, co byłoby wg mnie dobre pod względem UX.

Potem oczywiście w JS sobie ściągniesz wartości z tych inputów i scalisz w jeden adres plus można ewentualnie poddać jakieś walidacji - w sumie walidacja byłaby fajna już na etapie tworzenia kolejnych członów.

Jak znajdę wieczorem chwilę to spróbuję coś skrobnąć na codepen o co mi chodzi, bo może trochę zawile napisałem :)

Comments

Walidacja będzie już po stronie serwera (przy pomocy odpowiedniego wyrażania regularnego), więc o to się nie martwię, jednakże chcę to zrobić w atrakcyjny dla użytkownika sposób, gdyż docelowo to trafi na front end w angularze, ale to już żaden problem.

---

No to wydaje mi się, że mój sposób mógłby być dobry... kurde zaciekawiłeś mnie i chyba w weekend usiąde sobie do tego na codepen :) A z tą walidacją to serwer to rzecz oczywista, ale we froncie też warto ją robić choćby ze względu na wygodę usera i minimalizowanie strzałów do API.

---

Dla numeru telefonu zrobiłem, ale z nim sprawa jest łatwiejsza bo jest regularny 

$(document).ready(() => {
    let input = $("#inputNumber");

    input.on("keypress", (event) => {
        let licznik = input.val().length;
        if ( ((licznik === 3 || licznik === 7) && event.key !== '-' ) && licznik <= 7) {
            input.val(input.val() + "-");
        }
    });

});

z racji że on jest w formacie 123-123-123, bo obecnie mało niemal każdy ma już tel. kom.

---

A na jakiej podstawie tak oceniasz? Troszkę wydaje mi się, że zbyt pochopnie podchodzisz to tego zakładanego formatu numeru telefonu - masz to poparte jakimiś badaniami i statystykami z aplikacji?

Numer telefonu to sprawa dość skomplikowana i tak naprawdę najbezpieczniej po prostu ograniczyć się do zwalidowania cyfr i ewentualnego plusa na starcie. Ja podchodzę też dość swobodnie od strony usera do białych znaków, tj. pozwalam mu je stosować, tak samo jak myślniki w dowolnej dla niego formie (co 3 cyfry, co 5, jak mu wygodnie, rybka mi to) i potem przy zapisie obrabiam numer do swoich potrzeb. To jest wg mnie lepsze pod kątem UX, lepiej żeby user byl zadowolony z apki niż wkurzał się np. że musi tu podać numer w konkretnym formacie... Z takim podejściem można łatwo stracić trochę userów, co biznes niekoniecznie może zaakceptować :)

Moim zdaniem każda tak rygorystyczna walidacja powinna być poparta obserwacjami statystyk i zachowań userów.

---

niestety takie są założenia projektu, i nie mogę ich zmieniać

---

Że co??? Sorry, ale ja bym taką osobę wyśmiał... Z takim podejściem to uwierz mi, że projekt szybko wybuchnie...  nie bierz tego do siebie, ale czasami tak to się kończy, jak programiści zbyt posłusznie słuchają pomysłów biznesu praktycznie bez konsultacji z UX i testerami... Dlatego ja w ostatnim czasie coraz bardziej zaczynam doceniać pracę działów UX i testerów oraz badaczy bo są oni na prawdę mega ważnym ogniwem w procesie wprowadzania różnych ficzerów biznesowych... Ale to jak widzę zależy od polityki firmy... jedna chce zrobić dobry produkt dla usera, a druga przysłowiowe g... byleby szybko się pozbyć tematu...

---

Faktycznie, masz rację, obecnie zajmę się tym adresem ip, zaś telefon zostawię użytkownikowi dowolność w wprowadzaniu, walidując jedynie na podstawie wyrażenia regularnego, czasem dobrze jednak posłuchać kogoś mądrzejszego od siebie, ponieważ nie lubię robić za przeproszeniem gówna, a to mój pierwszy poważniejszy projekt, więc również brak stażu, wybacz.

---

Źle mnie odebrałeś, ja nie uderzałem do Ciebie personalnie, tylko bardziej do sposobu organizacji pracy i tworzenia kodu w firmie :) Ja uważam zawsze, że warto dać userowi maksymalną dowolność w takim stopniu, w jakim jesteśmy w sposób pewny potem te dane obsłużyć. Ważne jest tu jednak to słowo "pewny sposób". To znaczy np. te białe znaki, myślniki itp. łatwo możemy usunąc regexp ale trzeba też umieć znaleźć umiar i ten punkt graniczny - na co pozwolić, a co jednak wymuszać i to jest bardzo trudne i nawet wielu seniorów ma często problem ze znalezieniem tej właśnie granicy.

Kiedyś miałem ciekawy problem, który bardzo dużo mnie nauczył, szczególnie pokory do własnych zapędów programistycznych :) Temat trochę z doskoku, chodziło w pewnej apce o dodanie walidacji numerów pesel. Wsio fajnie, mamy konkretny algorytm sumy kontrolnej no i bajka, ficzer do napisania w godzinkę co nie? No i tak też myślałem... aż się na prodzie nagle okazało, że pewien starszy mocno już pan miał zły numer pesel, tzw. niezgodny z algorytmem sumy kontrolnej, ale wpisany w dowód... i ups... A okazało się, że kiedyś gdy nie było takiej informatyzacji to zdarzały się pomyłki i urzędnicy wpisywali błędne numery, ale zgodnie z prawem są one ważne... Dlatego od teraz mocno uważam przy walidacjach, tak sam np. z numerem dowodu... nowe numery mają konkretne reguły i sumy kontrolne, ale stare nie... a nawet jak piszesz apkę dzisiaj, to trzeba zawsze być świadomym tego, czy istnieje ryzyko np. wprowadzania do bazy danych osób już nieżyjących? (tak też ja miałem, przez co trafiłem na owe błędne pesele :)

O walidacji można by dyskutować godzinami, a i tak nie uwzględnilibyśmy wszystkich corner cases :

---

Czasem tak bywa że coś jak na pierwszy rzut oka wydaje się łatwe, to tak naprawdę jest sporo problemów później.

---

Dokładnie... dlatego dzisiaj już wiem, że szacowanie czasu na kodowanie trzeba szacować w dniach lub tygodniach co najmniej... nigdy w godzinach, bo to się szybko może na nas zemścić :)

---

Zdaje mi się że udało się rozwiązać problem, tu zamieszczam kod może komuś się przyda.

Wrzucam kod na JSFiddle

https://jsfiddle.net/patryk95/zh0u5cg8/37/