1) Тут три причины. Первая смешная, хотят модно-молодежно. Вторая более реальная - уйти от самописного решения к общепринятому стандарту, чтобы проще было погружать новых разработчиков в кодовую базу. Третья - хочется независимых релизов, чтобы не пересобирать каждый раз корневое приложение (всю боль с консистентностью версий осознаем)
2) Про режим хоста у микрофронта я как-то не подумал (видимо плохо гуглил). Выглядит как то, что мне надо Спасибо за ответы.
Спасибо за статью! Если вам не сложно, нужен совет по техническому вопросу от боевого микрофронтендера. Есть долгоиграющий фронтенд на реакте, поделенный на самописные модули
китовые компоненты на основе ant design
авторизация (страницы авторизации/регистрации, интерсепторы для приватных запросов, хуки для работы с данными юзера, роутер гарды и подобное). Зависит от кита
биллинг (страница оплаты, хуки для работы с балансом пользователя). Зависит от кита и авторизации
пермишны (HOC обертки над кнопками, роутер гарды, хуки проверки и обновления доступов). Зависит от авторизации и биллинга
еще 5 модулей, которые представляют из себя отдельные страницы с логикой. Зависят от кита, авторизации, пермишнов и биллинга
Интеграция в buildtime. Стейт менеджер - реактовский контекст. Модули общаются между собой только через фронт (так сложилось исторически). Есть rxjs синглтоны с подпиской и емитом евентов. Каждый модуль подписывается на нужное событие и самостоятельно обновляет данные с бекенда
Вопрос 1: руководство очень хочет module federation. Насколько это реализуемо, если не менять архитектуру? Я пока не могу понять, будут ли работать евенты и хуки в федерации. И будет ли общий кит на все модули или каждый модуль будет ставить себе ant design и раздувать чанки
Вопрос 2: в моей схеме не решен вопрос независимой разработки, чтобы, например, у разработчика был доступ только к биллингу и он мог запустить дев сервер только с ним и вести разработку. Разработчику выданы все доступы, он просто корневое приложение запускает и ведет разработку только в своем модуле. Из вариантов, которые я придумал - это создавать мини-корневое приложение, в которое будет подключен кит+авторизация и биллинг, но это тоже не полная изоляция и неудобно. Может подскажите, какие есть еще варианты?
У меня такой же случай был. Дал девочке примитивную, неалгоритмическую задачу пробежаться по массиву и достать данные. Она начала получать данные из массива, не в цикле, хардкодом arr[0], arr[1], arr[2]... А потом возмутилась, что не знала, что на джуниора нужно решать олимпиадные задачи. При этом это уже был кандидат, который закончил Яндекс практикум настолько хорошо, что его даже взяли на двухнедельную стажировку в том же ЯП
Пусть меня заминусят. Но накрутка опыта - очередной костыль, чтобы решить глобальную проблему. И, как и у всех костылей, у этого свои сайд эффекты. Если посмотреть на ситуацию с обратной стороны, то получится так, что фильтр обошли, а техническое интервью расставило все на свои места и все-равно отказ, только потратили время HR и разработчика на собес. И бизнес за это время заплатил. В результате критерии первичного отбора ужесточатся еще сильнее и всем станет еще хуже. Например, уже сейчас, наш HR на вакансию мидла игнорит все резюме, в которых указаны курсы и 1-5 лет опыта фриланса.
Решение проблемы простое, но на него никто не согласится. Запретить курсовикам в продажных лендингах и рекламах говорить, что через 6 месяцев вы будете зарабатывать 80к, честно говорить, что после курсов вы будете стажерами с ЗП 20-40к, но, если хорошо себя проявите, то рост ЗП не заставит себя ждать.
Я не гений, знания у меня, изначально, усваивались методом упорства, а не чтения доки по диагонали. Мне, чтобы в 2015 войти в IT, понадобился всего-лишь год обучения. Но до этого я потратил 5.5 лет на классическое техническое образование в ВУЗе (не по IT профилю), где меня хорошо научили учиться самостоятельно.
У вас хорошие мысли. Только по 4 пункту я вижу такой контраргумент. Чем библиотека "базовее" и распространеннее, тем выше цена ошибки. Соответственно есть шанс, что затраты на исследование и тестирование новых изменений могут перекрыть затраты по написанию самих правок
Я понимаю Вашу боль. Сам переходил с 4.7 на 6.2. Как ни странно, довольно быстро привык и возвращаться на меньшую диагональ не хочется. Но я не про это. Если Вам нужен компактный флагман - посмотрите на Asus zenfone 8 или 9. Там хоть и диагональ 5.9", но он вытянут и рамки небольшие. Скорее всего будет примерно габаритов вашего 5.5" смартфона
В 2005 я поступил в ХАИ и на протяжении первого семестра многие преподаватели вполне серьезно говорили нам, что мы еще не студенты, и называли нас абитуриентами. Говорили, что студентами мы станем, когда сдадим первую сессию.
Я не особо заморачивался с CSS моделью. Просто вручную высчитал координаты и размер карточек в процентах для трех типов отображения (3, 5 и 7 карточек).
По сути я брал первую карту, подбирал ей подходящий размер визуально, затем центрировал (допустим, получилась карта шириной 20% и высотой 80%, значит горизонтальное положение будет 50 — 20/10 = 40%, вертикальное подбирал визуально).
Затем создавал две одинаковые карты чуть меньшего размера, чем центральная и зеркально смещал их относительно центра влево/вправо, и так до полного заполнения. Карты заднего фона просто пропроционально уменьшил и сместил немного влево, относительно первого ряда.
Абсолютно с Вами согласен. Но мои познания во втором ангуляре еще слишком малы, чтобы делиться ими с общественностью. Плюс рускоязычных мануалов по первому ангуляру относительно мало.
1) Тут три причины. Первая смешная, хотят модно-молодежно. Вторая более реальная - уйти от самописного решения к общепринятому стандарту, чтобы проще было погружать новых разработчиков в кодовую базу. Третья - хочется независимых релизов, чтобы не пересобирать каждый раз корневое приложение (всю боль с консистентностью версий осознаем)
2) Про режим хоста у микрофронта я как-то не подумал (видимо плохо гуглил). Выглядит как то, что мне надо
Спасибо за ответы.
Спасибо за статью!
Если вам не сложно, нужен совет по техническому вопросу от боевого микрофронтендера.
Есть долгоиграющий фронтенд на реакте, поделенный на самописные модули
китовые компоненты на основе ant design
авторизация (страницы авторизации/регистрации, интерсепторы для приватных запросов, хуки для работы с данными юзера, роутер гарды и подобное). Зависит от кита
биллинг (страница оплаты, хуки для работы с балансом пользователя). Зависит от кита и авторизации
пермишны (HOC обертки над кнопками, роутер гарды, хуки проверки и обновления доступов). Зависит от авторизации и биллинга
еще 5 модулей, которые представляют из себя отдельные страницы с логикой. Зависят от кита, авторизации, пермишнов и биллинга
Интеграция в buildtime. Стейт менеджер - реактовский контекст. Модули общаются между собой только через фронт (так сложилось исторически). Есть rxjs синглтоны с подпиской и емитом евентов. Каждый модуль подписывается на нужное событие и самостоятельно обновляет данные с бекенда
Вопрос 1: руководство очень хочет module federation. Насколько это реализуемо, если не менять архитектуру? Я пока не могу понять, будут ли работать евенты и хуки в федерации. И будет ли общий кит на все модули или каждый модуль будет ставить себе ant design и раздувать чанки
Вопрос 2: в моей схеме не решен вопрос независимой разработки, чтобы, например, у разработчика был доступ только к биллингу и он мог запустить дев сервер только с ним и вести разработку. Разработчику выданы все доступы, он просто корневое приложение запускает и ведет разработку только в своем модуле. Из вариантов, которые я придумал - это создавать мини-корневое приложение, в которое будет подключен кит+авторизация и биллинг, но это тоже не полная изоляция и неудобно. Может подскажите, какие есть еще варианты?
У меня такой же случай был. Дал девочке примитивную, неалгоритмическую задачу пробежаться по массиву и достать данные. Она начала получать данные из массива, не в цикле, хардкодом arr[0], arr[1], arr[2]... А потом возмутилась, что не знала, что на джуниора нужно решать олимпиадные задачи. При этом это уже был кандидат, который закончил Яндекс практикум настолько хорошо, что его даже взяли на двухнедельную стажировку в том же ЯП
Почему Краснодара нет в статистике? Вопрос без хейта, просто интересно, по нам нет статистики или IT-сектор слишком маленький?
Пусть меня заминусят. Но накрутка опыта - очередной костыль, чтобы решить глобальную проблему. И, как и у всех костылей, у этого свои сайд эффекты. Если посмотреть на ситуацию с обратной стороны, то получится так, что фильтр обошли, а техническое интервью расставило все на свои места и все-равно отказ, только потратили время HR и разработчика на собес. И бизнес за это время заплатил. В результате критерии первичного отбора ужесточатся еще сильнее и всем станет еще хуже. Например, уже сейчас, наш HR на вакансию мидла игнорит все резюме, в которых указаны курсы и 1-5 лет опыта фриланса.
Решение проблемы простое, но на него никто не согласится. Запретить курсовикам в продажных лендингах и рекламах говорить, что через 6 месяцев вы будете зарабатывать 80к, честно говорить, что после курсов вы будете стажерами с ЗП 20-40к, но, если хорошо себя проявите, то рост ЗП не заставит себя ждать.
Я не гений, знания у меня, изначально, усваивались методом упорства, а не чтения доки по диагонали.
Мне, чтобы в 2015 войти в IT, понадобился всего-лишь год обучения. Но до этого я потратил 5.5 лет на классическое техническое образование в ВУЗе (не по IT профилю), где меня хорошо научили учиться самостоятельно.
У вас хорошие мысли. Только по 4 пункту я вижу такой контраргумент. Чем библиотека "базовее" и распространеннее, тем выше цена ошибки. Соответственно есть шанс, что затраты на исследование и тестирование новых изменений могут перекрыть затраты по написанию самих правок
Я понимаю Вашу боль. Сам переходил с 4.7 на 6.2. Как ни странно, довольно быстро привык и возвращаться на меньшую диагональ не хочется. Но я не про это. Если Вам нужен компактный флагман - посмотрите на Asus zenfone 8 или 9. Там хоть и диагональ 5.9", но он вытянут и рамки небольшие. Скорее всего будет примерно габаритов вашего 5.5" смартфона
В 2005 я поступил в ХАИ и на протяжении первого семестра многие преподаватели вполне серьезно говорили нам, что мы еще не студенты, и называли нас абитуриентами. Говорили, что студентами мы станем, когда сдадим первую сессию.
По сути я брал первую карту, подбирал ей подходящий размер визуально, затем центрировал (допустим, получилась карта шириной 20% и высотой 80%, значит горизонтальное положение будет 50 — 20/10 = 40%, вертикальное подбирал визуально).
Затем создавал две одинаковые карты чуть меньшего размера, чем центральная и зеркально смещал их относительно центра влево/вправо, и так до полного заполнения. Карты заднего фона просто пропроционально уменьшил и сместил немного влево, относительно первого ряда.