VKCOM
[Feature]: Скролл в Panel
Сейчас скролл распространяется на всю страницу, связи с чем библиотека обросла костылями для анимаций и восстановления позиции прокуртки. К тому же, сам скроллбар наезжает на PanelHeader, что выглядит не нативно.
Предлагаю сам скролл сделать внутри Panel, для него же сделать условно 2 слота (пропа) - before/after - в который будет помещаться, например, PanelHeader.
FixedLayout в данном случае уйдет за ненадобностью, проблемы со скачущими элементами уйдут, сохранение позиции скролла упростится, и скроллбар будет а-ля нативный.
Единственная, пожалуй, проблема останется с оверскроллом на Safari, но она довольно просто решается - у body position: fixed. Возможно затронет insets, но там уже по реализации смотреть надо.
Если у body будет position: fixed, вангую что будет куча проблем в iOS, пруфов у меня нет, но в модалках (которые тоже fixed) были проблемы с инпутами причем в разных версиях iOS работало по разному.
Есть в планах подобная реализация? Или так и будем страдать с fixedlayout и его костылями?
@eolme мы собираемся разобраться с FixedLayout, чтобы преуменьшить страдания, так что все будет. Точный срок пока не могу назвать, но планируем это сделать до конца этого года.
@eugpoloz зачем уменьшить, если можно вообще избавится? Звучит как-то плохо. Серьезно, нет ни одной причины почему и зачем нужен fixedlayout.
@eolme подожди, я нигде не сказала, что мы его оставим. В планах — «разобраться», пока предварительно обсуждали, что его выпилим как раз, потому что причин его оставлять действительно нет.
@eugpoloz а что скажешь про скролл внутри панели? У нас вроде есть уже логика обработки, нужно только в самой панели реализовать
@eolme скролл не на документе — путь к пачке проблем, по ходу решения которых мы обрастём большим количеством костылей (и даже они вряд ли помогут). Пример таких проблем:
- Упомянутый тобой оверскролл на iOS. Исправить его с помощью предложенного
position: fixedу меня не получилось. Возможно не так тебя понял. Буду рад посмотреть на живой пример с решением этой проблемы. - Залипающий скролл. Это уже более серьезная проблема. Тоже пока не видел удачного решения. Браузер всё время норовит проскроллить документ, а не внутренний элемент.
- Scroll restoration. При переходе на другой документ и возврате с него скролл не восстановится автоматически, если он будет не на document.
- Усложнение API. Теперь людям для скролла к элементу нужно будет обращаться не к document (интуитивно), а ко вложенной dom-ноде (без доки не догадаются)
Мы постараемся решить все основные проблемы, связанные с навигацией в следующем квартале (до нг)
@ArthurStam по 3 и 4 пункту, у нас контекст для этого есть, это наоборот унификация API. Восстановление у нас все равно кастомное.
По поводу сколла у меня есть пример с реализацией, но там не совсем то, сделано костыльно достаточно https://vk.com/masks
Мне бы реализацию посмотреть, а не её результат. Про этот контекст знают полтора человека. Восстановление у нас кастомное, а при возвращении с левого сайта на vkui — нативное. И его оторвет.
Как-то сложно диалог строится. Мне предложение скролла в панели не нравится, причины я описал. Если есть решение, то пришли либо PR, либо ссылку на код. Заниматься дебагом и реверс инжинирингом подхода, который на этапе рассуждений вызывает сомнения, у меня времени нет.
Такс, мой выход. Если изначальная проблема в костыльности FixedLayout, то в #1949 + #1958 я выкинул всё костыляние для переходов и вроде бы ничего не произошло.
У скролла внутри Panel, кроме упомянутых @ArthurStam проблем, есть фатальный недостаток — в многоколоночном интерфейсе придется целенаправленно скроллить внутри колонки (бонусом — страшный внутренний скроллбар на винде). Еще хуже будет, когда мы начнем делать на вкюи разделы большого вк, где все завязано на глобальный скролл.
FixedLayout, кроме хака с переходом, нужен потому и затем, что:
- Цепляется к колонке в многоколоночном интерфейсе
- Проставляет инсеты
- Проставляет з-индексы
Возможно, сейчас он делает это не очень хорошо, но это отдельные баги, велкам заносить — я начал #1970. Даже если заведешь [Feature] FixedLayout в портале я буду только рад.
Комбинировать восстановление скролла и анимации довольно сложно в любом случае (вот правда, не нашел ни одного удачного примера, дайте знать если видели). Контекст: сейчас мы на время анимации обрезаем панели по размеру экрана и скролл на документе исчезает. Я делал пару концептов, где глобальный скролл сохраняется на время перехода, и мне не нравится, что так во время перехода можно скроллить — думаю, на убивание этого поведения уйдет много костылей. Пришел к выводу, что сильно лучше, чем сейчас, не выйдет.
Каждый, кто хочет скролл внутри панели, может легко сделать это в 1 строку: <Panel style={{ overflow: 'auto' }}>
Поэтому @eolme предлагаю этот ишью закрыть — спасибо за предложение, правда, я очень ценю твое участие.
@thoughtspile, у меня изначально претензия к скроллбару, который уходит под любой FixedLayout.
У дизайнеров сразу срабатывает триггер и просят вообще его скрывать. Со стороны пользователя любой из вариантов выглядит не нативно и не интуитивно.