Короче, кажется, у меня складывается целостная картина в голове. #mokum-dev 1) можно считать, что любую загруженную картинку можно вернуть в любом заказанном bounding box (по ширине), а также в любом формате в амортизированном рилтайме. есть три способа: а) client-side resize средствами браузера — это можно использовать как быстрый и грубый способ протестировать прототип; б) imgix.com — минимальный прайс 10 долларов в месяц за 3300 запрошенных мастеров; если кол-во пользователей/картинок будет расти, то я думаю, что мы найдем пропорциональное количество единиц долларов в месяц; если у Мокума не будет денег на десятку в месяц — то наверное, это будет не единственная его проблема; в) есть фоллбэк на случай экстремальной прижимистости: в принципе кажется простую наколенную ресайзилку можно написать за несколько дней (чтобы обеспечить амортизированный рилтайм, можно отдавать при первом запросе _оригинал_, чтобы самый первый клиент заплатил случайную цену, скачав исходник и отресайзив его в браузере. Остальные клиенты получат уже сгенерированное оптимальное представление).
2) различных средств обеспечения responsiveness довольно много, и они решают разные подзадачи. Однако, у Мокума есть некий уникальный набор требований, который облегчает принятие некоторых решений. в частности, на самом деле нам надо поддерживать а) тупых клиентов на чистом HTML и б) нормальных клиентов на React. Для первых можно всегда генерировать превьюшку, которая работает как сейчас (укладываться в ширину 200/300/600 для портрета/ландшафта/панорамы, плюс спец-тамбнейл для длиннокотов). Ссылку на эту дефолтную превьюшку надо запихать внутрь <picture> так, чтобы его еще и современные браузеры игнорировали. Соответственно, говноклиенты по крайней мере не попадут на выкачивание здоровенного исходника, что соответствует их предназначению. ‎- псы в рапиде
3) для нормальных клиентов на React мы полностью контролируем структуру страницы, в частности, мы точно знаем ширину основной колонки в пикселях. Мы можем воспользоваться стандартным умещением фоток в горизонтальные полосы с минимальной/максимальной высотой этой полосы. При react-рендеринге мы тупо считаем эту правильную структуру картинок, и генерируем <img src="">, который указывает на ресайзилку (imgix или собственную, или вообще в прототипе тупо юзает оригинал). В этом месте нам не надо никаких <picture> уже и прочих средств responsiveness, потому что мы уже все знаем про браузер — какие форматы он поддерживает и какая ширина viewport. Более того, нам не надо париться с responsiveness на уровне Bootstrap, потому что мы сразу конструируем фактически HTML фиксированного размера, как в девяностые. ‎- псы в рапиде
4) так как есть некий UX-ад, описанный в https://mokum.place/mokum-support/49784, то необходимо иметь явную ссылку на "Скачать исходную картинку" (видимо, это пойдет в грядующую ссылку "Share") чтобы люди могли сохранить ее себе в нормальном, не-адском формате. Кроме того, можно еще даже если кто-то зальет webp, сконвертировать его один-в-один обратно в стандартный формат типа PNG. ‎- псы в рапиде
5) кажется, надо признать неизбежное и конвертировать анимированные гифы в .gifv (и сделать нормальный эмбед gfycat). Для дебильных браузеров можно отдавать оригинал, и пусть они ебутся с ним как хотят. ‎- псы в рапиде
6) абсолютно тот же самый алгоритм выстраивания по лентам необходимо расширить также на прочие эмбеды, в первую очередь на youtube. При этом можно будет например дать ссылку на ютьюб и залить например постер фильма, или кавер альбома, и все эти объекты будут аккуратно стоять друг рядом с другом. См. http://embedresponsively.com/ за эмбедами всего актуального. ‎- псы в рапиде
7) отдельно нужно не забыть про то, что большое количество картинок, типично заливающихся на системы типа мокума, исходно являются небольшими (плюс это будет актуально при импорте внешних источников, где традиционно отдаются уже тамбнейлы от контента). То есть некоторые картинки вообще даже не надо ресайзить, потому что они и так — ... Update: case in point: https://mokum.place/szypulka/113721 ‎- псы в рапиде
Вариант с реактом не учитывает поворот мобильного насколько я понял. Плюс есть два вида пикселей: Физические (ритина в разных разновидностях) и логические (то что на ретине отдается всякому css и js при измерении кеглей, разрешения и прочего). Для разных сочетаний в идеале надо отдавать разное. Кажется проще сделать один раз picture + picturefil с несколькими основными значениями телефонных экранов, а промежуточные просто ресайзить силами браузера до ближайшего. ‎- Alexey Ivanov
@iadramelk: а) вроде ведь есть window.DeviceOrientationEvent, кроме того, этим кейсом можно пренебречь — повернул и и нажал рефреш; б) да, про ретину и ее обобщения я почитал, и это грустно, грустно ("но косить надо", как гласит анекдот). Спасибо! ‎- псы в рапиде
@squadette: Тут немного в другом проблема. Поймать поворот экрана легко – тот же onresize это сделает. Вопрос что делать дальше: Можно обновить props или сторы, чтобы пошел новый render, но тогда старая картинка исчезнет, а новая будет грузиться и на какое-то время интерфейс будет мигать. А если вернуть телефон в изначальное положение опять все повторится. Можно попытаться не удалять старую картинку пока новая не загрузится и менять потом. Но это уже не стандартные средства Реакта и надо будет много своей логики писать. Причем если сначала подгружена большая картинка, грузить маленькую уже не надо – надо браузером её ресайзить к меньшему размеру, иначе просто трафик лишний потратится. ‎- Alexey Ivanov
<picture> с правильными параметрами и картинками как раз все эти проблемы решает более-менее автоматически. ‎- Alexey Ivanov
@iadramelk: поворот экрана слишком редкая вещь, чтобы всерьез на нее так париться, у меня никаких ресурсов на это не будет никогда. ну мигнет она во время физического движения экрана, и чо? это какой-то непонятный мне перфекционизм... ‎- псы в рапиде
@squadete Ннну вот ту не соглашушь. Поворот телефона в ландшафтный режим, чтобы посмотреть большую версию мелкой картинки – у меня очень частый кейс. А как раз картинка которую я хочу посмотреть будет в этот момент будет пропадать и грузиться по новой. Возможно это я такой мутант один, но что-то мне подсказывает что нет. Прелесть picture как раз в том, что с ним все работает из коробки как ожидается и для этого почти ничего не надо. ‎- Alexey Ivanov
Пример когда надо повернуть телефон для большой картинки – демотиватор с мелкими буквами например. ‎- Alexey Ivanov
@iadramelk: ну да, да, ок. ладно, посмотрим. можно и правда сделать некий механизм миграции между размерами картинки, в принципе это решаем на существующей схеме. Скажем так, по сравнению с текущей реализацией картинок в Мокуме даже без поворота это будет такой прорыв, что — ... ‎- псы в рапиде
Понял еще одну проблему с перезагрузкой – интернет на телефоне не всегда стабилен. Если ты перед входом в поезд метро загрузил страницу, а в поезде решил повернуть телефон на бок, то внезапно может оказаться, что картинок на странице у тебя больше нет. ‎- Alexey Ivanov
@iadramelk: да-да, я тоже осознал, что у этой проблемы большой мультипликатор потому, что она как раз актуальна на мобиле. И я кстати понял про picture, спасибо. Есть идеи. ‎- псы в рапиде