Здесь дело не в мутабельности литерального типа (в большинстве современных языков строковые литералы порождают иммутабельные объекты). В C++, к примеру:
Но в Rust запрещены неявные преобразования типов, в том числе от литерала к String. Хочешь сконструировать объект другого типа? Вызови соответствующую фабрику: String::from или to_string трейта Display.
Почему его должно быть больше? Это же обертки над API и всякие бутстраперы WASM-модулей, а логика делается на чем-то WASM-совместимом.
К примеру, у Yew (web_sys) бутстрапер в ~16Кб неминифицированного кода, благодаря чему хэлловорд в сборе выходит меньше размером, чем голый реакт.
вам надо в конкретном приложении сделать, чтобы иконки фалов увеличивались при наведении на имя файла. А компонент этот поддерживаете вообще не вы.
Предлагается изменить внутреннее поведение компонента. Если так, то логичнее было бы его в самом деле форкнуть и наделить необходимым функционалом, а не патчить результат извне. Не факт, что будет дороже, но 100% — надежнее.
Форкать, вставлять костыли и поддерживать их при каждом обновлении?
Внедряясь во внутреннюю структуру разметки и стилей так же никто не сможет гарантировать, что при следующем обновлении все не поломается.
В разных контекстах необходимо менять разные особенности визуализации компонента.
Здесь проблематика аналогична модификаторам в BEM: очень тонкая грань между кастомизацией и вообще другим отображением. Во втором случае — это разные компоненты, в которых можно легко переиспользовать логику, обернутую в хук.
А просовывание классов ломает саму идею компонентного подхода — оборачивающий код жестко завязывается на низкоуровневую специфику отображения своего дочернего компонента.
За примерами можете посмотреть любой более-менее матёрый компонент.
Матерые компоненты (DevExtreme, к примеру) имеют богатые настройки отображения через параметризацию, хотя и поддерживают передачу css-классов в некоторых местах.
необходимость ручного прокидывания: классов для стилизации
Но зачем? Стилизация компонентов — ответственность самих компонентов, а возможная вариативность — это часть явного интерфейса компонента, которой в пропсах самое место. Да и то, не факт, что там нужны именно CSS-классы, а не флаги или другие высокоуровневые параметры.
При обращении по невалидной ссылке уже сейчас JS умеет падать с TypeError, почему вдруг ошибка типа в выражении должна устраивать глобальную катастрофу с белым экраном?
А так — да, это позволило бы повысить качество.
Это никак не отменяет необходимость валидации данных между сервером и клиентом.
Это был лишь один пример. Контракты могут быть разломаны локально, проявляться в более хитрых случаях и все так же далеко уплывать, пользуясь «преимуществом» слабой типизации.
Всякие сложные штуки вроде google docs в расчет не берём, это совсем другая лига
Веб развивается, клиенты все жирнее. Поэтому игнорировать эту проблему чревато. Собственно, здесь и обсуждается WASM, как способ использовать более надежные технологии.
речь про всякие «Access violation reading location», которые переодически возникают.
Если считать это обращением к невалидному/нулевому указателю, то в подобном случае и выполнение JS-скрипта так же отпадает.
Преимущество в том, что система работает непредсказуемо?)
пользователь увидит NaN
Благо, если NaN только в интерфейсе отобразится, а не пойдет дальше под капотом ломать инварианты и шатать бизнес-логику, суля занимательными часами/днями отладки в поисках причины сломанных данных в системе.
А в случае сильной типизации случится рантайм ошибка и сломается вообще всё.
Скорее отлавливаемое исключение (или аналогичная технология обработки ошибок), позволяющее корректно себя обработать или хотя бы показать милое сообщение об ошибке и отправить лог разработчику. Если восстановление работы возможно (и имеет смысл) или затронута лишь незначительная часть приложения/сайта, никто не мешает продолжить работу. Вместо NaN можно написать что-то более осмысленное, например.
Только шарпы ведь специально в wasm не компилят, а затаскивают реализацию виртуальной машины, которая исполняет обычный байткод дотнета. Из ощутимых проблем — это увеличивает размер бандла, хотя код рантайма отлично кэшируется.
В веб-фреймворках под WASM обычно реализованы обертки с интеропом под капотом, чтобы у пользователя не было нужды вылезать из привычной технологии. А тот же Razor для C# вовсе заточен на создание интерфейсов.
В чем проблема сделать новое браузерное API, если обратная совместимость нас не тянет? Это как раз тот случай, когда можно и нужно. Легаси продолжит использовать интероп, ибо и сам JS сразу никуда не планирует исчезать из браузеров.
типа литерал это строка которую нельзя менять?Здесь дело не в мутабельности литерального типа (в большинстве современных языков строковые литералы порождают иммутабельные объекты). В C++, к примеру:
const char* literalData = "Hello World!";std::string myStringObject = literalData; // OK, implicit std::string ctor callНо в Rust запрещены неявные преобразования типов, в том числе от литерала к String. Хочешь сконструировать объект другого типа? Вызови соответствующую фабрику: String::from или to_string трейта Display.
Когда в FF вкладки перестают влезать, панель вкладок начинает прокручиваться. А минимальный размер конфигурируется стандартными средствами.
К примеру, у Yew (web_sys) бутстрапер в ~16Кб неминифицированного кода, благодаря чему хэлловорд в сборе выходит меньше размером, чем голый реакт.
На все поставленные вами вопросы вроде бы ответил прямо или косвенно. Давайте еще раз:
Тут вы число ждали? Вслепую оценивать объем работ как-то странно.
Искать более подходящий компонент или форкать имеющийся.
Предлагаемый подход с патчингом удовлетворяет лишь крайнему пункту.
Предлагается изменить внутреннее поведение компонента. Если так, то логичнее было бы его в самом деле форкнуть и наделить необходимым функционалом, а не патчить результат извне. Не факт, что будет дороже, но 100% — надежнее.
Внедряясь во внутреннюю структуру разметки и стилей так же никто не сможет гарантировать, что при следующем обновлении все не поломается.
Здесь проблематика аналогична модификаторам в BEM: очень тонкая грань между кастомизацией и вообще другим отображением. Во втором случае — это разные компоненты, в которых можно легко переиспользовать логику, обернутую в хук.
А просовывание классов ломает саму идею компонентного подхода — оборачивающий код жестко завязывается на низкоуровневую специфику отображения своего дочернего компонента.
Матерые компоненты (DevExtreme, к примеру) имеют богатые настройки отображения через параметризацию, хотя и поддерживают передачу css-классов в некоторых местах.
Но зачем? Стилизация компонентов — ответственность самих компонентов, а возможная вариативность — это часть явного интерфейса компонента, которой в пропсах самое место. Да и то, не факт, что там нужны именно CSS-классы, а не флаги или другие высокоуровневые параметры.
А так — да, это позволило бы повысить качество.
Это был лишь один пример. Контракты могут быть разломаны локально, проявляться в более хитрых случаях и все так же далеко уплывать, пользуясь «преимуществом» слабой типизации.
Веб развивается, клиенты все жирнее. Поэтому игнорировать эту проблему чревато. Собственно, здесь и обсуждается WASM, как способ использовать более надежные технологии.
Если считать это обращением к невалидному/нулевому указателю, то в подобном случае и выполнение JS-скрипта так же отпадает.
У нас тут за окошком 2к21 с SPA и прочими serverless во фронтенде.
Вот бы все браузеры падали с сообщением об ошибке, когда пользователь ошибся в домене)
Благо, если NaN только в интерфейсе отобразится, а не пойдет дальше под капотом ломать инварианты и шатать бизнес-логику, суля занимательными часами/днями отладки в поисках причины сломанных данных в системе.
Скорее отлавливаемое исключение (или аналогичная технология обработки ошибок), позволяющее корректно себя обработать или хотя бы показать милое сообщение об ошибке и отправить лог разработчику. Если восстановление работы возможно (и имеет смысл) или затронута лишь незначительная часть приложения/сайта, никто не мешает продолжить работу. Вместо NaN можно написать что-то более осмысленное, например.
Только шарпы ведь специально в wasm не компилят, а затаскивают реализацию виртуальной машины, которая исполняет обычный байткод дотнета. Из ощутимых проблем — это увеличивает размер бандла, хотя код рантайма отлично кэшируется.
С поправкой на то, что WASM должен быть готов к исполнению JS (встроена стандартная библиотека, GC и т.п.).
Blazor и Yew эксплуатируют React-подобный подход с XML-подобным синтаксисом и реактивностью. Первый из коробки отлаживается прямо в девтулзах хрома.
В рантайме типов нет, а слабость типизации все так же присутствует.