Когда я только начинал в свой путь в JavaScript и поборол эту тему с присвоением параметров через this, я, вдруг, обнаружил, что у этого ключевого слова есть контекст выполнения...
Спасибо за комментарий) Сейчас постараюсь все разъяснить:
Вопрос - точно ли надо в onChange дополнительным параметром передавать event?
Да, в большинстве случаев такой подход избыточный. API наших полей ввода как раз таки принимает первым аргументом value , чтобы само значение можно было быстро и удобно получить без прямого обращения к объекту события.
Да, у вас там был пример, где вызывается event.preventDefault, но preventDefault не работает для этого события.
Тут пример чисто демонстрационный (может быть и не самый удачный), который показывает, что пользователи могут как-то завязаться в своих функциях-обработчиках именно на второй аргумент event , который они предварительно затипизируют в соответствии с типами самого компонента. И что если мы как-то рискнем поменять тип второго аргумента, то это уже не будет сохранять обратную совместимость в рамках минорного релиза библиотеки, и нам придется выносить всю доработку в мажорную версию.
Если всё-таки прямо нужен event, то всё равно в обработчике onChange абсолютно без надобности PointerEvent.
Изначально, как мы рассчитывали, в рамках компонентной библиотеки все таки есть потребность в разделении сущностей, которая вызвала изменение поля: либо изменено с помощью нативных механизмов поля input, либо изменено с помощью стороннего компонента (при нажатии на кнопку очистки поля).
Ну вот реально, зачем мне координаты клика, очистившего поле ввода?
Тут как раз, да, речь о том, кто именно поменял значение поля, если прилетел PointerEvent , то это кнопка очистки поля.
Можно вызвать изменение текста программно, у нас для этого используется такая утилита
Да, это отличное решение! У нас, в свою очередь, тоже есть подобная утилита для генерации событий, привязанных к полю. Мы тоже начали смотреть в эту сторону, чтобы на программном уровне генерировать события, и отходить от разделения типов объекта event , чтобы он всегда мог иметь один тип.
В TypeScript нет общепринятой терминологии для этого, что создает путаницу в названиях. Программирование - это обширное понятие, а типизация - всего лишь небольшая его часть, собственно, и сама статья посвящана этой части. Называть это "шаблоном типизации" вполне нормально, и это не звучит слишком вычурно или сложно.
"Шаблон стратегия" или "Шаблон Команда" - это же не про Typescript, это про шаблоны программирования, и да, там официальное название - это Pattern.
Если мы говорим про Typescript - "шаблон" или "шаблон типизации" - звучит вполне логично, потому что это тоже паттерн для реализации нужного итогового поведения в результате типизации (например, компонента).
В зависимости от разных контекстов одинаковые слова имеют разный смысл, и это нормально, если, базово, они будут звучать одинаково.
Пример (очень утрированный): слово "Запрос". Если мы говорим в контексте Web - запрос (query) - это отправка "сообщения" на сервер. В контексте баз данных - это команда с нужными операциями, отправляемая к базе данных. (Запрос к серверу и запрос к базе данных - это все программирование).
Ну почему нельзя? В англоязычном коммьюнити повсеместно и, достаточно, устойчиво используется слово "Pattern". Почему бы не перевести это, как шаблон? Особо проблем, лично я, тут не вижу. "Механизм" и "возможность" - слишком абстрактные понятия, как по мне, чтобы они давали хоть какой-нибудь намек на то, что они делают. "Шаблон" же дает некий намек на то, что это какая то предзаложенная последовательность действий.
Кстати, я не против транслитерации в лексиконе) В русскоязычной документации это всегда смотрится неуместно, как по мне)
Точно так же, как и операция - это один из механизмов работы с числами.
Проводя аналогию, если простое объединение типов можно было бы назвать "оператором", так как используется один символ `|`, то в случае с распределенными условными типами, где нужно указание дженерика, условных операторов с ключевыми словом `extends` и т.д - уже сложно называть оператором. Думаю, ты меня понял.
Мой тейк, в данном случае, это предложить русскоязычную адаптацию понятия "фича", которую ты упомянул. Использование слова "фича", по сути, является транслитерацией, все равно что вместо "функции обратного вызова" писать "кАлбэк" или вместо "свойства" - "проп".
Да, я понимаю про что ты. При написании статьи я долго думал, как подходы TypeScript (условное объединение, и т.д) можно объединить в одно ёмкое название. Паттерн, подход... В итоге я решил предложить вариант "Шаблон", так как он чаще всего мне попадался на глаза во время поисков. Других альтернатив на просторе документации Typescript или русскоязычного коммьюнити я не нашел.
1) Пишешь рабочий, но такой себе в плане "правильности", код; 2) Подписываешь его как `TODO: исправить`; 3) git add + git commit + git push; 4) Радуешься, что хотя бы немного оправдался перед коллегами :)
Когда я только начинал в свой путь в JavaScript и поборол эту тему с присвоением параметров через
this, я, вдруг, обнаружил, что у этого ключевого слова есть контекст выполнения...Спасибо за комментарий) Сейчас постараюсь все разъяснить:
Да, в большинстве случаев такой подход избыточный. API наших полей ввода как раз таки принимает первым аргументом
value, чтобы само значение можно было быстро и удобно получить без прямого обращения к объекту события.Тут пример чисто демонстрационный (может быть и не самый удачный), который показывает, что пользователи могут как-то завязаться в своих функциях-обработчиках именно на второй аргумент
event, который они предварительно затипизируют в соответствии с типами самого компонента. И что если мы как-то рискнем поменять тип второго аргумента, то это уже не будет сохранять обратную совместимость в рамках минорного релиза библиотеки, и нам придется выносить всю доработку в мажорную версию.Изначально, как мы рассчитывали, в рамках компонентной библиотеки все таки есть потребность в разделении сущностей, которая вызвала изменение поля: либо изменено с помощью нативных механизмов поля
input, либо изменено с помощью стороннего компонента (при нажатии на кнопку очистки поля).Тут как раз, да, речь о том, кто именно поменял значение поля, если прилетел
PointerEvent, то это кнопка очистки поля.Да, это отличное решение! У нас, в свою очередь, тоже есть подобная утилита для генерации событий, привязанных к полю. Мы тоже начали смотреть в эту сторону, чтобы на программном уровне генерировать события, и отходить от разделения типов объекта
event, чтобы он всегда мог иметь один тип.Надеюсь, смог ответить на ваш вопрос)
В TypeScript нет общепринятой терминологии для этого, что создает путаницу в названиях. Программирование - это обширное понятие, а типизация - всего лишь небольшая его часть, собственно, и сама статья посвящана этой части. Называть это "шаблоном типизации" вполне нормально, и это не звучит слишком вычурно или сложно.
"Шаблон стратегия" или "Шаблон Команда" - это же не про Typescript, это про шаблоны программирования, и да, там официальное название - это Pattern.
Если мы говорим про Typescript - "шаблон" или "шаблон типизации" - звучит вполне логично, потому что это тоже паттерн для реализации нужного итогового поведения в результате типизации (например, компонента).
В зависимости от разных контекстов одинаковые слова имеют разный смысл, и это нормально, если, базово, они будут звучать одинаково.
Пример (очень утрированный): слово "Запрос". Если мы говорим в контексте Web - запрос (query) - это отправка "сообщения" на сервер. В контексте баз данных - это команда с нужными операциями, отправляемая к базе данных. (Запрос к серверу и запрос к базе данных - это все программирование).
Ну почему нельзя? В англоязычном коммьюнити повсеместно и, достаточно, устойчиво используется слово "Pattern". Почему бы не перевести это, как шаблон? Особо проблем, лично я, тут не вижу. "Механизм" и "возможность" - слишком абстрактные понятия, как по мне, чтобы они давали хоть какой-нибудь намек на то, что они делают. "Шаблон" же дает некий намек на то, что это какая то предзаложенная последовательность действий.
Кстати, я не против транслитерации в лексиконе) В русскоязычной документации это всегда смотрится неуместно, как по мне)
Точно так же, как и операция - это один из механизмов работы с числами.
Проводя аналогию, если простое объединение типов можно было бы назвать "оператором", так как используется один символ `|`, то в случае с распределенными условными типами, где нужно указание дженерика, условных операторов с ключевыми словом `extends` и т.д - уже сложно называть оператором. Думаю, ты меня понял.
Мой тейк, в данном случае, это предложить русскоязычную адаптацию понятия "фича", которую ты упомянул. Использование слова "фича", по сути, является транслитерацией, все равно что вместо "функции обратного вызова" писать "кАлбэк" или вместо "свойства" - "проп".
Да, я понимаю про что ты. При написании статьи я долго думал, как подходы TypeScript (условное объединение, и т.д) можно объединить в одно ёмкое название. Паттерн, подход... В итоге я решил предложить вариант "Шаблон", так как он чаще всего мне попадался на глаза во время поисков. Других альтернатив на просторе документации Typescript или русскоязычного коммьюнити я не нашел.
Лайфках, чтобы душа была чиста:
1) Пишешь рабочий, но такой себе в плане "правильности", код;
2) Подписываешь его как `TODO: исправить`;
3) git add + git commit + git push;
4) Радуешься, что хотя бы немного оправдался перед коллегами :)