Прим. от кожаного мешка: Интересно, чатгпт лучше справилась?
Toyota Представляет Симулированную Механическую Коробку Передач для Электромобилей: Новинка с Неограниченным Количеством Скоростей
Электромобили постепенно входят в нашу жизнь, но для многих автолюбителей отсутствие классического "механика" остается препятствием на пути к полной гармонии с электротранспортом. Компания Toyota предложила оригинальное решение этой проблемы, представив патент на симулированную механическую коробку передач для своих электромобилей.
Согласно недавно опубликованному патенту, в этой системе теоретически нет ограничения на количество "передач". Изображения, приложенные к техническому документу, даже демонстрируют версии с до 14 скоростями. Но как это работает на практике?
В документе подробно описывается, что водитель может выбрать любое количество передач в соответствии со своими предпочтениями. Например, можно установить шесть или более ступеней, или даже меньше шести. Главное здесь – свобода выбора для водителя.
Но стоит уточнить, что речь идет не о какой-то электро-механической системе, создающей физические затворы передач в соответствии с желаниями пользователя. Вместо этого, будет фиксированное количество реальных "ворот"; скорее всего шесть, хотя в качестве примера Toyota приводит четыре. Переключение передач происходит так же, как и в обычной механике, но рычаг может возвращаться в нейтральное положение после использования. Затем, проходя через передачи, виртуальный паттерн сдвигается к следующему набору "режимов". Так, выбрав шестую передачу, на дисплее может появиться приглашение переключиться на седьмую и так далее.
Звучит запутанно? Возможно, именно поэтому автопроизводители никогда не стремились к созданию более чем семиступенчатых механических коробок передач для обычных легковых автомобилей. Но когда речь идет о симуляции механической коробки, Toyota считает, что предоставление выбора пользователям – это не что-то вредное.
Это новшество от Toyota обещает добавить новые ощущения в управление электромобилями, приближая их к традиционным автомобилям с ДВС и, возможно, сделав их более привлекательными для широкого круга автолюбителей. Следите за обновлениями – эра электромобилей только начинается, и каждый день приносит что-то новое и удивительное.
Несколько лет назад мы фантазировали на тему таких интерфейсов в телефоне. Продумывали UX всех взаимодействий. Класс, что у вас получилось зарелизиться!
С технической точки зрения, многие SPA-фреймворки умеют из коробки в навигацию. А наличие подобного механизма помимо положительного влияния на UX еще и упрощает разработку, что ведет к ускорению процесса.
PWA-установка на домашний экран довольно простая (по-сравнению, с установокой приложения из Аппстора, например, ввод пароля (а такое бывает) напрочь застопорит процесс установки).
А PWA обладает полноэкранным режимом. Из бонусов -- процесс установки может быть отложен до первого успешного раунда или даже игры.
А если серьезно, полагаю, может случиться такая ситуация, когда на новом роуте понадобятся те же самые данные, загрузка которых только что была прервана.
Именно. В свое время отказался от красивого синтаксиса dot нотаций, когда одна из подобных фич грузила дополнительную библиотеку. Например, в такой карточке (а она может быть одна на всю страницу) нужно отобразить график.
А здесь начинает ломаться tree-shaking. И даже если мы будем использовать такой компонент без графика (дополнительной библиотекой), она притащится вся и целиком, даже если не используется, получается мертвый код налицо.
Если же вместе с dot-нотацией идет в комплекте babel-плагин, тогда уже лучше.
А как по-вашему, браузер хранит их? Собственным механизмом разметки бинарного пространства, предоставленном физическим носителем? Нет, это все лежит в файле того или иного формата. В процессе работы -- в оперативной памяти, а затем сохраняет в файл.
Возражу, в таком смысле можно было бы сконфигурировать webpack на генерацию статических svg, со свойствами fill="currentColor" и т.д., и не иметь оверхеда.
Автоматический бандлинг имеет смысл, так как на среднем проекте очень часто используется максимум 5-10-20 общих иконок (стрелочки, человечки, т.д.), если у вас на проекте сотни разных иконок, то скорее всего, довольно весомая часть из них встречается в одном React-компоненте, который и стоит отправлять в отдельный чанк, возможно, с целом куском UI-я, который окружает эту иконку.
Конечно, при бесконечном большом проекте, конечно, бесконечное число иконок будет иметь смысл превратить в бесконечное число мини-чанков, однако в таком крайнем случае просто svg-иконки как svg-файлы будут самым верным решением.
Хорошая статья для понимания того как работает процесс бандлинга. Однако, оверхед в 1,5мб довольно высок, и многие фреймворки имеют автоматическое создание чанков по страницам, компонентам, где оверхед чанка уже незаметен.
Зачем? на работу/учебу и обратно. Я предпочту припарковать и зарядить, чем тащить с собой еще 5кг-10кг батарей. Не хочу переплачивать за ненужный функционал, которы мне вредит.
Должен быстро заряжаться до полной емкости
Тут либо первое, либо второе. Но с этим пунктом я согласен. Однако, время заряда небольшой батарее будет меньше, чем батареи большей емкости.
Не должен бояться заморозков.
Согласен. Возможно, в модели для северных регионов. Не хочу переплачивать за ненужный функционал.
Должен быть более «тяговитым»
Зачем? Чтобы убиться?
Должен быть безопасным
Согласен. Тогда он должен быть легким и не-«тяговитым»
должен продаваться по цене, доступной российскому покупателю.
Делим на ноль.
И с таким подходом про самокат у авторов получается Батут Рогозина.
Дизайн-система — это UI kit, превращенный в код и связанный с ним, т. е. это система [UI kit] [+] [код].
Т. е. UI kit ≠ дизайн-система!
Не уверен, насчет определений, однако согласен с утверждением, о неравенстве.
В моем понимании:
Дизайн-система -- это набор правил и консистентность в цветах, отступах, комбинациях. Грубо говоря, когда говорят "У нас есть Дизайн-система", подразумевают наличие (или желание) имплементированной логики базовых элементов дизайна.
UI-kit -- это набор компонентов, которые могут следовать дизайн-системе. Однако, этот kit может быть имплементирован где угодно: в коде, графическом редакторе. В отличие от дизайн-системы -- UI-kit, это готовый к использованию набор элементов.
Цифра здесь скорее всего с потолка, однако, потерянное время на код-ревью может быть существенным. А одинаковость кода уменьшает когнитивную нагрузку. А этот фактор имеет долговременный эффект.
Будет горизонтальный скролл страницы на iOs, если не прикрыть overflow: hidden; , который может обрезать тени, вызвать дополнительные визуальные баги или отсутствие работы backdropFilter.
А еще проблемы с width: 100%; или необходимость calc()
Да, вот что меня действительно раздражает, так этот момент, когда компонент написан, но тут возникает задача пробросить ref, и начинается синтаксический ад с forwardRef и Typescript. Пока все скобочки в нужном порядке расставишь, все желание кодить пропадает =)
Но по идее мы можем глобально расширить тип HTMLAttributes, либо же создать новый тип-дженерик, который принимал бы на вход параметры для data-атрибутов.
Вот пример (может кому пригодится), с глобальной модификацией:
Прим. от кожаного мешка: Интересно, чатгпт лучше справилась?
Toyota Представляет Симулированную Механическую Коробку Передач для Электромобилей: Новинка с Неограниченным Количеством Скоростей
Электромобили постепенно входят в нашу жизнь, но для многих автолюбителей отсутствие классического "механика" остается препятствием на пути к полной гармонии с электротранспортом. Компания Toyota предложила оригинальное решение этой проблемы, представив патент на симулированную механическую коробку передач для своих электромобилей.
Согласно недавно опубликованному патенту, в этой системе теоретически нет ограничения на количество "передач". Изображения, приложенные к техническому документу, даже демонстрируют версии с до 14 скоростями. Но как это работает на практике?
В документе подробно описывается, что водитель может выбрать любое количество передач в соответствии со своими предпочтениями. Например, можно установить шесть или более ступеней, или даже меньше шести. Главное здесь – свобода выбора для водителя.
Но стоит уточнить, что речь идет не о какой-то электро-механической системе, создающей физические затворы передач в соответствии с желаниями пользователя. Вместо этого, будет фиксированное количество реальных "ворот"; скорее всего шесть, хотя в качестве примера Toyota приводит четыре. Переключение передач происходит так же, как и в обычной механике, но рычаг может возвращаться в нейтральное положение после использования. Затем, проходя через передачи, виртуальный паттерн сдвигается к следующему набору "режимов". Так, выбрав шестую передачу, на дисплее может появиться приглашение переключиться на седьмую и так далее.
Звучит запутанно? Возможно, именно поэтому автопроизводители никогда не стремились к созданию более чем семиступенчатых механических коробок передач для обычных легковых автомобилей. Но когда речь идет о симуляции механической коробки, Toyota считает, что предоставление выбора пользователям – это не что-то вредное.
Это новшество от Toyota обещает добавить новые ощущения в управление электромобилями, приближая их к традиционным автомобилям с ДВС и, возможно, сделав их более привлекательными для широкого круга автолюбителей. Следите за обновлениями – эра электромобилей только начинается, и каждый день приносит что-то новое и удивительное.
Несколько лет назад мы фантазировали на тему таких интерфейсов в телефоне. Продумывали UX всех взаимодействий. Класс, что у вас получилось зарелизиться!
С технической точки зрения, многие SPA-фреймворки умеют из коробки в навигацию. А наличие подобного механизма помимо положительного влияния на UX еще и упрощает разработку, что ведет к ускорению процесса.
PWA-установка на домашний экран довольно простая (по-сравнению, с установокой приложения из Аппстора, например, ввод пароля (а такое бывает) напрочь застопорит процесс установки).
А PWA обладает полноэкранным режимом. Из бонусов -- процесс установки может быть отложен до первого успешного раунда или даже игры.
Так процесс онбоардинга будет еще проще.
А если серьезно, полагаю, может случиться такая ситуация, когда на новом роуте понадобятся те же самые данные, загрузка которых только что была прервана.
Использовать его фреймворк, очевидно же
Мне кажется, но вы спорите с нейросетью =)
P.S.: Отвечаю ли я нейросети?
P.P.S.: Нейросеть ли я?
Именно. В свое время отказался от красивого синтаксиса
dotнотаций, когда одна из подобных фич грузила дополнительную библиотеку. Например, в такой карточке (а она может быть одна на всю страницу) нужно отобразить график.А здесь начинает ломаться tree-shaking. И даже если мы будем использовать такой компонент без графика (дополнительной библиотекой), она притащится вся и целиком, даже если не используется, получается мертвый код налицо.
Если же вместе с dot-нотацией идет в комплекте
babel-плагин, тогда уже лучше.А как по-вашему, браузер хранит их? Собственным механизмом разметки бинарного пространства, предоставленном физическим носителем? Нет, это все лежит в файле того или иного формата. В процессе работы -- в оперативной памяти, а затем сохраняет в файл.
Возражу, в таком смысле можно было бы сконфигурировать webpack на генерацию статических svg, со свойствами
fill="currentColor"и т.д., и не иметь оверхеда.Автоматический бандлинг имеет смысл, так как на среднем проекте очень часто используется максимум 5-10-20 общих иконок (стрелочки, человечки, т.д.), если у вас на проекте сотни разных иконок, то скорее всего, довольно весомая часть из них встречается в одном React-компоненте, который и стоит отправлять в отдельный чанк, возможно, с целом куском UI-я, который окружает эту иконку.
Конечно, при бесконечном большом проекте, конечно, бесконечное число иконок будет иметь смысл превратить в бесконечное число мини-чанков, однако в таком крайнем случае просто
svg-иконки какsvg-файлы будут самым верным решением.Хорошая статья для понимания того как работает процесс бандлинга. Однако, оверхед в 1,5мб довольно высок, и многие фреймворки имеют автоматическое создание чанков по страницам, компонентам, где оверхед чанка уже незаметен.
Зачем? на работу/учебу и обратно. Я предпочту припарковать и зарядить, чем тащить с собой еще 5кг-10кг батарей. Не хочу переплачивать за ненужный функционал, которы мне вредит.
Тут либо первое, либо второе. Но с этим пунктом я согласен. Однако, время заряда небольшой батарее будет меньше, чем батареи большей емкости.
Согласен. Возможно, в модели для северных регионов. Не хочу переплачивать за ненужный функционал.
Зачем? Чтобы убиться?
Согласен. Тогда он должен быть легким и не-«тяговитым»
Делим на ноль.
И с таким подходом про самокат у авторов получается Батут Рогозина.
Но... mobx рекомендовано использовать с хуками =)
> чему он там "научится"
самому главному -- человеческой натуре
А книги -- это цензурированное и отфильтрованное проявление культуры в довольно узком спектре
А вы правда не видите связи между ламповостью, уменьшением количества интересных статей и отъездом специалистов?
А можно все то же самое, но завернуть все картинки под спойлер?
Могу порекомендовать к чтению эту статью https://habr.com/ru/post/649381/
Особенно актуально в UI-kit'ах
Не уверен, насчет определений, однако согласен с утверждением, о неравенстве.
В моем понимании:
Дизайн-система -- это набор правил и консистентность в цветах, отступах, комбинациях. Грубо говоря, когда говорят "У нас есть Дизайн-система", подразумевают наличие (или желание) имплементированной логики базовых элементов дизайна.
UI-kit -- это набор компонентов, которые могут следовать дизайн-системе. Однако, этот kit может быть имплементирован где угодно: в коде, графическом редакторе. В отличие от дизайн-системы -- UI-kit, это готовый к использованию набор элементов.
Цифра здесь скорее всего с потолка, однако, потерянное время на код-ревью может быть существенным. А одинаковость кода уменьшает когнитивную нагрузку. А этот фактор имеет долговременный эффект.
Будет горизонтальный скролл страницы на iOs, если не прикрыть
overflow: hidden;, который может обрезать тени, вызвать дополнительные визуальные баги или отсутствие работыbackdropFilter.А еще проблемы с
width: 100%;или необходимостьcalc()Да, вот что меня действительно раздражает, так этот момент, когда компонент написан, но тут возникает задача пробросить ref, и начинается синтаксический ад с forwardRef и Typescript. Пока все скобочки в нужном порядке расставишь, все желание кодить пропадает =)
Но по идее мы можем глобально расширить тип HTMLAttributes, либо же создать новый тип-дженерик, который принимал бы на вход параметры для data-атрибутов.
Вот пример (может кому пригодится), с глобальной модификацией: