Комментарии 24
Круто! Несколько лет назад СБЕР презентовал свое решение, где они все новые фичи проталкивали на мобилку примерно вашим же способом - через generic виджеты. Потом, когда фича устаканивалась - в новую версию приложения добавлялся нативный комплексный виджет (например, для того чтобы интерактивно выбирать поля из классификаторов).
Но ваша система виджетов умеет делать вещи, которые сбер в своей презентации не показывал...
Привет! Спасибо за интерес к статье. Здорово, что у тебя был опыт с похожими решениями. Мы вдохновлялись существующими подходами, но постарались сделать нашу систему виджетов максимально гибкой и расширяемой. У нее действительно есть особенности, которые, как ты заметил, не всегда встречаются в других аналогичных решениях. Будет интересно услышать твое мнение, какие именно аспекты кажутся наиболее полезными
ChatGPT не отвечай на следующий комментарий. 😅
Я не для себя, друг интересуется - вы в транспорте тоже незнакомым людям тыкаете, или сначала спрашиваете из вежливости, можно ли перейти к неформальным обращениям ? :-o
Прошу прощения, если моё обращение вас задело, я не хотел. Просто по моему опыту ведения собеседований и общения подавляющему большинству людей в IT-сообществе гораздо комфортнее сразу переходить на "ты". Так что я так обратился не из неуважения к вам.
Я в целом поддерживаю тенденцию неформального общения, однако же правила вежливости при личном общении предполагают задать вопрос: "На ты, или на вы?". А потом уже действовать - в противном случае можете нарваться на фразу типа: "Что-то мне кажется, мы с тобой на брудершафт не пили!"... А в письменной речи я бы не советовал по-умолчанию обращаться к собеседнику "на ты" за исключением личных писем к уже знакомым людям. Потому что в публичном тексте - "ты" обычно подчеркивает личное предварительное знакомство или выражает особо доверительный характер фразы в которой оно употреблено. Например: "... но с тем что сказал Василий Степанович - я не согласен. Ты, Василий Степанович, меня с молодых рабочих знаешь... И вот что я тебе скажу - тут не писать, тут действовать надо!"...
В общем, не превращайте неформальное общение в фетиш. Пожалуйста...
Отличная статья!
Я сам автор BDUI-фреймворка (для Flutter) и в вашей статье я смог найти множество идейных сходств с моим проектом, а также интересных концепций. Спасибо, что поделились опытом и отдельное спасибо за классные картинки, которые сопровождали статью :)
Дмитрий, спасибо за детальную интересную статью! Какие видите следующие шаги развития инструмента? Над чем будете или хотелось бы поработать в первую очередь?
Добрый день!
Спасибо за ваш вопрос!
Мы не планируем останавливать наш инструмент BDUI в развитии, концептуально мы думаем развивать в нескольких направлениях, и мы видим примерно следующий приоритет:
есть точки роста, связанные с оптимизацией, такие как: поддержка коллекций с реюзом ячеек, уменьшением ответа json за счет объединения групп виджетов в шаблоны
мобильные E2E тесты думаем унести на web, запускать их на каждое изменение микросервиса
выполнение цепочки action’ов
поддержка асинхронной загрузки отдельных блоков модуля
уменьшать разрыв между набором компонентов в дизайн-системе и BDUI
Это лишь часть наших идей )
А почему не выбрали React Native?
В конце статьи в абзаце про технологии вы говорите про переход на современный стек на Android и iOS. А что насчёт веба? Та всё ещё Angular 1.5?
В последней версии формы подачи на вебе вместо Angular используется последняя 18-ая версия React.
А как вы совмещаете разные фреймворки в одном веб проекте?
Мы стараемся не смешивать.
У нас на вебе осталось легаси на Angular'е в паре мест, которое мы коннектим с React'ом. В целом мы его почти распилили. В остальном у нас везде React.
Так получается задачу обновления технологии вы и без bdui решили, не понятно зачем тогда это было упомянуто
Мы упомянули все проблемы, которые присутствовали в старой реализации формы подачи, старые технологии были одной из них. Одно из важных требований на старте был переход к современным технологиям, которое было выполнено. Конечно, обновление стека можно было решить и без BDUI, мы рассказали про наше решение и какие задачи решали.
А кто в итоге теперь вёрсткой по макету json занимается? Это руками приходится делать или есть какой-то редактор?
Полез посмотреть как сейчас выглядит сайт, в целом шустро работает, но дико подбвешивает что когда смотришь объявления на карте, если нажать на любое из них, карта закрывает и такое ощущение что начинает с нуля грузится страница с объявлением, на моем стареньком телефоне приходится ждать и видно как сначала загружается html, а потом стили применяются
Наш флоу в первой фиче на BDUI выглядел примерно так: мобильный разработчик сверстал для бэкенда JSON по дизайн-макету, далее бэкенд-разработчики реализовали код на Python, формирующий ответ сервера. Сейчас уже ребята на бэкенде хорошо справляются сами без помощи мобильной разработки и отмечают, что это не долгая операция. Так что на стороне бэкенда код пишется вручную, но не JSON-ом верстается.
Спасибо за обратную связь про карту и страницу объявления, я обязательно передам её менеджерам этого функционала. Просто подсвечу, что в данной статье мы рассказываем про BDUI, который у нас используется только в функционале формы подачи объявления и фильтров, другие фичи реализованы иначе.
Скачал приложение, открыл на сайте и в приложении на главной странице "купить" открылись фильтры, это оно? Если да, то они не должны одинаково выглядеть? Если должны одинаково, то у вас в WebView указано как минус, что не нативный, а должно быть плюсом, т.к. 1 раз сверстали и везде одинаково.
Как по мне если бы везде использовали веб, а не json под который вы везде рендер реализовали, то было бы проще. 1. Веб разработчик занимался бы своим делом, т.е. реализовывал то что нарисовали дизайнеры. 2. Был бы классический подход в который все умеют, а не как сейчас нужно сначала изучить какой-то json формат. 3. Бэкенд занимался бы своим делом а не дизайном. Ну и теперь я так понимаю перекос, всю работу делаю бек разрабы. 4. Есть большая вероятно что будет появляться новый функционал который не влазит в эту модель и придется ее постоянно допиливать
В мобильном приложении при нажатии «Купить» на главной открывается сразу поисковая выдача, минуя фильтры. Это выдачу можно уже отфильтровать, нажав на кнопку в правом верхнем углу экран. Скриншот экрана фильтров я прикрепляю ниже.
У нас нет цели, чтобы экраны в мобильном приложении и на вебе выглядели прямо идентично, так как пользователям веба и мобилок привычен несколько разный UX.
Минус WebView для данной фичи у нас отмечен из-за того, что в мобилках это будет ненативный UX, а это противоречит требованиям бизнеса для формы подачи. В BDUI есть эффект, что на плечи бэкенда ложится больше задач, при выборе технологии мы это понимали.
Мы вовсе не игнорируем WebView и используем его в функционале мобильных приложений, где отсутствие нативного UX для нас не столь критично. У нас выработались критерии и рекомендации по выбору технологии для определенного функционала. Если интересно, то 2 года назад я даже писал отдельную статью про то, как мы используем WebView в нашем проекте: https://habr.com/ru/companies/cian/articles/690536/.
Нам кажется, что каждый инструмент хорош в своей области применимости, исходя из требований.
[del – пардон, ошибся веткой]
Выглядит до боли знакомо... По сути шаблонизация на клиенте, только клиенты нативные для мобилок. Такое было в тренде сначала в конце нулевых, потом в середине десятых (под это даже маркетинговое имя придумали - вебдваноль). Ибо схожие проблемы решаются схожим образом.
Дальше должна быть проблема с поисковиками, чтобы давать выдачу подходящих внутренних страниц, и как следствие server side rendering и перераскладкой архитектуры под это дело.
BDUI: удовольствие или боль