[Feature] Скролл в Panel

[eolme]

Сейчас скролл распространяется на всю страницу, связи с чем библиотека обросла костылями для анимаций и восстановления позиции прокуртки. К тому же, сам скроллбар наезжает на PanelHeader, что выглядит не нативно.

Предлагаю сам скролл сделать внутри Panel, для него же сделать условно 2 слота (пропа) - before/after - в который будет помещаться, например, PanelHeader.

FixedLayout в данном случае уйдет за ненадобностью, проблемы со скачущими элементами уйдут, сохранение позиции скролла упростится, и скроллбар будет а-ля нативный.

Единственная, пожалуй, проблема останется с оверскроллом на Safari, но она довольно просто решается - у body position: fixed. Возможно затронет insets, но там уже по реализации смотреть надо.

[stels-cs]

Если у body будет position: fixed, вангую что будет куча проблем в iOS, пруфов у меня нет, но в модалках (которые тоже fixed) были проблемы с инпутами причем в разных версиях iOS работало по разному.

[eolme]

@stels-cs, тестил на бете старой v4, все ок

[eolme]

Есть в планах подобная реализация? Или так и будем страдать с fixedlayout и его костылями?

[eugpoloz]

@eolme мы собираемся разобраться с FixedLayout, чтобы преуменьшить страдания, так что все будет. Точный срок пока не могу назвать, но планируем это сделать до конца этого года.

[eolme]

@eugpoloz зачем уменьшить, если можно вообще избавится? Звучит как-то плохо. Серьезно, нет ни одной причины почему и зачем нужен fixedlayout.

[eugpoloz]

@eolme подожди, я нигде не сказала, что мы его оставим. В планах — «разобраться», пока предварительно обсуждали, что его выпилим как раз, потому что причин его оставлять действительно нет.

[eolme]

@eugpoloz а что скажешь про скролл внутри панели? У нас вроде есть уже логика обработки, нужно только в самой панели реализовать

[ArthurStam]

@eolme скролл не на документе — путь к пачке проблем, по ходу решения которых мы обрастём большим количеством костылей (и даже они вряд ли помогут). Пример таких проблем:

1. Упомянутый тобой оверскролл на iOS. Исправить его с помощью предложенного position: fixed у меня не получилось. Возможно не так тебя понял. Буду рад посмотреть на живой пример с решением этой проблемы.
2. Залипающий скролл. Это уже более серьезная проблема. Тоже пока не видел удачного решения. Браузер всё время норовит проскроллить документ, а не внутренний элемент.
3. Scroll restoration. При переходе на другой документ и возврате с него скролл не восстановится автоматически, если он будет не на document.
4. Усложнение API. Теперь людям для скролла к элементу нужно будет обращаться не к document (интуитивно), а ко вложенной dom-ноде (без доки не догадаются)

[ArthurStam]

Мы постараемся решить все основные проблемы, связанные с навигацией в следующем квартале (до нг)

[eolme]

@ArthurStam по 3 и 4 пункту, у нас контекст для этого есть, это наоборот унификация API. Восстановление у нас все равно кастомное.

[eolme]

По поводу сколла у меня есть пример с реализацией, но там не совсем то, сделано костыльно достаточно https://vk.com/masks

[ArthurStam]

Мне бы реализацию посмотреть, а не её результат. Про этот контекст знают полтора человека. Восстановление у нас кастомное, а при возвращении с левого сайта на vkui — нативное. И его оторвет.

[eolme]

Мне бы реализацию посмотреть

mvk + devtools вроде никто не запрещал

[ArthurStam]

Как-то сложно диалог строится. Мне предложение скролла в панели не нравится, причины я описал. Если есть решение, то пришли либо PR, либо ссылку на код. Заниматься дебагом и реверс инжинирингом подхода, который на этапе рассуждений вызывает сомнения, у меня времени нет.

[thoughtspile]

Такс, мой выход. Если изначальная проблема в костыльности FixedLayout, то в #1949 + #1958 я выкинул всё костыляние для переходов и вроде бы ничего не произошло.

У скролла внутри Panel, кроме упомянутых @ArthurStam проблем, есть фатальный недостаток — в многоколоночном интерфейсе придется целенаправленно скроллить внутри колонки (бонусом — страшный внутренний скроллбар на винде). Еще хуже будет, когда мы начнем делать на вкюи разделы большого вк, где все завязано на глобальный скролл.

FixedLayout, кроме хака с переходом, нужен потому и затем, что:

1. Цепляется к колонке в многоколоночном интерфейсе
2. Проставляет инсеты
3. Проставляет з-индексы

Возможно, сейчас он делает это не очень хорошо, но это отдельные баги, велкам заносить — я начал #1970. Даже если заведешь [Feature] FixedLayout в портале я буду только рад.

Комбинировать восстановление скролла и анимации довольно сложно в любом случае (вот правда, не нашел ни одного удачного примера, дайте знать если видели). Контекст: сейчас мы на время анимации обрезаем панели по размеру экрана и скролл на документе исчезает. Я делал пару концептов, где глобальный скролл сохраняется на время перехода, и мне не нравится, что так во время перехода можно скроллить — думаю, на убивание этого поведения уйдет много костылей. Пришел к выводу, что сильно лучше, чем сейчас, не выйдет.

Каждый, кто хочет скролл внутри панели, может легко сделать это в 1 строку: <Panel style={{ overflow: 'auto' }}>

Поэтому @eolme предлагаю этот ишью закрыть — спасибо за предложение, правда, я очень ценю твое участие.

[eolme]

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

У дизайнеров сразу срабатывает триггер и просят вообще его скрывать. Со стороны пользователя любой из вариантов выглядит не нативно и не интуитивно.