HW5 #8
HW5 #8
Conversation
| @@ -1,9 +1,98 @@ | |||
| document.addEventListener("DOMContentLoaded", function(event) { | |||
| document.querySelector("#portfolio-card-theme-switcher").addEventListener('click', changeTheme); | |||
There was a problem hiding this comment.
У тебя отличная реализация с точки зрения JS без фреймворков, Именно так писали раньше до реакта и классов. С появлением классов все стали делать реактивные компоненты. Почему решил именно в функциональном стиле написать?
There was a problem hiding this comment.
Минус тут такой - отображение, логика, модель данных, все в куче. Какие плюсы?
There was a problem hiding this comment.
Вообще изначально я хотел сделать, что-то типа класса генератора, но в итоге все выливалось в конструктор без параметров и один осмысленный метод, - generate. И я решил, сделать на функциях. Плюсы - удобно вносить мелкие правки, при этом можно быть уверенным, что ничего не сломается и не будет side эффектов, я имею в виду, например, изменить что-то для процента или name, просто дописываем / меняем configureName или configurePercent и не беспокоимся про все остальное, конечно, подобное справедливо на 100% только для чистых функций. Также из плюсов, простота кода и разработки, если делать все аккуратно (сохранять одинаковую структуру для всех функций и т.п.). Возможно еще быстрее будет работать, все-таки проще уже сложно сделать. По поводу минусов, я старался разделить, хоть и условно логику и отображение, то есть в начале всегда идут классы, потом методы типа configure, потом уже все eventListener`s. Я думал, еще сделать еще какой-то mapping, к примеру для сохранения формы, чтобы инпут был ключем, а то что его подменяет значением, а потом в цикле просто пройти и в одной строке все заменять, вроде это бы "сгладило минусы", но решил оставить как есть.
There was a problem hiding this comment.
Мне больше по душе реактивность, но я готов принять аргументирований выбор. Сделай разделение по файлам, в js, за тайпскрипт накину ещё 15 баллов, если импорты в браузере не заработают, поменяй в rollup, "esm" на "iife" и все заработает. В функциональном стиле важна разбивка на файлы и структурность и логика кода.
ps. Вариант с реактивностью архитектурно бы выглядел так: есть класс скилл, и модель данных состоящая из массива скилов. Есть контроллер отвечающий за добавление и удаление элементов туда, он не взаимодействует с дом деревом. есть классы SkillListView и SkillView, они занимаются отрисовкой данных из модели в DOM. При изменении даннных в модели, SkillListView перерисовывает все, или только то что изменилось. Это FYI
There was a problem hiding this comment.
Дело в том, что я это писал сразу после первой лекции, на которой эту домашку выдали, соответственно про реактивность тогда вроде не упоминалось. Переделал на typescript, немного изменил архитектуру так как мне кажется, что если бы я просто переписал, что уже есть, то различия между js и typescript были бы минимальны, поэтому добавил классы, но в концептуальном плане все осталось +-также, разве что повысилась возможность повторного использования кода. Еще по тайпскрипту возникло пару вопросов:
- Нужно ли всегда указывать тип переменной
- Принято ли делать поля публичными или работать через геттеры и сеттеры. Например, у меня в классе SkillForm все поля приватные, геттеры и сеттеры я не делал, так как они мне не нужны были, но в общем, если бы мне они понадобились, то как лучше сделать через publc или get/set?
- Есть ли способ сделать replace без querySelector по классу, то есть не так написать
this.skillForm.querySelector('.' + element.className).replaceWith(...), а как-то таким образом:
this.skillForm.querySelector(this.saveButton).replaceWith(...) может используя что-то другое, а не querySelector, Это я к тому, что у элемента по которому делаем select может не быть класса или будет несколько с одинаковыми классами - Есть ли способ вынести то, что связано с eventListener-ми куда-то отдельно и надо ли вообще это делать или то, как сделано у меня это норм,
- В какой ситуации использовать export с default, а когда без него
There was a problem hiding this comment.
- Тайпскрипт не должен мешать разработке, он должен ее упрощать, так что ты волен настраивать типизацию как тебе удобно. Но в большинстве случаев лучше обьявлять тип всех данных. Хотябы поверхностно.
- Проще работать с публичными полями. Но все зависит от задач и реализации. В JS есть get/set методы, которые позволяют перехватывать обращения или присваивания публичных атрибутов класса, так что всегда можно их добавить, не повредив код. Поэтому мое мнение что изначально делать сеттер геттер кастомным методом смысла нет
- Можно, ты можешь хранить ссылку на элемент в поле класса или переменной и получить быстрый доступ к элементу без querySelector, https://developer.mozilla.org/ru/docs/Web/API/Node/replaceChild
- В целом можно и так
- Лично я предпочитаю никогда не использовать export default, поскольку через обычный поиск потом не найти этот код, тк программист может произвольное имя задать этому экспорту. Но обычно если есть много экспортов из файла, то дефолтным делают основной, если такой есть.
| {qualifierName: 'placeholder', value: 'text'}, | ||
| {qualifierName: 'type', value: 'Name'}, | ||
| {qualifierName: 'pattern', value: '^[A-z][a-z\\s]*$'}, | ||
| {qualifierName: 'required', value: 'true'}, |
There was a problem hiding this comment.
Интересно сделано с валидацией!
Заменил export default на export, и сделал replace как в ссылке, что вы скинули |
There was a problem hiding this comment.
Что понравилось:
- Самобытно, больше опыта в разработке и эта самобытность станет собственными хорошими решениями, новыми библиотеками и прочими полезностями
- Оправданый код, это ООП без реактивности, код логичен
- Подход к деталям
- Валидация
- Тайпскрипт + 15баллов
Что не понравилось:
- Стили и верстка
- Скилы получились самостоятельными и не встраиваются в проект визитки визуально и цвета и все остальное отличается от общей темы визитки
Итог: 40 баллов из 40
No description provided.