Прошу прокомментировать код JavaScript?

Question

[Иван Трофимов]

Многие мои пользователи впадают в ступор, когда слышат фразу "придумайте пароль посложнее".
Тренировал JavaScript и написал мини-сервис, который должен помочь не впадать в ступор при этой фразе ))

Демо: https://htmlpreview.github.io/?https://github.com/...
Исходники: https://github.com/trofivan/strong-password

Прошу прокомментировать код, что можно улучшить?

UPD: вынес методы и свойства классов Password и Questions в прототипы

Answer 1

[Николай]

На скидку:
файл password.js
1. low, medium, high стоит оформить в виде enum'а.
2. методы класса перенести в прототип.
файл questions.js:
1. так же методы - в прототип
файл page.js
1. я бы разбил на два компонента - собственно форма придумывания пароля и и форма попыток ввода. Это два независимых блока ну и файликов к ним тоже 2.
2. не использовать id и поиск по id.
3. Прямая работа с DOM в реалиях 2016 года - это не очень хорошо. Хотелось бы какой-то data-binding видеть(тут уже что вам больше нравится).

По поводу функционала:
Стоит добавить какую-то случайность в процесс генерации пароля(те же большие/маленькие буквы неапример).

Comments

[Николай]

Иван Трофимов: да, правильно. Конкретно в вашем случае ничего страшного не произойдет, и можно оставить как есть. При создании нового экземпляра класса все внутренние свойства будут создаваться заново, т.е. для каждого объекта будет отводиться память под все функции. (Да, v8 уже достаточно умён и не делает так, но общее поведение такое). В случае с прототипом - будет один единственный объект-прототип, и функция будет вызываться из этого объекта по цепочке наследования. Поэтому считается правилом хорошего кода выносить методы(а иногда и свойства) в прототип.

[Иван Трофимов]

Случайно удалил прошлый комментарий, вот с дополнением:

>> 2. методы класса перенести в прототип.
Правильно понимаю, что должно быть что-то подобное для всех методов:
Password.prototype.getAnswers = function () {
return answers;
};
В чём преимущества такого подхода?

>> 1. я бы разбил на два компонента - собственно форма придумывания пароля и и форма попыток ввода. Это два независимых блока ну и файликов к ним тоже 2.
Сначала хотел разбить, но эти два блока сильно зависят друг от друга и разбивать на два отдельных класса, а потом описывать взаимодействие между ними посчитал более накладным.

>> 2. не использовать id и поиск по id.
Правильно понимаю, что лучше во всех элементах использовать атрибуты data-* и уже с ними взаимодействовать?

[Николай]

Иван Трофимов: data- аттрибуты тут непричем, просто используйте классы, а не идентификаторы. В случае переиспользуемых компонент это очень существенно.
По поводу взаимодействия компонент - я бы всё таки попытался разбить, т.к. отвечают они за совсем разные вещи. А взаимодействие между компонентами - это вполне нормальное явление.

[Иван Трофимов]

Николай: придерживался подхода, что если используется один объект на странице, то задавал ему id а не class и к нему уже обращался.

[Николай]

Иван Трофимов: я понимаю, да, просто часто получается что делаете для одного места, а потом где-то хотите использовать(в другом проекте например) и с id-шниками могут возникнуть проблемы. Ну и если уж всё таки используете id - нет особого смысла задавать в селекторе ещё и тип элемента(хоть так и немного понятнее).

[Иван Трофимов]

Николай: согласен, логично. Спасибо за ценные комментарии.

[Иван Трофимов]

Николай: UPD: вынес методы и свойства классов Password и Questions в прототипы
https://github.com/trofivan/strong-password/tree/m...

Answer 2

[Дмитрий Еремин]

Пользователи впадают в ступор от фразы "придумайте пароль посложнее", потому что, обычно, в таких случаях, пользователю показывают требования к паролю

Например:

• Должна быть минимум одна заглавная буква
  
• Должна быть минимум одна цифра
  
• ...
  
• Должен быть использован минимум один спец.символ