Indefinite employment contract это большая редкость для NL в наше время, по крайней мере для тех кого перевозят. ВНЖ с таким типом контаркта обычно дают сразу на 5 лет, а не на 1, что довольно удобно, ваш случай.
Но вот только кроме него никто полностью не понимает тонкостей внутреннего устройства этого интерфейса. Т.е. как только у тебя нештатная ситуация, а он в отпуске — все, приплыли. Пишем костыли.
То есть лучше писать костыли чем один раз разобраться с могучим «интерфейсом»?
Я писал про фреймворки. Давайте уже без «воды». Назовите фреймвок, который не требует костомного туллинга?
Когда у тебя код во внешних файлах типового формата, то типовые тулы будут работать вне зависимости от фреймворка потому что это ведь просто JS/TS/CSS/SCSS/HTML/итд файлы которые не нужно кастомным образом выколупывать из SFC для анализа или какой-либо post обработки.
Просто нужно понимать что исходный код не требует некой логической группировки (SFC) и даже наоборот лучше делить код на мелкие части (даже например просто банально потому что будет меньше вероятность конфликтов при мерже). Но группировка может быть нужна потребителю кода или при дистрибуции кода и вот там уже имеет смыслы делать некую логическую группировку и компоненты.
Готовых решений валидации по схеме/сериализации/десериализации/рантайм валидаций ведь для TS много. Свое начали писать потому что захотелось освоить всю мощь TS in action?
> React изначально не было туллинга для jsx, во Vue для SFC
Как раз по той же причине по которой и у свелти, все эти поделки пропагандируют SFC, а React еще доверху намешал кода с шаблонами в своем JSX (фирменнный PHP спагетти-стиль 15 летней давности).
> Все фреймворки требуют кастомного туллинга в любом случае
Это не так. Если все в отделных файлах, то доработки никакие не нужны, тулы просто сканирут файл и все.
Глупости написаны, лок файл необходим. Конечно в публикацию он не попадает и это потому что консьюмер модуля:
— Должен получить зависимости от зависимости согласно semver версиям указанным в засисимости. Если бы лок файл зависимости учитывался, то использовались бы зависимости на момент публикации что было бы плохой идее в большинстве случаев.
— Сам ответственен за работоспособность своего модуля. То есть проверяется работоспособность всей системы/модуля и лочатся все зависимости включая транзитивные при любом обновлении модулей. Это отвественность потребителя/консьюмера модуля.
На самом деле причина одна — переедание. Все остальные причины выдумывает мозг потому что выдумать причину и продолжать жрать проще чем начать кушать умеренно.
Если компонент радумается, что хочется разделить его, то скорее всего был нарушен принцип single responsibility и компонент следует отрефакторить.
Разделение ведь нужно не потому что файл раздувается, а чтобы самый различный туллинг мог работать с файлами. Но если на то пошло, то как раз все мешать в один файл и есть нарушение принципа single responsibility. Что в Vue что в Svelte какая-то нездоровая мода.
В-третьих, подобное сравнение уже проводилось, когда только были заявлены прекрасные характеристики Ivy. В итоге, сравнение показало что сравнивать бесполезно.
В одном случае он сравнивает по скорости, а в другом по размеру, это не серьезно. Хотя чего можно было ожидать в свитере кроме троллинга.
Поддерживаю но уточню что «изящно» звучит как-то по маркетинговому здесь было ругательство. Давайте лучше скажем правильно/дальновидно/грамотно/предусмотрительно/разумно.
JSX пропагандируемый реактом и есть 15-ти летней давности спагетти-код-стайл, видимо потому что в FB изначально было много PHP кодеров и дос сих пор таковые диктуют правила игры имея огромные рычаги маркетингового влияния.
В angular действительно шаблоны можно инлайнить в код компонента как строку, но это опциональная возможность. Как правило шаблоны там в отдельных файла что хорошо. А вот Svelte насколько я понимаю не позволяет использвать 3-files-component модель разработки которая по моему мнению предпочтительна.
В Svelte пропагандируется one-file-component. То есть стили, код и шаблон все в оном файле. При таком подходе сразу отрубается множество полезных инструментов статического анализа кода, форматирования и тд.
Почему автор Svelte не добавляет к сравнению Angular с включенной AOT компиляцией и onPush для всех компонентов (желательно еще с отключенныйми zones, от этого костыля Angular собирается уходить постепенно)?
radio-t известен тем что давно существует, но по сути в основном это просто болтовня о новостях прошедшей недели. Однако ведущие обладают некоторым опытом и эрудицией, на этом и выезжают. Хотя соглашусь что такой формат тоже нужен.
Просто нужно понимать что исходный код не требует некой логической группировки (SFC) и даже наоборот лучше делить код на мелкие части (даже например просто банально потому что будет меньше вероятность конфликтов при мерже). Но группировка может быть нужна потребителю кода или при дистрибуции кода и вот там уже имеет смыслы делать некую логическую группировку и компоненты.
Как раз по той же причине по которой и у свелти, все эти поделки пропагандируют SFC, а React еще доверху намешал кода с шаблонами в своем JSX (фирменнный PHP спагетти-стиль 15 летней давности).
> Все фреймворки требуют кастомного туллинга в любом случае
Это не так. Если все в отделных файлах, то доработки никакие не нужны, тулы просто сканирут файл и все.
— Должен получить зависимости от зависимости согласно semver версиям указанным в засисимости. Если бы лок файл зависимости учитывался, то использовались бы зависимости на момент публикации что было бы плохой идее в большинстве случаев.
— Сам ответственен за работоспособность своего модуля. То есть проверяется работоспособность всей системы/модуля и лочатся все зависимости включая транзитивные при любом обновлении модулей. Это отвественность потребителя/консьюмера модуля.
Неплохой материал.