В итоге получается что json в stream-json не архивирован.
В парсер stream-json необходимо направлять обычный текст
gzip на сервере отнимает все преимущества стриминга json
Речь в статье была про то, что парсинг JSON блокирует поток исполнения JS, а также требует выделения памяти сразу и на исходный текст, и на итоговый объект. Библиотека stream-json позволяет парсить большой JSON по частям, и соответственно блокировка будет происходит на короткое время, но много раз. Также за счет стрима, например, можно извлечь какую-то информацию из файла, размер которого превышает объем свободной памяти.
В теории можно попробовать при помощи того же сервера выдернуть все зависимости проверяемого файла, и рекурсивно их добавить в список для проверки. Возможно это даже будет работать эффективнее чем прогонять через tsc --noEmit. Правда на такую проверку будет влиять общая связность кода, впрочем это решается параметром максимальной глубины. В любом случае не уверен, что выдача проблемных зависимостей, будет полезна в рамках того процесса миграции, что мы у себя наметили. Но в качестве какого-то вспомогательного инструмента, наверное имеет смысл рассмотреть реализацию этой логики. Спасибо за вопрос!
Сложный вопрос. То есть целью было наоборот избежать такого отслеживания. Подобные зависимости отслеживаются скриптом сборки, и если сборка не падает, значит условно и нет проблем между зависимостями.
Задача в пайплайне с проверкой строгих типов, нужна примерно с такой целью: например разработчик поменял одну строчку где-то в старом файле. При этом сам файл весь светится красным, но разработчик точно знает, что его изменения не повлияют на успех сборки. И раньше такие изменения пропускались через пайплайн, а сейчас их заворачивает утилита. То есть если залез куда-то в старый код что-то исправить, то придется и причесать типы заодно.
У нас сейчас стрикт включен для всех файлов проекта по умолчанию. А для сборки используется отдельный tsconfig без строгого режима. Проверка в CI/CD происходит только для тех файлов, которые изменились в рамках задачи. То есть, в нашем случае, не возникает проблемы, когда необходимо как-то точечно разделить проверку по файлам. Но понимаю, что могут быть кейсы например с тестами или чем-то похожим, в этом случае можно воспользоваться примерно следующей конфигурацией, хотя не уверен что это лучший путь:
Сейчас еще решил проверить как это будет работать в связке с вашим плагином. В общем всё хорошо, как и ожидалось: то есть плагин можно настроить только на подсветку, а для автоматизации проверки в CI использовать утилиту.
Заголовок спойлера
Касательно второго пункта, это класс, который предоставляет пакет, помимо самой утилиты. В случае утилиты, это просто базовая функциональность, через которую и происходит проверка файлов. Но в протоколе тайпскрипт сервера есть много всего интересного, вдруг у кого-то возникнет желание поиграть с ним, поэтому и добавил это в пакет и в статью, как довольно простой способ взаимодействия с сервером через nodejs.
Многие наверно подумаю что это же "просто"! А вот нифига. Написать "просто" - сложнее чем просто написать
Еще у Паскаля было: "Письмо это вышло более длинным только потому, что у меня не было времени написать короче". В общем, это просто проблема оптимизации, которая обычно не решается за 2-3 итерации. За это время можно даже не успеть понять, что конкретно следует оптимизировать и в ущерб чему.
Из примера так и не понял почему одно лучше другого. Для меня выглядят как инструменты для решения немного разных задач. По крайней мере, я обычно разделяю задачи построения лейаута и передачи данных. Иногда эти задачи, конечно, тесно сплетаются, взять например реактивные формы, или таблицы из cdk и прочее. Но такой декларативный подход далеко не всегда уместен, и зачастую сложнее в реализации и поддержке (тут можно обратиться к исходникам тех же форм и таблиц).
В Ваших примерах, количество строк на таком объеме сильно зависит от стиля написания кода, что как бы не совсем объективное сравнение.
Правда одно из существенных отличий в этих примерах я вижу в том как объявляются шаблоны. Метод render в Lit обладает контекстом this и следовательно для него будет работать типизация, подсказки редактора, линтеры и все прочее. Помимо этого, это также снимает сразу множество вопросов по композиции шаблонов.
Для шаблонов в Symbiote без какого-то дополнительного туллинга, как у того же angular, может стать больно. И совсем не очевидно как составлять сложные компоненты, с условиями, списками и т. д. То есть порог входа как-будто становится сильно больше чем у Lit. Но тут вопрос конечно в дизайне, и в том какую проблему этим решали.
Но это так, просто мнение после первого взгляда. В целом спасибо за статью, было интересно ознакомиться.
На сайте Lit, сразу же на главной странице есть пример с декораторами. Что по ощущениям, должно сильно снижать количество бойлерплейта в подобных примерах.
Хотя возможно это особенность V8. Вообще нас еще на первом курсе учили, что довольно опасно проверять на равенство числа с плавающей запятой, независимо от языка.
017 - это 15, так как с префиксом 0 записываются числа в восьмеричной системе. Number("017") - это 17, так как по правилам приведения типов, 0 в начале строки не учитывается. 018 - это 18, так как такая запись не может быть восьмеричной, Number("018") - так же 18, по правилам приведения типов.
В данном примере все конвертируется одинаково. Проблема в том, что используется устаревший синтаксис. То есть дело не том, что авторы языка не видят в этом проблемы, просто ничего не могут с этим сделать, чтобы не сломать разом всю обратную совместимость.
Реализация: Интерфейсы могут быть реализованы классами, в то время как типы не могут быть непосредственно реализованы.
Если речь про implements, то типы могут быть реализованы в виде класса с некоторыми ограничениями.
Объединение типов: Типы могут быть объединены с помощью оператора |, что позволяет создавать объединение типов.
Объединение интерфейсов ничем не отличается от объединения типов, но на выходе, да, получится тип, вместо интерфейса.
Возможности: Интерфейсы обладают некоторыми дополнительными возможностями, такими как объявление методов и наследование интерфейсов.
Ничто не мешает объявить метод внутри типа.
Касательно наследования и расширения, из данного описания как-будто это суть одного и того же:
interface Foo {}
interface Bar extends Foo {}
Foo расширяет Bar
Bar наследует Foo
Но как и в случае с классами, интерфейс может быть расширен типом или унаследован от типа, с некоторыми ограничениями. Примеры.
В основное отличие я бы выделил возможность расширения одного и того же интерфейса, за счет множественного объявления. А дальше уже начинаются различные тонкости.
Люди покупают большие мониторы для того, чтобы на них помещалось больше информации
Не знаю про всех, для себя покупал чтобы видеть приятную картинку на комфортном расстоянии для глаз.
Но если говорить в целом, моя мысль скорее заключалась в том, что нет такой категории людей, как пользователи операционной системы для персональных компьютеров, которая не пересекалась бы с пользователями других систем и других устройств. Чтобы интерфейс подходил как можно большему количеству людей, а особенно новым пользователям, необходимо учитывать опыт других систем и устройств. И так как мир вокруг не стоит на месте, отсюда и процесс изменений в дизайне, а вовсе не из-за тайного заговора дизайнеров. И это не говоря про то, что различные системы сами постоянно меняются, что может требовать адаптации старого интерфейса, под новые возможности.
Меняются размеры экранов, способы ввода, да и в целом персональные устройства. Что является привычным интерфейсом для одних, для других оказывается незнакомым и неудобным.
Понял. В таком случае есть стандартный принтер для печати в файл, но вроде как начиная только с win 10. До этого подобный принтер например появлялся после установки Adobe Reader. Короче в любом случае выглядит как пустяковая проблема.
Для меня лучший вариант, когда можно выполнить необходимое действие нажатием одной или нескольких клавиш. И для себя я вообще не ощутил каких-то изменений в привычных паттернах, после обновления до 11.
Но вот попробуйте объяснить поколению, которое с детства привыкло пользоваться тачскрином и видеть те же настройки чего-угодно в виде вложенных списков, с возможностью поиска по ним, что лучший вариант это оказывается иконки, и многоуровневые окна, в которых ты вряд ли найдешь нужный переключатель без гугла.
сейчас это удобно и быстро, как никогда: Win+R, ввод wt
Слишком сложно как по мне. Я для себя написал небольшой скрипт для Autohotkey, чтобы запускать терминал по F1. Хотя там в какой-то момент добавили и нативную поддержку такого режима открытия.
мы вполне получаем преимущество эвент-лупа, где по сути каждая таска внутри это такой микро-поток в частно случае
Ну и пусть горутина потребляет всего пару килобайт
Что-то я вижу в этом некоторое противоречие.
Если честно, практически незнаком с go, и как там считают потребление горутин, но в event-loop также есть свои накладные расходы на описание структуры задач, хранение их в очереди, на запуск и прочее. При этом libuv может обрабатывать задачи только в одном потоке, а Go этим не ограничен. Что эффективнее в плане накладных расходов: одна задача в очереди event-loop или одна горутина - для меня лично вопрос открытый.
Впрочем я вообще вел к тому, что асинхронный ввод-вывод, не является какой-то особенностью ноды или nginx. Нода является очень простым и удобным инструментом для создания эффективных веб-сервисов, которые не требуют особых вычислений, а например только гоняют данные из базы и обратно. Но нода это не про эффективное распределение нагрузки и параллельные вычисления, так как у нее практически нет для этого инструментов. Так что это просто очевидный ее минус, но опять же в контексте проектов, где это требуется. И тут я согласен с автором треда, что подобный бенчмарк практически бессмысленен.
В парсер stream-json необходимо направлять обычный текст
Речь в статье была про то, что парсинг JSON блокирует поток исполнения JS, а также требует выделения памяти сразу и на исходный текст, и на итоговый объект. Библиотека stream-json позволяет парсить большой JSON по частям, и соответственно блокировка будет происходит на короткое время, но много раз. Также за счет стрима, например, можно извлечь какую-то информацию из файла, размер которого превышает объем свободной памяти.
В теории можно попробовать при помощи того же сервера выдернуть все зависимости проверяемого файла, и рекурсивно их добавить в список для проверки. Возможно это даже будет работать эффективнее чем прогонять через
tsc --noEmit. Правда на такую проверку будет влиять общая связность кода, впрочем это решается параметром максимальной глубины. В любом случае не уверен, что выдача проблемных зависимостей, будет полезна в рамках того процесса миграции, что мы у себя наметили. Но в качестве какого-то вспомогательного инструмента, наверное имеет смысл рассмотреть реализацию этой логики. Спасибо за вопрос!Сложный вопрос. То есть целью было наоборот избежать такого отслеживания. Подобные зависимости отслеживаются скриптом сборки, и если сборка не падает, значит условно и нет проблем между зависимостями.
Задача в пайплайне с проверкой строгих типов, нужна примерно с такой целью: например разработчик поменял одну строчку где-то в старом файле. При этом сам файл весь светится красным, но разработчик точно знает, что его изменения не повлияют на успех сборки. И раньше такие изменения пропускались через пайплайн, а сейчас их заворачивает утилита. То есть если залез куда-то в старый код что-то исправить, то придется и причесать типы заодно.
У нас сейчас стрикт включен для всех файлов проекта по умолчанию. А для сборки используется отдельный tsconfig без строгого режима. Проверка в CI/CD происходит только для тех файлов, которые изменились в рамках задачи. То есть, в нашем случае, не возникает проблемы, когда необходимо как-то точечно разделить проверку по файлам. Но понимаю, что могут быть кейсы например с тестами или чем-то похожим, в этом случае можно воспользоваться примерно следующей конфигурацией, хотя не уверен что это лучший путь:
Заголовок спойлера
tsconfig.json
tsconfig.strict.json
tsconfig.not-strict.ts
Сейчас еще решил проверить как это будет работать в связке с вашим плагином. В общем всё хорошо, как и ожидалось: то есть плагин можно настроить только на подсветку, а для автоматизации проверки в CI использовать утилиту.
Заголовок спойлера
Касательно второго пункта, это класс, который предоставляет пакет, помимо самой утилиты. В случае утилиты, это просто базовая функциональность, через которую и происходит проверка файлов. Но в протоколе тайпскрипт сервера есть много всего интересного, вдруг у кого-то возникнет желание поиграть с ним, поэтому и добавил это в пакет и в статью, как довольно простой способ взаимодействия с сервером через nodejs.
Еще у Паскаля было: "Письмо это вышло более длинным только потому, что у меня не было времени написать короче". В общем, это просто проблема оптимизации, которая обычно не решается за 2-3 итерации. За это время можно даже не успеть понять, что конкретно следует оптимизировать и в ущерб чему.
Полнота по Тьюрингу - это математическое понятие, не более того. Связку HTML+CSS тоже можно считать тьюринг-полной.
Из примера так и не понял почему одно лучше другого. Для меня выглядят как инструменты для решения немного разных задач. По крайней мере, я обычно разделяю задачи построения лейаута и передачи данных. Иногда эти задачи, конечно, тесно сплетаются, взять например реактивные формы, или таблицы из cdk и прочее. Но такой декларативный подход далеко не всегда уместен, и зачастую сложнее в реализации и поддержке (тут можно обратиться к исходникам тех же форм и таблиц).
upd: заглянул в документацию primeng, там для кнопки можно передать и различные виды темплейтов: https://primeng.org/button#template , https://primeng.org/button#api.button.templates , то есть поле label не обязательное.
В Ваших примерах, количество строк на таком объеме сильно зависит от стиля написания кода, что как бы не совсем объективное сравнение.
Правда одно из существенных отличий в этих примерах я вижу в том как объявляются шаблоны. Метод
renderв Lit обладает контекстомthisи следовательно для него будет работать типизация, подсказки редактора, линтеры и все прочее. Помимо этого, это также снимает сразу множество вопросов по композиции шаблонов.Для шаблонов в Symbiote без какого-то дополнительного туллинга, как у того же angular, может стать больно. И совсем не очевидно как составлять сложные компоненты, с условиями, списками и т. д. То есть порог входа как-будто становится сильно больше чем у Lit. Но тут вопрос конечно в дизайне, и в том какую проблему этим решали.
Но это так, просто мнение после первого взгляда. В целом спасибо за статью, было интересно ознакомиться.
На сайте Lit, сразу же на главной странице есть пример с декораторами. Что по ощущениям, должно сильно снижать количество бойлерплейта в подобных примерах.
Это особенность чисел с плавающей запятой.
Касательно равенства этих значений в js
Хотя возможно это особенность V8. Вообще нас еще на первом курсе учили, что довольно опасно проверять на равенство числа с плавающей запятой, независимо от языка.
https://floating-point-gui.de/errors/comparison/
017- это 15, так как с префиксом 0 записываются числа в восьмеричной системе.Number("017")- это 17, так как по правилам приведения типов, 0 в начале строки не учитывается.018- это 18, так как такая запись не может быть восьмеричной,Number("018")- так же 18, по правилам приведения типов.В данном примере все конвертируется одинаково. Проблема в том, что используется устаревший синтаксис. То есть дело не том, что авторы языка не видят в этом проблемы, просто ничего не могут с этим сделать, чтобы не сломать разом всю обратную совместимость.
Достаточно просто ознакомиться с синтаксисом и правилами приведения типов.
Или включить строгий режим и не использовать устаревшие конструкции.
Про пункт отличия типов и интерфейсов
Если речь про
implements, то типы могут быть реализованы в виде класса с некоторыми ограничениями.Объединение интерфейсов ничем не отличается от объединения типов, но на выходе, да, получится тип, вместо интерфейса.
Ничто не мешает объявить метод внутри типа.
Касательно наследования и расширения, из данного описания как-будто это суть одного и того же:
FooрасширяетBarBarнаследуетFooНо как и в случае с классами, интерфейс может быть расширен типом или унаследован от типа, с некоторыми ограничениями. Примеры.
В основное отличие я бы выделил возможность расширения одного и того же интерфейса, за счет множественного объявления. А дальше уже начинаются различные тонкости.
Не знаю про всех, для себя покупал чтобы видеть приятную картинку на комфортном расстоянии для глаз.
Но если говорить в целом, моя мысль скорее заключалась в том, что нет такой категории людей, как пользователи операционной системы для персональных компьютеров, которая не пересекалась бы с пользователями других систем и других устройств. Чтобы интерфейс подходил как можно большему количеству людей, а особенно новым пользователям, необходимо учитывать опыт других систем и устройств. И так как мир вокруг не стоит на месте, отсюда и процесс изменений в дизайне, а вовсе не из-за тайного заговора дизайнеров. И это не говоря про то, что различные системы сами постоянно меняются, что может требовать адаптации старого интерфейса, под новые возможности.
Меняются размеры экранов, способы ввода, да и в целом персональные устройства. Что является привычным интерфейсом для одних, для других оказывается незнакомым и неудобным.
Понял. В таком случае есть стандартный принтер для печати в файл, но вроде как начиная только с win 10. До этого подобный принтер например появлялся после установки Adobe Reader. Короче в любом случае выглядит как пустяковая проблема.
Да любые браузеры уже очень давно умеют открывать и соответственно распечатывать PDF.
Для меня лучший вариант, когда можно выполнить необходимое действие нажатием одной или нескольких клавиш. И для себя я вообще не ощутил каких-то изменений в привычных паттернах, после обновления до 11.
Но вот попробуйте объяснить поколению, которое с детства привыкло пользоваться тачскрином и видеть те же настройки чего-угодно в виде вложенных списков, с возможностью поиска по ним, что лучший вариант это оказывается иконки, и многоуровневые окна, в которых ты вряд ли найдешь нужный переключатель без гугла.
Слишком сложно как по мне. Я для себя написал небольшой скрипт для Autohotkey, чтобы запускать терминал по F1. Хотя там в какой-то момент добавили и нативную поддержку такого режима открытия.
Что-то я вижу в этом некоторое противоречие.
Если честно, практически незнаком с go, и как там считают потребление горутин, но в event-loop также есть свои накладные расходы на описание структуры задач, хранение их в очереди, на запуск и прочее. При этом libuv может обрабатывать задачи только в одном потоке, а Go этим не ограничен. Что эффективнее в плане накладных расходов: одна задача в очереди event-loop или одна горутина - для меня лично вопрос открытый.
Впрочем я вообще вел к тому, что асинхронный ввод-вывод, не является какой-то особенностью ноды или nginx. Нода является очень простым и удобным инструментом для создания эффективных веб-сервисов, которые не требуют особых вычислений, а например только гоняют данные из базы и обратно. Но нода это не про эффективное распределение нагрузки и параллельные вычисления, так как у нее практически нет для этого инструментов. Так что это просто очевидный ее минус, но опять же в контексте проектов, где это требуется. И тут я согласен с автором треда, что подобный бенчмарк практически бессмысленен.