Должен ли наноостровной контрол тригерить nb-* события в перемешку с нативными?

[pmyagkov]

Предыстория: Для 3 контрольных вопросов Саша попросил Вадима сделать возможным прослушивание нативного события focusin от inputa в ущерб наноостровному nb-focused. Пожелание было реализовано, и у нас благополучно отвалились саджест и поиск, которые опирались на событие nb-focused.

Вопрос 1: должны ли острова давать возможность разработчику слушать нативные события?
Вопрос 2: как сделать так, чтобы нововведения, заказанные одним человеком, не ломали код, написанный другим человеком в проде? Как на концептуальном уровне (а то получится, как в басне про лебедя, рака и щуку), так и на уровне юнит- и автотестов.

[pmyagkov]

Мое мнение: если уж библиотека берет на себя смелость кидать кастомные события, то она должна кидать только их. Кто знает, что станет с островным input'ом в будущем? Может быть в кишках у него перестанет быть нативный, и что тогда? Библиотека будет прокидывать и focusin тоже сама?

[basvasilich]

#376
И это тоже.

[basvasilich]

@yandex-ui/nanoislands

[hexode]

Мое мнение: если уж библиотека берет на себя смелость кидать кастомные события, то она должна кидать только их.

Я сторонник противоположного мнения. Есть стандартные события и надо поддерживать с ними совместимость не нарушая по максимуму. Ломать легче, чем строить.

Если строится новая абстракция, то она должна решать проблемы которые существовали в старых абстракциях. Новое имя для событий не решает каких-либо проблем.

И я до сих пор не понял концептуальной разницы нативных и и островных событий(я про те которые совпадают по назначению). Чем они различаются кроме имени, я просто не в курсе :)?

Может быть в кишках у него перестанет быть нативный, и что тогда?

А что изменится? Принципы, набор событий? А вообще думать в такую сторону противоречит YAGNI. Слишком смелое предположение:)

Библиотека будет прокидывать и focusin тоже сама?

Она в любом случае будет это делать, если элемент интерфейса имеет состояние фокуса.

Вопрос 2

Хорошое покрытие функциональными автотестами + ручное тестирование решит проблему. Юнит тесты уже есть.

Да и мой ответ на issue - наноостровной контрол не должен тригеррить вперемешку c нативными. Он должен расширять контрол новыми событиями и сохранять старые, а не переопределять старые(если конечно же функциональность одна и та же)

[pmyagkov]

@hexode

А что изменится? Принципы, набор событий?

Да, именно события и изменится. И все поломается. Абстракции возводятся для того, чтобы избавить от такой головной боли. Если Вадим инкапсулирует нативные контролы, то я не должен задумываться о том, что у них под капотом, и какие события он кидает.

Она в любом случае будет это делать, если элемент интерфейса имеет состояние фокуса.

Совсем необязательно, ведь наноострова властны над тем, что прокидывают их внутренние контролы.

[Katochimoto]

1. Если задача/назначение/смысл/... кастомного события совпадает с нативным, то он должен называться как нативный.
2. На любое пожелание - ишью. Все должны их мониторить. + подробный лог изменений в версии.
   И тот кто обновляет острова должен проверить совместимость.
   Это то, как мы сейчас обновляем jquery, например.

[hexode]

Абстракции возводятся для того, чтобы избавить от такой головной боли

Ничто не мешает изменить все кишки(хотя на канве, хоть на svg) контрола и оставить имя события 'focusin' без изменений. Не понимаю это мысль - событие предоставляет всего лишь интерфейс контрола, но не его реализацию. Меняй внутри, что хочешь, но интерфейс надо держать по максимуму совместимым с веб-стандартами.

[pmyagkov]

Мне лично все равно, как их называть, сейчас проблема в другом: на данный момент реализация такая, что если ты перешел в input мышкой, то кидается focusin, если табом — то nb-focused. Таким образом, тебе необходимо подписываться на оба события, чтобы поймать обе ситуации. Это неудобно. К тому же, коллбеки вызываются в разных контекстах.

2 события фокуса, прокидываемые контролом, вводят путаницу, мой посыл в этом.

[hexode]

Ну с этим я не могу не согласиться.

[basvasilich]

и туда же #344

[basvasilich]

Я еще хочу напомнить что завтра там может уже не быть нативного инпута в реализации.

[JhonyLe]

я за то, чтобы все элементы кидали нативные события. Во-первых, если я решил использовать библиотеку, я хочу только красивые кнопочки и уж точно не хочу заново изучать все события, которые мне нужны и держать их потом в голове. Во-вторых, все должно поддерживать стандарт, даже если кто-то что-то на него навесил сверху. Я считаю, что в не зависимости от реализации интерфейс взаимодействия с элементами не должен меняться. Взять в пример тот же MVC, разве от изменения view мы должны переписывать все остальное? Эти части не должны быть жестко зависимы друг от друга. И здесь тоже самое, мы меняем контрол в шаблоне и не должны после этого переписывать всю его обработку в js. Иначе работа с библиотекой становится слишком дорогой.

[pmyagkov]

Да, сорь, ошибся.

[arteg]

Если задача/назначение/смысл/... кастомного события совпадает с нативным, то он должен называться как нативный.

Согласен.