Вот это не понял "они меняют и публикуют новый контракт в виде интерфейса на typescript - " - как вы это представляете себе?
после добавления метода на typescript описание метода будет автоматически добавлено в описание интерфейса API - новую версию извлекают при помощи tsc и публикуют.
Если код пишется не на typescript - руками ли либо при помощи тулзы генерируется новое описание API на typescript (в нем будет описание нового метода) Затем контракт так же публикуется
Затем разработчики приложения обновляют у себя пакет и в коде находят ошибки в тех местах где API изменилось - правят код вызова в соответствии с подсказкой IDE о типах и интерфейсе из typescript и всё - работа окончена!
А кто же кроме ребя на сервере знает что изменилось??? Кто меняет - тот и пишет изменения! :)
После изменения кода API они меняют и публикуют новый контракт в виде интерфейса на typescript - все просто!
Если ребята наши (JavaScript) то пишут то они как проффи на typescript - им и делать то ничего не нужно - просто извлечь описание типов из кода при помощи tsc и опубликовать
>Если часть каких-то данных переместили в другой эндпоинт? перемещаете данные из одного эндпоинта в другой в коде приложения
>А как это работает с вложенными эндпоинтами, напр., item/{id}/nested_item ? Что вы подразумеваете под вложенными эндпоинтами? Если вы имеете в виду иерархические структуры данных - просто описываете тип на typescript и он проконтролирует чтобы вы положили туда именно то что требуется
>Или поменялся content type? меняете content-type в вызове метода - я же реализацию написал для примера - вы должны написать реализацию под ваши условия и ограничения
>если у нас уже есть соглашение в рамках RESTfull API в коде показан пример относящийся к REST
рекомендую почитать почему индустрия от FLUX перешла на REDUX - там как раз про это
Во FLUX был однонаправленный поток но не было единого хранилища - и все баги которые возникали - это были баги и проблемы в коде, который связывал разные сторы: ожидание изменений, проверка целостности данных, разнонаправленный поток изменений ...
да действительно, я скорее всего не понял как у вас реализовано
я понимаю, что можно писать без typescript, но считаю что это не верно - типизация это и контракт и документация и банальная гарантия от очепяток и ошибок.
я знаю что много разработчиков не любят typescript, но в промышленной разработке к сожалению без него - никак
не согласен - это называется "опыт" :) когда подхватите один раз зацикленность изменений и просидите в отладке пару дней пытаясь во всем коде приложения ставить брейкпоинты для того, чтобы найти где же произошло зацикливание - сразу же измените мнение. Мы это уже проходили в Bacbone.js и в Marionette.js и других подобных фреймворках ну и до этого в голом MVC
по размеру - да возможно полностью не изучал но по диагонали пробежался - да приблизительно похожая реализация за исключением того, что сама идеология атомов, молекул и кварков в принципе не верная - зачем выносить, к примеру, состояние счетчика из компонента в какой-то атом? - атомы, молекулы кварки если они в реальности связанные сущности придется связывать кодом между собой, код будет размазан, поток данных будет разнонаправленным и не контролируемым и не читаемым - в общем получим классический model hell из MVC
в коде приложения (не в слое API) вам придется изменять только те вызовы что изменились в API: добавить параметр к вызову, переименовать метод, удалить удаленный вызов и т.д.
вы обновляете интерфейс на typescript - он в соответствии с изменениями генерирует ошибки в тех местах кода приложения где API изменился - вы просто исправляете эти ошибки в коде приложения - всё! на клиенте больше ничего не нужно изменять! Proxy подхватит ваши изменения в вызовах и выполнит вызовы API так как вам нужно
изменения в typescript делают ребята, которые пишут сервер API - после изменений они публикуют пакет с описанием интерфейса на typescript и все приложения, которые используют данное API обновляют пакет в своих приложениях и делают только правки в коде приложения там где API изменилось
Давайте начнем сначала: - Proxy позволяет нам писать любой вызов, которого в реальности нет у объекта - интерфейс на typescript позволяет нам генерировать ошибку для не существующих вызовов, не соответствующих описанию вызовов или изменившихся на сервере
При изменении API на сервере вы обновляете описание интерфейса API на typescript и для изменившихся методов в коде получаете ошибки. Вы просто меняете в коде приложения методы вызова с учётом изменений - всё! вам не нужно менять код слоя API - Proxy объект за вас сам применит все изменения
Если у вас API имеет какую-либо систему (у нас на проекте это JSON RPC, у вас может быть своя система к примеру как в коде статьи) - один раз пишите реализацию API слоя, используя Proxy, реализуете все соглашения и ограничения, оформляете в пакет и используете на всех проектах, которые используют такие же соглашения в API.
В проектах при изменении API на бэке обновляете только описание интерфейсов API на typescript, не переписывая сам код API слоя (он не меняется никогда)
Нужно использовать протоколы по их назначению - REST предназначен для публичных API и таки да он сделан удобным для публики, но не для разработчиков Но многие используют REST для внутреннего общения сервисов и больно мучаются при этом
Согласен. Если API написано без применения системы - да к сожалению такой подход не подойдет и придется все время генерировать либо код по схемам либо писать его вручную. Мы в проекте используем JSON RPC, который позволяет описать практически любую реализацию метода в его рамках и он отлично реализуется предложенным методом.
С изменением API вам его придется изменять - Proxy позволяет один раз написать реализацию ваших соглашений и требований к названиям методов, методам HTTP и возвращаемым результатам и не изменять этот слой руками больше никогда - меняются только типы
Наверное в статье я не достаточно четко написал, что реализуется один простой вариант для примера. Я специально не стал писать полные реализации для того чтобы разработчики смогли понять суть и не погрязли бы в деталях реализации. У нас в коде реализован JSON RPC в котором все есть и данные и ошибки.
Если выбирать между этими двумя - я бы выбрал Zustand - практически ничего не весит, не привносит никакой ментальной нагрузки + простой и выразительный синтаксис и огромные возможности
после добавления метода на typescript описание метода будет автоматически добавлено в описание интерфейса API - новую версию извлекают при помощи tsc и публикуют.
Если код пишется не на typescript - руками ли либо при помощи тулзы генерируется новое описание API на typescript (в нем будет описание нового метода) Затем контракт так же публикуется
Затем разработчики приложения обновляют у себя пакет и в коде находят ошибки в тех местах где API изменилось - правят код вызова в соответствии с подсказкой IDE о типах и интерфейсе из typescript и всё - работа окончена!
А кто же кроме ребя на сервере знает что изменилось???
Кто меняет - тот и пишет изменения! :)
После изменения кода API они меняют и публикуют новый контракт в виде интерфейса на typescript - все просто!
Если ребята наши (JavaScript) то пишут то они как проффи на typescript - им и делать то ничего не нужно - просто извлечь описание типов из кода при помощи tsc и опубликовать
>Если часть каких-то данных переместили в другой эндпоинт?
перемещаете данные из одного эндпоинта в другой в коде приложения
>А как это работает с вложенными эндпоинтами, напр., item/{id}/nested_item ?
Что вы подразумеваете под вложенными эндпоинтами? Если вы имеете в виду иерархические структуры данных - просто описываете тип на typescript и он проконтролирует чтобы вы положили туда именно то что требуется
>Или поменялся content type?
меняете content-type в вызове метода - я же реализацию написал для примера - вы должны написать реализацию под ваши условия и ограничения
>если у нас уже есть соглашение в рамках RESTfull API
в коде показан пример относящийся к REST
Очередной вопрос про MobX - зачем MobX если есть Zustand?
Zustand проще, легче и гибче! :)
рекомендую почитать почему индустрия от FLUX перешла на REDUX - там как раз про это
Во FLUX был однонаправленный поток но не было единого хранилища - и все баги которые возникали - это были баги и проблемы в коде, который связывал разные сторы: ожидание изменений, проверка целостности данных, разнонаправленный поток изменений ...
да действительно, я скорее всего не понял как у вас реализовано
я понимаю, что можно писать без typescript, но считаю что это не верно - типизация это и контракт и документация и банальная гарантия от очепяток и ошибок.
я знаю что много разработчиков не любят typescript, но в промышленной разработке к сожалению без него - никак
не согласен - это называется "опыт" :)
когда подхватите один раз зацикленность изменений и просидите в отладке пару дней пытаясь во всем коде приложения ставить брейкпоинты для того, чтобы найти где же произошло зацикливание - сразу же измените мнение.
Мы это уже проходили в Bacbone.js и в Marionette.js и других подобных фреймворках ну и до этого в голом MVC
по размеру - да возможно
полностью не изучал но по диагонали пробежался - да приблизительно похожая реализация за исключением того, что сама идеология атомов, молекул и кварков в принципе не верная
- зачем выносить, к примеру, состояние счетчика из компонента в какой-то атом?
- атомы, молекулы кварки если они в реальности связанные сущности придется связывать кодом между собой, код будет размазан, поток данных будет разнонаправленным и не контролируемым и не читаемым - в общем получим классический model hell из MVC
нет - ни то ни другое :)
в коде приложения (не в слое API) вам придется изменять только те вызовы что изменились в API: добавить параметр к вызову, переименовать метод, удалить удаленный вызов и т.д.
вы обновляете интерфейс на typescript - он в соответствии с изменениями генерирует ошибки в тех местах кода приложения где API изменился - вы просто исправляете эти ошибки в коде приложения - всё! на клиенте больше ничего не нужно изменять! Proxy подхватит ваши изменения в вызовах и выполнит вызовы API так как вам нужно
изменения в typescript делают ребята, которые пишут сервер API - после изменений они публикуют пакет с описанием интерфейса на typescript и все приложения, которые используют данное API обновляют пакет в своих приложениях и делают только правки в коде приложения там где API изменилось
Давайте начнем сначала:
- Proxy позволяет нам писать любой вызов, которого в реальности нет у объекта
- интерфейс на typescript позволяет нам генерировать ошибку для не существующих вызовов, не соответствующих описанию вызовов или изменившихся на сервере
При изменении API на сервере вы обновляете описание интерфейса API на typescript и для изменившихся методов в коде получаете ошибки. Вы просто меняете в коде приложения методы вызова с учётом изменений - всё! вам не нужно менять код слоя API - Proxy объект за вас сам применит все изменения
Задавайте вопросы - отвечу на остальные
тем, что при изменениях API на сервере вы будете вынуждены заново генерировать или дорабатывать код библиотеки руками.
Предлагаемый же способ исключает доработку кода при изменении API и предлагает в приложении обновлять только интерфейс на typescript
нет - немного не так!
Если у вас API имеет какую-либо систему (у нас на проекте это JSON RPC, у вас может быть своя система к примеру как в коде статьи) - один раз пишите реализацию API слоя, используя Proxy, реализуете все соглашения и ограничения, оформляете в пакет и используете на всех проектах, которые используют такие же соглашения в API.
В проектах при изменении API на бэке обновляете только описание интерфейсов API на typescript, не переписывая сам код API слоя (он не меняется никогда)
Нужно использовать протоколы по их назначению - REST предназначен для публичных API и таки да он сделан удобным для публики, но не для разработчиков
Но многие используют REST для внутреннего общения сервисов и больно мучаются при этом
Согласен. Если API написано без применения системы - да к сожалению такой подход не подойдет и придется все время генерировать либо код по схемам либо писать его вручную.
Мы в проекте используем JSON RPC, который позволяет описать практически любую реализацию метода в его рамках и он отлично реализуется предложенным методом.
С изменением API вам его придется изменять - Proxy позволяет один раз написать реализацию ваших соглашений и требований к названиям методов, методам HTTP и возвращаемым результатам и не изменять этот слой руками больше никогда - меняются только типы
Возможно мое выражение "API слой приложения" не достаточно точное, но в данной статье речь шла только о слое API в приложении - бэк не рассматривался
Наверное в статье я не достаточно четко написал, что реализуется один простой вариант для примера. Я специально не стал писать полные реализации для того чтобы разработчики смогли понять суть и не погрязли бы в деталях реализации.
У нас в коде реализован JSON RPC в котором все есть и данные и ошибки.
Если выбирать между этими двумя - я бы выбрал Zustand - практически ничего не весит, не привносит никакой ментальной нагрузки + простой и выразительный синтаксис и огромные возможности