Я подумал над этой проблемой. Я хочу оставить её решение за рамками этой статьи.
Начальная задача была сделать из императивного компонента декларативный. И сейчас компонент работает аналогично декларативным нативным компонентам, таким как, например, <input />. У них если не контролировать onChange в родителе, то также value будет присваиваться только при ре-рендеринге родителя.
Это не совсем соответствует идеальной декларативности. Но до идеала, наверное, и не добраться, т.к., например, если пользователь нажал внутри плеера stop, а мы программно заставим его вернуться на то же место и играть дальше, то видео всё равно успеет "дёрнуться". Поэтому, я думаю, здесь уже надо отталкиваться от бизнес-задач и конкретной реализации плеера.
Если я на практике столкнусь с тем, чтобы нужно было в нашей обёртке контролировать бизнес-логику, то, может быть, напишу продолжение.
Работать будет. Но вы правы в том плане, что когда видео доиграет до конца, оно не начнёт проигрываться заново. Для этого более тонкая логика нужна в VideoPlayer.
Спасибо! Дополнил. Хотя, преимущество использовать ref для этого не совсем понятно. Разве что то, что ref-ы документация React считает "окном" в императивную работу с DOM.
А вы читали Глеба Архангельского "тайм-драйв"? У него есть понятие хроносных и кайросных задач. Хроносные привязаны ко времени, их надо размечать в календаре. Кайросные - не надо, потому что замучаешься оценивать их и переносить изо дня в день.
Непонятно, как деструктуризация относится к описываемой проблеме. Без деструктуризации, при передаче props.images ?? [] было бы то же самое. И, наоборот, с деструктуризацией, но если можно передать, например, undefined в качестве images, то проблемы нет.
Когда пользователям даешь новую фичу с богатым функционалом и простором для воображения, всегда есть период, когда фича используется как попало. По-идее, со временем народ вырабатывает какой-то свой подход ее использования.
Но! Есть опасность, что ее начнут использовать совсем уж не по назначению. Как например было с отличным проектом Google Wave — народ стал пользоваться вложенностью и возможностю сворачивания комментариев в Wave и плодить километровые волны. А разработчики все-таки рассчитывали, что волны будут примерно похожи на почтовую переписку. В итоге проект провалился, хотя ему прочили заменить все виды письменного общения (почта, чаты, вики).
Т.о. первый вывод: нужно давать пользователям понять, для каких именно случаев разработчики все-таки ввели эту фичу. Может быть не давать общие названия, типа «подзадача». А конкретные: задачи первого уровня — проекты, второго — системы, третьего — подсистемы и т.д. Например, чтобы эти названия можно было настраивать админу достаточно гибко, но система уже заставляла народ использовать заданную структуру. Кажется такое есть в TrackStudio — они очень гордятся иерархичностью своей системы.
Вторая опасность: если каждый человек/компания выработает свой подход к использованию фичи, то дальнейшие фиче-реквесты по ее доработке будут очень разнообразными — т.к. каждый человек захочет ее «допиливать» в разные стороны — под то, под что он ее пытается приспособить.
Я подумал над этой проблемой. Я хочу оставить её решение за рамками этой статьи.
Начальная задача была сделать из императивного компонента декларативный. И сейчас компонент работает аналогично декларативным нативным компонентам, таким как, например, <input />. У них если не контролировать onChange в родителе, то также value будет присваиваться только при ре-рендеринге родителя.
Это не совсем соответствует идеальной декларативности. Но до идеала, наверное, и не добраться, т.к., например, если пользователь нажал внутри плеера stop, а мы программно заставим его вернуться на то же место и играть дальше, то видео всё равно успеет "дёрнуться". Поэтому, я думаю, здесь уже надо отталкиваться от бизнес-задач и конкретной реализации плеера.
Если я на практике столкнусь с тем, чтобы нужно было в нашей обёртке контролировать бизнес-логику, то, может быть, напишу продолжение.
Теперь понятно, какой кейс вы имеете ввиду. Да, в статье не обрабатывается такой случай. Доработаю, спасибо.
Работать будет. Но вы правы в том плане, что когда видео доиграет до конца, оно не начнёт проигрываться заново. Для этого более тонкая логика нужна в VideoPlayer.
Спасибо! Дополнил. Хотя, преимущество использовать ref для этого не совсем понятно. Разве что то, что ref-ы документация React считает "окном" в императивную работу с DOM.
А вы читали Глеба Архангельского "тайм-драйв"? У него есть понятие хроносных и кайросных задач. Хроносные привязаны ко времени, их надо размечать в календаре. Кайросные - не надо, потому что замучаешься оценивать их и переносить изо дня в день.
Непонятно, как деструктуризация относится к описываемой проблеме. Без деструктуризации, при передаче props.images ?? [] было бы то же самое. И, наоборот, с деструктуризацией, но если можно передать, например, undefined в качестве images, то проблемы нет.
Спасибо за примеры. Кажется, CT работает аналогично CET. В CET аналогично, осенью час повторяется, а весной пропадает.
Это тоже отличный комментарий, и кому-то это может пригодится.
Но да, я при написании статьи решил это не указывать, т.к. мы, таким образом, запрещаем опциональные аргументы. Что, может быть, не так уж и критично.
Спасибо за ценное замечание, дополнил статью!
Но! Есть опасность, что ее начнут использовать совсем уж не по назначению. Как например было с отличным проектом Google Wave — народ стал пользоваться вложенностью и возможностю сворачивания комментариев в Wave и плодить километровые волны. А разработчики все-таки рассчитывали, что волны будут примерно похожи на почтовую переписку. В итоге проект провалился, хотя ему прочили заменить все виды письменного общения (почта, чаты, вики).
Т.о. первый вывод: нужно давать пользователям понять, для каких именно случаев разработчики все-таки ввели эту фичу. Может быть не давать общие названия, типа «подзадача». А конкретные: задачи первого уровня — проекты, второго — системы, третьего — подсистемы и т.д. Например, чтобы эти названия можно было настраивать админу достаточно гибко, но система уже заставляла народ использовать заданную структуру. Кажется такое есть в TrackStudio — они очень гордятся иерархичностью своей системы.
Вторая опасность: если каждый человек/компания выработает свой подход к использованию фичи, то дальнейшие фиче-реквесты по ее доработке будут очень разнообразными — т.к. каждый человек захочет ее «допиливать» в разные стороны — под то, под что он ее пытается приспособить.