Если честно, точно я не знаю, но мне вроде говорили, что там какой-то очень дешевый роуминг, сопоставимо с ценой VPN но зато полностью легально можно ходить куда угодно, а VPN это ж нелегальщина.
Я шучу насчет чуда, все логично. В Китае, например, с заграничной симкой в роуминге и Фейсбук и Гугл работает, причем довольно быстро. А у рядовых китайцев все забанено, поэтому особо хитрые покупают гонконгские симки вместо ВПН.
Справедливости ради, когда я попросил отключить услугу "Гудбай роуминг" которую врубают за любой входящий за границей за 599 рублей — вырубили и деньги даже вернули. Так что да, надо трясти их и они будут что-то делать.
Офигеть! Я лет 15 за это платил, сегодня написал в саппорт Мегафона, с формулировкой "Я хотел бы избавиться от городского номера с сохранением моего 921 номера. Слышал это можно сделать только через смену оператора с сохранением номера. Это так?", и они тут же отключили.
Далее диалог
— Вот так просто, раз и отключилась? Когда пару лет назад я об этом спрашивал мне сказали, что это технически невозможно. Я тогда правда не знал, что через переход к другому оператору это можно решить.
— Пару лет назад были другие условия. Сейчас техника развивается, да и мы вместе с ней тоже.
Я несколько более прагматично смотрю. Уровень темплейтов — это самый незначительный уровень в нормальном большом приложении. Все реально важные модули, где нужна архитектура — выше. Если, например, мы говорим о приложениях, которые ворочают данными, особенно в реальном времени, то там ядро данных будет скорее всего вообще ничего не знать о том Vue у вас или допустим Angular или React, потому что там MobX/Redux/RX/plain-vanilla/что-угодно. И по большому счету при правильном подходе должно быть все равно что творится в шаблонах, т.к. верстку переделывают и меняют часто, в том числе полностью с нуля, потому что последние A/B тесты показали, что как было — не годится. И за умную логику в шаблонах/компонентах вместо ядра данных — по голове дадут так и так.
Более того, работать приходится не только с мастерами экстра-класса, поэтому да, скорость разработки в формате "без шлема", а также дешевизна кода, который с большой долей вероятности будет выкинут — это крайне важные вещи.
С точки зрения "по учебнику" я с Вами согласен, но в жизни важны совсем другие вещи. Когда в системе 6000 модулей все должно быть чисто и аккуратно на многих уровнях, и если все правильно сделано на остальных уровнях, шаблон там или не шаблон в глубине уже не имеет значения.
набор конструкций, которые можно использовать в темплейте, существенно ограничен
Знаете сколько диких конструкций с пайпом и наворотами я видел в ngFor https://angular.io/api/common/NgForOf#local-variables. Я не спорю, что с темплейтом прострелить себе ногу сложнее, но зато и выразительность хуже, в JSX можно очень красивые вещи делать, если с умом подходить.
не просто про разделение, а про возможность выделить некий код как общий и переиспользовать его
в первую очередь про то, как отделить то самое "внешнее" от самого компонента
Вы по-моему то же самое написали, но другими словами. У меня акцент на то, что само по себе выделение должно быть оправдано и должно служить некой цели. Если компонент вещь в себе и логика его никому более не нужна — нет смысла что-то из него выделять в HOC/RP/Hook. Выделять имеет смысл то, что можно переиспользовать.
В Angular в темплейте будь здоров можно логики намешать, впрочем, как и везде.
HOC, RP и Hooks не просто про разделение, а про возможность выделить некий код как общий и переиспользовать его. Это библиотечные вещи в первую очередь, как подключить что-то внешнее к компоненту. А как ворочать локальным стейтом — дело десятое, если этого нигде снаружи не видно.
В клиентском коде логика представления очень часто неотделима от компонента, и кроме как в нем больше нигде не нужна, если мы не говорим о какой-то сложной бизнес логике. Пример — какой-нибудь разворачивающийся блок, выпадающее меню, кнопка со спиннером. Если такую логику начинать выносить — оно вроде как правильно с точки зрения паттернов, но выглядит крайне монструозно. Если слепо всем паттернам следовать — получается Java которую невозможно без крови в глазах читать от словоблудия. JS тем и хорош и элегантен, что можно write less do more. За это надо платить. И это риск. Главное головой думать и баланс соблюдать между "как надо" и "как проще".
Хуки кстати позволяют логику вынести легким движением руки на любой стадии, что хорошо.
Они и в разработке так же поступают, начисто игнорируя опыт соседних же команд. Там есть как будто две модели — либо полный коммунизм, когда все всем делятся и ко всему прислушиваются, либо полное огораживание и "свой путь" по всем граблям. Среднего не встречал.
Я сегодня когда статью увидел — чуть кофе не пролил, я писал такие же тексты в презентациях архитектурных, почти дословно, особенно на тему плюсов и минусов, так что путь крайне похож, как и аргументация.
У нас два реестра ;) один — известные компоненты, грубо говоря хардкондый список, мы их сами пишем и к ним доверие (web components) и их можно монтировать руками + реестр установленных у юзера приложений, хранящийся на бакенде, там и наши и сторонние могут быть, это IFRAME/веб-компоненты, интерфейс одинаковый в данном случае, хосту все равно что вставлять на основе урла.
Вдохновлялся… как то само родилось. Поглядывал на приложения VK и FB, на всякие CRM типа ZenDesk, Salesforce и тд., там кто во что горазд извращения, я решил, что надо творчески переосмыслить и пойти простым и понятным путем.
Нам еще следующий шаг предстоит, надо как-то давать приложениям возможность влезать в другие приложения, парсить DOM, добавлять контролы (ну например в список юзеров кнопку с действием) и тд и все это безопасно надо делать, но это совсем другая история.
Если честно, точно я не знаю, но мне вроде говорили, что там какой-то очень дешевый роуминг, сопоставимо с ценой VPN но зато полностью легально можно ходить куда угодно, а VPN это ж нелегальщина.
Я шучу насчет чуда, все логично. В Китае, например, с заграничной симкой в роуминге и Фейсбук и Гугл работает, причем довольно быстро. А у рядовых китайцев все забанено, поэтому особо хитрые покупают гонконгские симки вместо ВПН.
Справедливости ради, когда я попросил отключить услугу "Гудбай роуминг" которую врубают за любой входящий за границей за 599 рублей — вырубили и деньги даже вернули. Так что да, надо трясти их и они будут что-то делать.
Офигеть! Я лет 15 за это платил, сегодня написал в саппорт Мегафона, с формулировкой "Я хотел бы избавиться от городского номера с сохранением моего 921 номера. Слышал это можно сделать только через смену оператора с сохранением номера. Это так?", и они тут же отключили.
Далее диалог
— Вот так просто, раз и отключилась? Когда пару лет назад я об этом спрашивал мне сказали, что это технически невозможно. Я тогда правда не знал, что через переход к другому оператору это можно решить.
— Пару лет назад были другие условия. Сейчас техника развивается, да и мы вместе с ней тоже.
Вот же изворотливые сволочи!
Часто бывает что Мегафон показывает "нет связи", а симка AT&T находящаяся в роуминге через тот же Мегафон — работает. Чудо )
Ну Вам то конечно виднее о чем тут говорят ) а у человека важный для него вопрос назрел!
Я несколько более прагматично смотрю. Уровень темплейтов — это самый незначительный уровень в нормальном большом приложении. Все реально важные модули, где нужна архитектура — выше. Если, например, мы говорим о приложениях, которые ворочают данными, особенно в реальном времени, то там ядро данных будет скорее всего вообще ничего не знать о том Vue у вас или допустим Angular или React, потому что там MobX/Redux/RX/plain-vanilla/что-угодно. И по большому счету при правильном подходе должно быть все равно что творится в шаблонах, т.к. верстку переделывают и меняют часто, в том числе полностью с нуля, потому что последние A/B тесты показали, что как было — не годится. И за умную логику в шаблонах/компонентах вместо ядра данных — по голове дадут так и так.
Более того, работать приходится не только с мастерами экстра-класса, поэтому да, скорость разработки в формате "без шлема", а также дешевизна кода, который с большой долей вероятности будет выкинут — это крайне важные вещи.
С точки зрения "по учебнику" я с Вами согласен, но в жизни важны совсем другие вещи. Когда в системе 6000 модулей все должно быть чисто и аккуратно на многих уровнях, и если все правильно сделано на остальных уровнях, шаблон там или не шаблон в глубине уже не имеет значения.
Знаете сколько диких конструкций с пайпом и наворотами я видел в ngFor https://angular.io/api/common/NgForOf#local-variables. Я не спорю, что с темплейтом прострелить себе ногу сложнее, но зато и выразительность хуже, в JSX можно очень красивые вещи делать, если с умом подходить.
Вы по-моему то же самое написали, но другими словами. У меня акцент на то, что само по себе выделение должно быть оправдано и должно служить некой цели. Если компонент вещь в себе и логика его никому более не нужна — нет смысла что-то из него выделять в HOC/RP/Hook. Выделять имеет смысл то, что можно переиспользовать.
В Angular в темплейте будь здоров можно логики намешать, впрочем, как и везде.
HOC, RP и Hooks не просто про разделение, а про возможность выделить некий код как общий и переиспользовать его. Это библиотечные вещи в первую очередь, как подключить что-то внешнее к компоненту. А как ворочать локальным стейтом — дело десятое, если этого нигде снаружи не видно.
В количестве словоблудия )
В клиентском коде логика представления очень часто неотделима от компонента, и кроме как в нем больше нигде не нужна, если мы не говорим о какой-то сложной бизнес логике. Пример — какой-нибудь разворачивающийся блок, выпадающее меню, кнопка со спиннером. Если такую логику начинать выносить — оно вроде как правильно с точки зрения паттернов, но выглядит крайне монструозно. Если слепо всем паттернам следовать — получается Java которую невозможно без крови в глазах читать от словоблудия. JS тем и хорош и элегантен, что можно write less do more. За это надо платить. И это риск. Главное головой думать и баланс соблюдать между "как надо" и "как проще".
Хуки кстати позволяют логику вынести легким движением руки на любой стадии, что хорошо.
https://overreacted.io/how-are-function-components-different-from-classes/ полезно почитать, там почти сразу пример разобран, когда классовая имплементация ошибки имеет
Вы статью читали? ;) У классов есть существенные недостатки, особенно по части race conditions при асинхронных эффектах.
Это ж не серебряная пуля. Где удобно надо использовать классы. А где удобнее хуки — там хуки.
Там есть schema stitching.
А можно поставить NextJS и выкинуть все шаги кроме последнего для PWA
https://github.com/andywer/webpack-blocks не то же самое ли делает?
Это еще надо как то увязывать с сигналами отменяемых fetch.
Они и в разработке так же поступают, начисто игнорируя опыт соседних же команд. Там есть как будто две модели — либо полный коммунизм, когда все всем делятся и ко всему прислушиваются, либо полное огораживание и "свой путь" по всем граблям. Среднего не встречал.
А не проще ли в проектах компилировать библиотеку? В смысле если все приватное, то зачем вообще компилировать релизы, используйте напрямую...
Я сегодня когда статью увидел — чуть кофе не пролил, я писал такие же тексты в презентациях архитектурных, почти дословно, особенно на тему плюсов и минусов, так что путь крайне похож, как и аргументация.
У нас два реестра ;) один — известные компоненты, грубо говоря хардкондый список, мы их сами пишем и к ним доверие (web components) и их можно монтировать руками + реестр установленных у юзера приложений, хранящийся на бакенде, там и наши и сторонние могут быть, это IFRAME/веб-компоненты, интерфейс одинаковый в данном случае, хосту все равно что вставлять на основе урла.
Вдохновлялся… как то само родилось. Поглядывал на приложения VK и FB, на всякие CRM типа ZenDesk, Salesforce и тд., там кто во что горазд извращения, я решил, что надо творчески переосмыслить и пойти простым и понятным путем.
Нам еще следующий шаг предстоит, надо как-то давать приложениям возможность влезать в другие приложения, парсить DOM, добавлять контролы (ну например в список юзеров кнопку с действием) и тд и все это безопасно надо делать, но это совсем другая история.