В своё время тоже пытался делать это через svgtofont, но в ней столько граблей, что забил на это и слелал всё то же самое через api от fontforge. Зато работает как часы и результат предсказуем.
Поддерживаю snap хорош для десктоп каких то приложений, но никак ни для серверных. Лучше как то иметь контроль над сервисом. Ставлю только руками Nginx-FPM + всё остальное. Более того иногда ну просто необходимо слазить рукам и в исходный код. Недавно мигрировал базу с MySQL в PostgreSQL того же NextCloud, не знаю насколько бы мне это было комфортно, когда бы это было всё промазано обертками. Если мне нужен сервис довольной стабильности и изолированности, то проще запилить виртуалку и не мучать голову с бекапами, бекапя сразу виртуалку с гипервизора.
Ну и да, у меня далеко не энтерпрайс. Обычный домашний сервер для фоточек.
Никто и не говорит, что они прямо наследники Observable. Но если посмотреть на механику и как они встраиваются в шаблон, то там отличий почти нет, по факту всё тоже самое.
Вам чё проект надо создать? Рабочие часы оплатите? Если не умеете работать с потоками и проектировать данные, то пользуйте то, что делает это за вас, вам же никто не запрещает
Всё идет от задач, если вы знаете как это работает под капотом, то для вас не будет никаких проблем это сделать штатными средствами. Всё в Angular по факту базируется на Observable, даже по факту те же сигналы работают на их базе, просто являются сахаром. С любым сахаром придется решать те же проблемы, он легко решает одну проблему и параллельно тихо создает ещё несколько.
Поддержу про NgRx, все эти стейты притянутые из мира Redux далеко не всегда нужны и очень не всегда несут пользу в Angular. Сейчас выпиливаем как раз остатки поделия в виде Mobx, который принес больше боли, чем пользы.
Согласен, там и "умный лифт" из разряда я жду вас на первом этаже) А если я из квартиры еду, зачем мне он на первом этаже? Вся эта автоматизация идёт лесом, стоимость контроллеров завышена на порядок. Щит как по мне так себе, видно что сделано на от...., нормальный владелец всё равно всё переделывать будет. Цены завышены, ну и срок уже перенесли.... в современных условиях его будут доделывать из того что есть, что не очень скажется на качестве.
Нормально всё дебажится, если хоть раз прочитать документацию... А вот от MobX и прочей "магии" в большом проекте больше проблем чем пользы, особенно от всяких autorun и прочего мусора... Спасибо, лучше научиться нормально проектировать слой данных, чем потом страдать от проблем производительности "типового" решения
Всё это конечно хорошо, но во всех этих проектах (NativeScript, ReactNative & etc) узким местом остается мост Javascript, который вносит часто больше проблем чем удобства. Поэтому единственный плюс данных технологий — это возможность переиспользования кода с JS.
Всё остальное становится печалью как только делается шаг в сторону нативки: надо какой то специфический компонент, надо поработать с устройством, надо как то раскрасить не так, надо просто побыстрее отображать что-то, надо как то обрабатывать Touch. Писал приложение на Cordova, NativeScript и Flutter. Так вот лучше уж на Cordova чем на этом фарше из нативки, измазанной в обертках JS, а если хочется скорости, то Flutter, там это хотя бы продуманнее, ну и нативные языки тоже никто не отменял.
Ну картина везде одинаковая, но в случаях если все работает, то зачем лезть в эту муть? Понятно что, когда что-то перестает работать то надо. Сам находил пару ошибок в транспиляторе TS, но как говорится не обновляйся раньше времени и проблем не будет. Проблема в Babel это то что все размыто по куче плагинов, не всегда поддерживаемых самим сообществом. В TS хотя бы оно если заявлено, то в 99% работает.
Ну тут сильно не согласен. Без карт отладка любого транспилированного модуля превращается в нечто нетривиальное. Да и зачем сидеть разбирать транспилированный код, если можно прекрасно дебажить исходный? Я как раз против того, чтобы этим занимались необученные люди. В нашей конторе несколько проектов пишущих фронт и я бы не сказал, что настройка сборки может производиться необученными людьми. Это создает кучу проблем и неудобств.
А насчет угроз безопасности, это смешно… Никто не заставляет эти мапы отдавать заказчику и т.п. Да и сами должны понимать, что JS код не защищен от слова НИКАК
Возможно вы просто пишете на нем, но никогда не лезли глубже, вдобавок наверное никогда не настраивали какую то свою сборку на нем… Это не беда, в нормальных конторах разделение труда. У нас народу немного, поэтому приходится во все тонкости вникать самому. Может быть я просто параноик и хочу знать как что работает ;)
Половина вопросов вытекает из знания JS.
2. Русское наименование дженериков меня вообще в ступор ввело, хотя знаю их еще с C# когда писал в 2005 году
3. Это не реализация, а описание. В принципе таким же методом можно и геттер объявить.
6. Спрашивать про .map в TS? Реально? Если он о них не знает, значит и остальное просто 0.
13. В 2018 кто то вообще пользуется module?
15. Всё так. Никогда не думали что все мыслят по разному и то что принятно в одной команде, легко не принято в другой?
19. Если вы до сих пор используете reference path, я вам сочуствую.
20. Возможность может быть и есть, но нежизнеспособно.
Он уже умер) Собственно и доверия к нему изначально не было.
В своё время тоже пытался делать это через svgtofont, но в ней столько граблей, что забил на это и слелал всё то же самое через api от fontforge. Зато работает как часы и результат предсказуем.
Поддерживаю snap хорош для десктоп каких то приложений, но никак ни для серверных. Лучше как то иметь контроль над сервисом. Ставлю только руками Nginx-FPM + всё остальное. Более того иногда ну просто необходимо слазить рукам и в исходный код. Недавно мигрировал базу с MySQL в PostgreSQL того же NextCloud, не знаю насколько бы мне это было комфортно, когда бы это было всё промазано обертками. Если мне нужен сервис довольной стабильности и изолированности, то проще запилить виртуалку и не мучать голову с бекапами, бекапя сразу виртуалку с гипервизора.
Ну и да, у меня далеко не энтерпрайс. Обычный домашний сервер для фоточек.
Переизобрел Intel NUC и тому подобные MiniPC получается)
Никто и не говорит, что они прямо наследники Observable. Но если посмотреть на механику и как они встраиваются в шаблон, то там отличий почти нет, по факту всё тоже самое.
Вам чё проект надо создать? Рабочие часы оплатите? Если не умеете работать с потоками и проектировать данные, то пользуйте то, что делает это за вас, вам же никто не запрещает
Всё идет от задач, если вы знаете как это работает под капотом, то для вас не будет никаких проблем это сделать штатными средствами. Всё в Angular по факту базируется на Observable, даже по факту те же сигналы работают на их базе, просто являются сахаром. С любым сахаром придется решать те же проблемы, он легко решает одну проблему и параллельно тихо создает ещё несколько.
Не в пользу, а в корзину... RxJS более чем достаточно для большинства даже вполне тяжелых проектов.
Поддержу про NgRx, все эти стейты притянутые из мира Redux далеко не всегда нужны и очень не всегда несут пользу в Angular. Сейчас выпиливаем как раз остатки поделия в виде Mobx, который принес больше боли, чем пользы.
Согласен, там и "умный лифт" из разряда я жду вас на первом этаже) А если я из квартиры еду, зачем мне он на первом этаже? Вся эта автоматизация идёт лесом, стоимость контроллеров завышена на порядок. Щит как по мне так себе, видно что сделано на от...., нормальный владелец всё равно всё переделывать будет. Цены завышены, ну и срок уже перенесли.... в современных условиях его будут доделывать из того что есть, что не очень скажется на качестве.
Все так говорят. А как до дела доходит, то пишут несусветную дичь и обкладывают штатные функции своими велосипедами
Выглядит как скрытая зависть, что человек просто оставил развитие в веб-технологиях 15 лет назад и сейчас хотел бы туда, но уже не может.
Нормально всё дебажится, если хоть раз прочитать документацию... А вот от MobX и прочей "магии" в большом проекте больше проблем чем пользы, особенно от всяких autorun и прочего мусора... Спасибо, лучше научиться нормально проектировать слой данных, чем потом страдать от проблем производительности "типового" решения
Первый же пример "более менее" не эквивалентен. Первый возвращает свойство data от результата fetch, а второй просто результат.
Всё остальное становится печалью как только делается шаг в сторону нативки: надо какой то специфический компонент, надо поработать с устройством, надо как то раскрасить не так, надо просто побыстрее отображать что-то, надо как то обрабатывать Touch. Писал приложение на Cordova, NativeScript и Flutter. Так вот лучше уж на Cordova чем на этом фарше из нативки, измазанной в обертках JS, а если хочется скорости, то Flutter, там это хотя бы продуманнее, ну и нативные языки тоже никто не отменял.
А насчет угроз безопасности, это смешно… Никто не заставляет эти мапы отдавать заказчику и т.п. Да и сами должны понимать, что JS код не защищен от слова НИКАК
2. Русское наименование дженериков меня вообще в ступор ввело, хотя знаю их еще с C# когда писал в 2005 году
3. Это не реализация, а описание. В принципе таким же методом можно и геттер объявить.
6. Спрашивать про .map в TS? Реально? Если он о них не знает, значит и остальное просто 0.
13. В 2018 кто то вообще пользуется module?
15. Всё так. Никогда не думали что все мыслят по разному и то что принятно в одной команде, легко не принято в другой?
19. Если вы до сих пор используете reference path, я вам сочуствую.
20. Возможность может быть и есть, но нежизнеспособно.