Удивительно, что микрофронты все еще актуальная тема Казалось, что те, кому это нужно, уже более менее определились, а те, кто просто интересовались, удовлетворили свое любопытство
Вы невнимательно читали =) Интерфейс бека генерируется автоматом, мне при изменении нейминга вообще делать не придется ничего, все сделает ts, в этом и прелесть Вы же не демаете, что нет сервисной функции, которая выполняет запрос?
Окей, в этой ситуации вы содержите те же 30 строк, только размазанные по проекту, появляется дополнительное место для поддержки и все такое (ведь адаптер придется и в js написать, верно?). Тоже вариант Кажется, за это мы и любим программирование, что в нем есть десятки способов решить одну и ту же задачу
Простите конечно, но это писал не человек Это поломанный репликант, изображающий выгоревшего синьора помидора или нейронка, которая пишет кучу кода в проекте Все это необъяснимый сюр
Именно из-за различных пониманий термина я и описал, что именно подразумеваю, говоря "рефакторинг". Могут быть разные мнения на этот счет, в статье приведены техники, которые что-то вроде паттернов проектирования, они нацелены на улучшение кода, не изменяя его функциональность Вообще таких техник довольно много (тот же Фаулер описывает их аж 64 в своем классификаторе), но на практике многие из них не применяются или являются слишком сложными. В статье как раз описаны некоторые очень простые способы, как можно сделать приложение лучше и не поломать то, что работает, даже если это глубокое легаси 🙂.
Тут ответ несколько проще - это внешнее апи, которое вы не контроллируете. Хотите перелопатить им бекенд - вперед, это тоже путь. Но кому-то, возможно, нужно более быстрое решение, к тому же, не прям уж оно сложное (все утили вместе с тестами улеглись в 30 строк!)
Есть такая тема, именно из-за нее в конце статьи есть тесты на типы XD) Если практически отвечать на этот вопрос, то такие типы не требуют поддержки, а использование в коде выглядит довольно прозрачно, ex
type RequestPayload = RequireOnlyOne<SwaggerRequestPayload>;
В целом, с перого раза понятно, что делает этот код, а тесты позволяют быть уверенным, что он выполняет свою работу
В дополнение к предыдущему комменту (кстати, этот момент описан в статье), еще добавлю, что мы используем автотипы из сваггера, то есть начальный тип уже у нас есть. Нам нужно только его переработать под конкретные нужды. Когда-нибудь, когда сваггер начнет адекватно размечать такие типы, заживем =)
Не будет, тк _cat ts распарсит как пустая строка + нижнее подчеркивание + cat, поэтому, если строка начинается с нижнего подчеркивания, для этой функции это тоже валидный snake_case
И снова большое спасибо) Я не знаю, кто вы, но ваши комменты бесценны (без иронии)
PS. Да, последний пример исключение, тк пересечение является флагом для ts, а наличие/отсутствие флага воспринимается как отличающий признак (вроде как) Но тут спасает другая привычка - при описании комплексных типов я обычно использую подобный код
type Prettify<T> = T extends Record<string, unknown> ? {
[K in keyof T]: T[K];
} : T
Он нивелирует все флаги и пересечения, делая сравнение максимально точным Если мы добавим этот код в Equals, то, вероятно, это и будет максимально строгое сравнение
type ExtractPath<T extends string> = T extends `:${infer Param}` ? Param : never;
type ExtractPaths<T extends string> =
T extends `${infer Left}/${infer Right}`
? ExtractPaths<Left> | ExtractPaths<Right>
: ExtractPath<T>;
type PathParams<T extends string> = Prettify<Record<ExtractPaths<T>, string>>;
Как вам убедиться, что все это работает и потом поддерживать? В обычном js мы спокойно берем условный jest и покрываем решение тестами, но тестов на типы в ts просто нет В этот момент вы используете описанные в статье шаги и пишете тест-кейсы, например, такие
type Cases = [
Expect<Equals<ExtractPath<':user'>, 'user'>>,
Expect<Equals<ExtractPath<'user'>, never>>
]
И достигаете сразу двойную пользу - ревьюер(пользователь в лице другого разраба) сразу видит, как работает этот код, а при его изменениях ts защитит вас от неожиданного поведения и поломок
Вся эта кухня нужна ровно с той же целью, как и автотесты, только для сложных типов, которые с первого раза иногда прочитать то сложно, не то чтобы проанализировать
Из X опрошенных 29% процентов разработчиков признались, что накручивали опыт А 71% не признались XD
Вопрос о социально неодобряемых действиях всегда имеет большую латентность, даже анонимный Для его нивелирования нужно досконально проверить некую выборку людей, точно узнать, накручивали ли они опыт, а затем посмотреть на результаты их опроса, после чего экстраполировать
Это не кортежи, это такой массив 💁♂️ Если серьезно, хороший вопрос, я не думал о преобразовании кортежей (из наших 1000+ ручек ни одна не использует кортежи) Вообще идея интересная, можно поресерчить, спасибо)
Спасибо, я очень старался 😇 Отвечу ссылкой: https://api.reactrouter.com/v7/functions/react_router.useRoutes.html Да, этот момент продуман, мы используем несколько хелперов, чтобы разделить структуру страницы и вклеивание в нее конечных элементов Возможно, напишу и об этом как-нибудь =)
Коммент топ Доберусь до компа, докину в статью, спасибо =) Полностью решение забирать не буду, иначе всю статью надо будет переписать, но Arg хелпер завезу
Эта функция не является целью статьи и оставлена только для тех, кто хочет прямо сейчас взять и попробовать все на практике. Но даже в реальном проекте она допустима, тк это "условно библиотечная реализация" Функция пишется один раз и густо покрывается тестами, поэтому мы спокойно можем быть уверены в ее корректности Чисто технически, мы можем добавить здесь тайпгарды и, возможно, стоило (мне было лень да и статья не об этом) Ну и стоит добавить, что ts не умеет типизировать Object.keys - а мы то с вами знаем, что он вернет, верно?) И смысл в применении остается, тк все вызовы функции будут работать как часы)
Удивительно, что микрофронты все еще актуальная тема
Казалось, что те, кому это нужно, уже более менее определились, а те, кто просто интересовались, удовлетворили свое любопытство
Вы невнимательно читали =) Интерфейс бека генерируется автоматом, мне при изменении нейминга вообще делать не придется ничего, все сделает ts, в этом и прелесть
Вы же не демаете, что нет сервисной функции, которая выполняет запрос?
Окей, в этой ситуации вы содержите те же 30 строк, только размазанные по проекту, появляется дополнительное место для поддержки и все такое (ведь адаптер придется и в js написать, верно?). Тоже вариант
Кажется, за это мы и любим программирование, что в нем есть десятки способов решить одну и ту же задачу
Простите конечно, но это писал не человек
Это поломанный репликант, изображающий выгоревшего синьора помидора или нейронка, которая пишет кучу кода в проекте
Все это необъяснимый сюр
Именно из-за различных пониманий термина я и описал, что именно подразумеваю, говоря "рефакторинг".
Могут быть разные мнения на этот счет, в статье приведены техники, которые что-то вроде паттернов проектирования, они нацелены на улучшение кода, не изменяя его функциональность
Вообще таких техник довольно много (тот же Фаулер описывает их аж 64 в своем классификаторе), но на практике многие из них не применяются или являются слишком сложными.
В статье как раз описаны некоторые очень простые способы, как можно сделать приложение лучше и не поломать то, что работает, даже если это глубокое легаси 🙂.
Пример заменил, спасибо =)
Тут ответ несколько проще - это внешнее апи, которое вы не контроллируете. Хотите перелопатить им бекенд - вперед, это тоже путь. Но кому-то, возможно, нужно более быстрое решение, к тому же, не прям уж оно сложное (все утили вместе с тестами улеглись в 30 строк!)
Есть такая тема, именно из-за нее в конце статьи есть тесты на типы XD)
Если практически отвечать на этот вопрос, то такие типы не требуют поддержки, а использование в коде выглядит довольно прозрачно, ex
В целом, с перого раза понятно, что делает этот код, а тесты позволяют быть уверенным, что он выполняет свою работу
В дополнение к предыдущему комменту (кстати, этот момент описан в статье), еще добавлю, что мы используем автотипы из сваггера, то есть начальный тип уже у нас есть. Нам нужно только его переработать под конкретные нужды.
Когда-нибудь, когда сваггер начнет адекватно размечать такие типы, заживем =)
Не будет, тк
_catts распарсит как пустая строка + нижнее подчеркивание + cat, поэтому, если строка начинается с нижнего подчеркивания, для этой функции это тоже валидный snake_caseИ снова большое спасибо)
Я не знаю, кто вы, но ваши комменты бесценны (без иронии)
PS. Да, последний пример исключение, тк пересечение является флагом для ts, а наличие/отсутствие флага воспринимается как отличающий признак (вроде как)
Но тут спасает другая привычка - при описании комплексных типов я обычно использую подобный код
Он нивелирует все флаги и пересечения, делая сравнение максимально точным
Если мы добавим этот код в Equals, то, вероятно, это и будет максимально строгое сравнение
Почему же?
Вот написали вы тип по типу такого
Как вам убедиться, что все это работает и потом поддерживать? В обычном js мы спокойно берем условный jest и покрываем решение тестами, но тестов на типы в ts просто нет
В этот момент вы используете описанные в статье шаги и пишете тест-кейсы, например, такие
И достигаете сразу двойную пользу - ревьюер(пользователь в лице другого разраба) сразу видит, как работает этот код, а при его изменениях ts защитит вас от неожиданного поведения и поломок
Вся эта кухня нужна ровно с той же целью, как и автотесты, только для сложных типов, которые с первого раза иногда прочитать то сложно, не то чтобы проанализировать
Из X опрошенных 29% процентов разработчиков признались, что накручивали опыт
А 71% не признались XD
Вопрос о социально неодобряемых действиях всегда имеет большую латентность, даже анонимный
Для его нивелирования нужно досконально проверить некую выборку людей, точно узнать, накручивали ли они опыт, а затем посмотреть на результаты их опроса, после чего экстраполировать
Наверное, можно пройтись по массиву через infer First, ...infer Rest, это должно сработать, как думаете?
Это не кортежи, это такой массив 💁♂️
Если серьезно, хороший вопрос, я не думал о преобразовании кортежей (из наших 1000+ ручек ни одна не использует кортежи)
Вообще идея интересная, можно поресерчить, спасибо)
Ждали этого коммента 😅
Серьезно, пора начать)
Спасибо, я очень старался 😇
Отвечу ссылкой: https://api.reactrouter.com/v7/functions/react_router.useRoutes.html
Да, этот момент продуман, мы используем несколько хелперов, чтобы разделить структуру страницы и вклеивание в нее конечных элементов
Возможно, напишу и об этом как-нибудь =)
Коммент топ
Доберусь до компа, докину в статью, спасибо =)
Полностью решение забирать не буду, иначе всю статью надо будет переписать, но Arg хелпер завезу
Эта функция не является целью статьи и оставлена только для тех, кто хочет прямо сейчас взять и попробовать все на практике.
Но даже в реальном проекте она допустима, тк это "условно библиотечная реализация"
Функция пишется один раз и густо покрывается тестами, поэтому мы спокойно можем быть уверены в ее корректности
Чисто технически, мы можем добавить здесь тайпгарды и, возможно, стоило (мне было лень да и статья не об этом)
Ну и стоит добавить, что ts не умеет типизировать Object.keys - а мы то с вами знаем, что он вернет, верно?)
И смысл в применении остается, тк все вызовы функции будут работать как часы)
Кажется, автор забыл упомянуть, насколько сложным и объемным является производство мобильных приложений, где он в данный момент трудится