Алексей Варфоломеев, а если по бизнес-требованиям надо? финансы, биржи, букмекерки ещё больше могут захотеть.
Тут уже виртуализацию на фронте крутить надо, данные стримить с бэка, что тоже уже выходит за рамки типичных задач.
Добавить сверху условие "над кодом работает команда, код должен быть поддерживаемым годами", то тут уже совсем другие правила игры))
Посмотрите реализации каких-нибудь "react input mask". Там вагон работы надо сделать. Особенно, работа с курсором / selection, когда происходит форматирование.
Руслан Янборисов, попробуйте исключать не "группу пробельных символов (\s)", а "ненужные символы (не цифра, не буква, итд)". Иначе можно долго с edge-cases играться.
<крик души>
Очень Вас прошу, почитайте сначала про JS, а потом уже используйте более продвинутые технологии.
И научитесь гуглом пользоваться.
</крик души>
1) Вбиваете в запрос "js convert object to array"
2) Браво
Tshmt, что 2 модели, что 20 - просто объём кода. "Сложные" - это понятие относительное. Кому-то гостевая книга будет "сложно", а кто-то проектирует Amazon/Ebay без особых усилий.
А не проще вбить адрес в Yandex Geocoder API и дальше уже плясать от результата? Я не знаю, что должна быть за регулярка, которая проверить "корректность адреса".
В любом раскладе, Array.prototype.sort - это мутирующая функция. Конечно, на созданный в рантайме массив это не особо повлияет, но по каномам такое писать нельзя))
Я бы сказал, что вообще нет смысла заморачиваться по поводу "как лучше писать фп или ооп". Надо писать чтобы работало и поддерживать можно было (если нужно, конечно).
Уметь понимать существующую и писать в том же стиле, согласно принятым решениям - обязательно.