проф и любительскому велосипеду нужна камера заднего вида совмещённая с радаром. Вообще, велорадары делает только Гармин, стоят они от $200, могут быть завязаны на инфраструктуру гармина, они как и многое у гармина хорошая штука, но они фуру от легковушки не отличают, разве что срабатывают точно на авто. Вот если картинку или точную карту проецировать на очки или телефон или отдельный модуль-экран того же компьютера это будет полезно.
У вас остается полное право ничего не заворачивать.
как тогда получать доступ к методам и данным сервисов?
У вас остается полное право использовать TypeScript.
даже вендорлок на технологию микрософта тут не очень поможет, пример ниже это просто хешмап (нетипизированная структура) уязвимый к ошибкам неконсистентности: const MyContext = React.createContext(/* some value */);
MyContext.displayName = 'MyDisplayName';
проблемы неравильного структурирования кода, когда вы заворачиваете один сервис в другой что-бы предоставить компоненту который будет в них завернут два сервиса это страшное с точнки зрения инженерии дело. Это будет стимулировать разработчиков лепить всю бизнелогику в огромные монолиты-помойки нарушающие принцип Single Of Responsibility, потому что добавлять новую зависимость будет сложнее чем наговнякать методов в существующий сервис. Есть отобразить этот код в виде UML диаграммы станет еще страшнее. Кроме того, автодополнение и проверка во время компиляции, в таком полностью динамически и нетипизированно связываемом коде как я понимаю тоже не будет работать как она не работала с экшинами редакса.
тут есть два момента:
1. ранние веб-компоненты были уродливы, там было много ошибок включая html imports, когда весь код компонента заворачивался в один хтмл файл и старомодный стиль кода на хешмапах (обжектах) вместо классов и модулей. Поэтому это все пресеклось вместе со смертью полимера. Правда многие другие фрефмворки успели понахватать анти-практик.
2. Одновременно с веб-компонентами появилась мощная компания на продвижение тогде еще только реакта, когда на каждой конференци все слоты были заняты докладами про рекат и в компаниях все ринались все на нем переписывать. Благодаря усилиям ее сторонников эти фреймворки разработанные поперек веб-компонентов заняли весь рынок фронтенд разработки. Т.е. там были локальные завихреня типа фейла ангуряра1 который сделал реакт монополистом и не очень удающихся попыток продвинуть убогий vue.
нынешние веб компоненты v1 это вместе с современным джаваскриптом это совсем не те вебкомпоненты что были ранее, они отличаются также как ангуляр2 от первого
я делал проекты еще с рефлюксом лет пять-семь назад и никакого контекста там не видел, затем на смену ему пришел редакс, потом мобикс, потом все начали талдычить сагу и санк, а теперь вот это все насколько я понял отброшено и надо заворачивать все в теги контекста и меня конечно удивляет как самоуверенно все это туманное прошлое отрицается:)
React.Context появился в фокусе массового применения по моим оценкам за последние год-два. А до того я видел множество проектов и шатаний с одной технологии из списка что я привел на другую. Причем, насколько я понял, контекст достаточно убог, т к принуждает к древовидной иерархичности и при использовании нескольких зависимостей приходится заворачивать их друг в друга. Это редкостное уродство, поэтому скоро думаю ещё что-нибудь появится. Все лишь бы браузерными эвентами и диай нормальным не пользоваться)
так никто же не использовал реакт без этих подсистем. Просто библиотека это когда ты взял ее и выбросил или заменил другой. А когда у тебя архитектура на реакт+что-нибудь_модное_в_этом_году это уже не просто либы.
Вот ангуляром можно было пользоваться без ng-rx разрабатывая полноценные приложения, потому что там просто сервисы и инжектор, которые проблему интеропа между компонентами решали. Vue скорее всего тоже как-нибудь зажмурившись. А вот как наладить взаимодействие между компонентами и переиспользование компонентов бизнес-логики в реакте без подсистем что я перечислял?
по вашей ссылке какой-то устаревший документ, который описывает совсем другое апи, с которым я никогда при работе с веб компонентами не сталкивался, на вид оно как раз предназначалось патчить стандартные браузерные элементы. Предупреждение этого документа ведет на другой, работы по которому были прекращены в пользу разработки стандартов отдельных технологий: Custom Elements, Shadow DOM, Native Templates, совокупность которых и понимаются сейчас под Веб Компонентами.
с реактом обычно используют биндинг данных к элементам интерфейса через подсистему реализующую шину событий, все из того, что я перечислил кроме контекста как раз такие реализации. Контекст же это что-то вроде куцего инжектора превращающего динамическую по сути ML разметку в механизм связывания компонентов.
я когда приделывал кеширование шаблонов между элементами одного класса разница становилась заметна прямо на глаз, возможно вы брали слишком простые или атомарные случаи на которых шаблоны прямо их кусков верстки не дают выйгрыша или клонировали сами элементы по отдельности, что и так делается браузером при создании дерева средствами JS
содержимое веб-компонентов можно рендерить нативными шаблонами, которые являются document-fragment, т.е. могут быть разобраны браузером на ранних этапах или просто разобраны однажды и переиспользованы многократно через клонирование
копмоненты без ооп или со странными его суррогатами тяжелы для разработки и поддержки, о легковесности тут сложно говорить, т.к. жквери и подходы применявшиеся с ним не отличались высокой скоростью работы
jquery как раз не имеет простой компонентной архитектуры, т.е. там есть какой-то .widget, но выглядит все страшненько и шаблонов нет и теневое дерево не поддерживается совсем
есть какой-то специальный способ дорабатывать стандартные элементы навроде аттрибута is, но я не пробовал с ним работать и не уверен, что это правильный подход. В прошлом были фреймворки навроде prototype, которые прямо патчили браузерное апи, но дело с ними как-то не пошло
flux, reflux, redux, mobix, saga/thunk, React.Context это то что я навскидку знаю даже если грубо поделить на 10 лет получается один раз в полтора — два года
проф и любительскому велосипеду нужна камера заднего вида совмещённая с радаром. Вообще, велорадары делает только Гармин, стоят они от $200, могут быть завязаны на инфраструктуру гармина, они как и многое у гармина хорошая штука, но они фуру от легковушки не отличают, разве что срабатывают точно на авто. Вот если картинку или точную карту проецировать на очки или телефон или отдельный модуль-экран того же компьютера это будет полезно.
esp32 самые популярные вроде
как тогда получать доступ к методам и данным сервисов?
даже вендорлок на технологию микрософта тут не очень поможет, пример ниже это просто хешмап (нетипизированная структура) уязвимый к ошибкам неконсистентности:
const MyContext = React.createContext(/* some value */);MyContext.displayName = 'MyDisplayName';
1. ранние веб-компоненты были уродливы, там было много ошибок включая html imports, когда весь код компонента заворачивался в один хтмл файл и старомодный стиль кода на хешмапах (обжектах) вместо классов и модулей. Поэтому это все пресеклось вместе со смертью полимера. Правда многие другие фрефмворки успели понахватать анти-практик.
2. Одновременно с веб-компонентами появилась мощная компания на продвижение тогде еще только реакта, когда на каждой конференци все слоты были заняты докладами про рекат и в компаниях все ринались все на нем переписывать. Благодаря усилиям ее сторонников эти фреймворки разработанные поперек веб-компонентов заняли весь рынок фронтенд разработки. Т.е. там были локальные завихреня типа фейла ангуряра1 который сделал реакт монополистом и не очень удающихся попыток продвинуть убогий vue.
нынешние веб компоненты v1 это вместе с современным джаваскриптом это совсем не те вебкомпоненты что были ранее, они отличаются также как ангуляр2 от первого
React.Context появился в фокусе массового применения по моим оценкам за последние год-два. А до того я видел множество проектов и шатаний с одной технологии из списка что я привел на другую. Причем, насколько я понял, контекст достаточно убог, т к принуждает к древовидной иерархичности и при использовании нескольких зависимостей приходится заворачивать их друг в друга. Это редкостное уродство, поэтому скоро думаю ещё что-нибудь появится. Все лишь бы браузерными эвентами и диай нормальным не пользоваться)
Вот ангуляром можно было пользоваться без ng-rx разрабатывая полноценные приложения, потому что там просто сервисы и инжектор, которые проблему интеропа между компонентами решали. Vue скорее всего тоже как-нибудь зажмурившись. А вот как наладить взаимодействие между компонентами и переиспользование компонентов бизнес-логики в реакте без подсистем что я перечислял?
есть какой-то специальный способ дорабатывать стандартные элементы навроде аттрибута is, но я не пробовал с ним работать и не уверен, что это правильный подход. В прошлом были фреймворки навроде prototype, которые прямо патчили браузерное апи, но дело с ними как-то не пошло