Андрей
А нормальная архитектура - это что?
Дима
Которая позволяет гибко поддерживать и изменять код с минимальным количеством неявных побочных явлений
Дима
Более того, я тебе буквально час назад показал как можно менять имплементацию не меняя самих функций
Дима
И этот подход — сюрприз — я взял не из головы а как раз из хороших практик архитектуры серверных приложений
Дима
Если ты не можешь менять имплементацию без рекомпиляции публичного апи то у тебя проблемы гораздо больше просто геттеров в экспортах
Андрей
Если ты не можешь менять имплементацию без рекомпиляции публичного апи то у тебя проблемы гораздо больше просто геттеров в экспортах
А как её менять, если у тебя не используются функции для доступа к данным?
Андрей
Я перечитаю тред, возможно, я что-то упустил.
Дима
Разделением зоны ответственности
Дима
Фасад апи сам по себе не обязан знать о деталях того, что он вызывает и вполне может быть полностью независимым от любых внутренних изменений
Андрей
Разделением зоны ответственности
Без проблем. Но у тебя есть, к примеру, источник и 15 декораторов, комбинируя которые ты получаешь нужжный тебе результат.
Андрей
И у тебя нет разницы в клиентском коде "с декораторами" ты получаешь данные или без.
Дима
Без проблем. Но у тебя есть, к примеру, источник и 15 декораторов, комбинируя которые ты получаешь нужжный тебе результат.
Я буду надеяться что это стращный сон🙃
Дима
Дима
Нет, спасибо
Дима
🌚
Дима
Я поверю на слово)
Андрей
Пример как ты используя декораторы формируешь чтение таким как тебе надо.
Андрей
Примерно как хоки в реакте)
Андрей
Суть одна и та же ведь.
Дима
Я всё жду развязки, к чему этот пример?)
Андрей
Я всё жду развязки, к чему этот пример?)
К тому, что и с данными в памяти можно делать так же.
Дима
Как?
Андрей
Если они у тебя под геттером, то имплементировать тот же интерфейс и изменить логику метода.
Андрей
Ну или наследоваться. Кому как приятнее.
Дима
Хоки как раз о том, что не нужно ничего наследовать и делать геттером
Дима
Потому что они как раз таки явно оборачивают компонент и так же явно управляют его вызовом
Андрей
Можно не наследовать.
Андрей
Просто ситуации немного разные. В реакте каждый компонент должен жить по своему. На бекенде ты общаешься только с внешним компонентом. Он уже управляет тем, что внутри него.
Андрей
И как реализовывать этот внешний компонент - на вкус разработчика.
Дима
Ну да, и как бы это не накладывает никаких ограничений на то, пользоваться ли геттерами или нет
Андрей
Ты сейчас предлагаешь не называть геттеры геттерами, верно?)
Андрей
Если так, то проблем нет.
Дима
Я пытаюсь понять что в них такого уникального кроме привносимых проблем
Андрей
Ничего. Эта такая же функция, как и все остальные.
Андрей
Просто где-то прямой доступ к полям - норма, а где-то табу.
Дима
Аа, я кажется понял в чем затруднение. Выше ты весь диалог имел ввиду монолитную серверную архитектуру?
Дима
Я просто никак не мног понять в чем проблема пересборки всего одного из узлов архитектуры
Андрей
Не только. Это про проектирование интерфейсов библиотек больше, чем про архитектуру конечного приложения.
Андрей
Но так как любой компонент системы может выпасть в отдельную библиотеку, то гораздо разумнее будет весь доступ к полям как-либо проксировать. А если и понадобится, то компилятор или же jit сам заинлайнит тебе все доступы.
Дима
Проксировать можно не только геттерами же
Короче я понял, традиция использования геттеров уходит корнями во времена когда требовалось пересобирать всё (весь мир)
Дима
В данный момент есть смысл выбирать модульный сервисный подход
Андрей
Проксировать можно не только геттерами же
Короче я понял, традиция использования геттеров уходит корнями во времена когда требовалось пересобирать всё (весь мир)
Ааааа, я правда начинаю подозревать, что тебе не нравится просто название таких функций)
Андрей
Как ты их не называй, они всё равно будут геттерами.
Дима
Я просто знаю что есть какая-либо альтернатива и не люблю когда меня её лишают из-за укоренившихся проблем подхода
Я знаю что я могу делать определенные суждения когда вижу foo.bar которые я не могу делать видя foo.getBar() и мне не нравится что этой уверенности меня лишают
Андрей
Я просто знаю что есть какая-либо альтернатива и не люблю когда меня её лишают из-за укоренившихся проблем подхода
Я знаю что я могу делать определенные суждения когда вижу foo.bar которые я не могу делать видя foo.getBar() и мне не нравится что этой уверенности меня лишают
Я понял. Ты привык, что foo.bar - это атомарное чтение/запись. Ну, не везде так. В некоторых местах это вызов определенной функции.
Дима
Атомарное — действие, я хочу знать что действий не будет вообще) Просто чтение без последствий
Потому что код склонен к содержанию ошибок и чем больше типичных синтаксических оборотов будут гарантировать отсутствие последствий — тем лучше
Андрей
Андрей
Кстати, я нашёл ситуацию, когда геттеры и в js пригодятся.
Дима
КСТАТИ
Дима
Дима
Это делегаты
Дима
Угадай откуда 😄
Андрей
Если тебе в своём коде надо изменить что-то связанное с полем. Тогда вешаешь на поле геттер-сеттер и объявляешь их deprecated)
Дима
Угадай откуда 😄
Короч я к тому, что с этим вполне можно жить и находить выход, главное понимать что проблемы есть
Дима
Андрей
Всегда так делаю кстати
Ну вот, а я только сейчас это осознал. Надо, чтобы во flow добавили в линт такую хрень.
Дима
Есть @deprecated декоратор. Так как он не меняет тип, то его можно использовать в типизированном коде
Андрей
Есть @deprecated декоратор. Так как он не меняет тип, то его можно использовать в типизированном коде
Это рантайм варнинг. А это не очень. Хотелось бы при сборке иметь возможность увидеть всё.
Дима
А, ну так то да
Даня
Konstantin
Ку, реакт или vue? Что выбрать на углубленное изучение?
Андрей
Да и сообщество вокруг него.
ℝei
Работы да, а сообщество и у vue хорошее
Андрей
Работы да, а сообщество и у vue хорошее
Ну, я рекомендую реакт только потому что проблем с ним меньше будет.
ℝei
А какие могут быть проблемы?
Андрей
Отсутсвие работы, отсутствие материалов как надо делать.
ℝei
Второе не нужно по большей части, все интуитивно. но тем не менее все равно не согласен. я считаю уже достаточно много информации по этому поводу можно найти
Андрей
Ну и то, что большая часть сообщества - это китайцы. Гуглишь баги, находишь страницы на китайском(