Незаслуженно мало аудитории знают о канале. Видосы топ. Это вам не какой-нибудь там Владилен с его курсами, это просто кладесь знаний. А ещё токен в редаксе хранить, как по мне так слишком сложно, куда проще в сешенСторадже
@@it-sin9k Это очень заметно! Мечтал о таком качественном контенте. Больше чем уверен, что уже в ближайшее время количество ваших подписчиков будет умножаться.
Очень крутое видео, спасибо за труды! Даже сейчас, при огромном количестве разного обучающего контента, Ваши видео очень ценны - за простоту, качество и наглядность =)
Классное видео :) Правда, мне больше нравится начинать рефакторинг с более высокоуровневых компонентов. Насчет авторизации - я обычно делаю что-то вроде такого: createGetUsersRequest().setAuthToken().execute(), где конструктор конкретного запроса наследуется от родительского класса Request и возвращает экземпляр класса, у которого можно тут же вызвать метод setAuthToken. Компонент AuthTokenHandler я обычно заменяю ивент эмиттером + листенерами - компонент, который ничего не рендерит, может смутить ))
Я думаю тут дело в 3-ех вещах) Первое, потому что вещи сложные, не так много людей любит образовательные каналы Второе, потому что мы не покупаем рекламу Третье, потому что у нас редко выходят выпуски, т.к. тяжело делать качественный контент быстро, и мы стараемся лучше делать полезный контент, чем делать ежедневный контент) Если вам нравится, то что мы делаем, поделитесь ссылками на видео со своими коллегами)
Вот это подача, я думал что будет про сборку скучных классов машин, а тут такой прикол! Очень круто. Синяк запиши видосы про функциональщину в js. Интересен именно твой подход подачи и примеры! Жирный лайк Синяку!
@@it-sin9k я не совсем про манады, скорее про сам функциональный подход- деление на независимые функции, по зонам ответственности. А то иногда даже сеньоры такое г..но пишут, что читать сложно. Но в любом случае респектоз тебе! Ждем серию про тайпскрипт в твоем исполнении.
Если бы я попал сразу на это видео, я бы просто оставил язвительный комментарий и больше бы не тратил время, НО так как я уже видел другие видео, про кишки React реально круто 😎, а то мне как фулстеку некогда туда лазить 🤣. Немного критики: По SRP, конечно, это мелочь, но сейчас модно упомянуть, что причина изменения - это один человек, типа дизайнер, или, для данного примера, бекендер, который меняет API. По организации проекта, конечно, у всех свой опыт, но все, что я видел с таким подходом - это путь к хаосу. Всё-таки нужно делать модули, как в том же Angular. А сам клиент для запросов можно получать или как зависимость, или напрямую импортировать. При чем, организация по слоям, а не по модулям приводит в хаос как на беке, так и на фронте, по моему мнению.
Я всё таки сторонник хранить логику запросов рядом с доменом, в случае с реактом в папке с контейнером который его делает. Иначе, отдельные папки заставляют тебя прыгать по файловой структуре, когда пишешь какой нибудь компонент, так как скорее всего, при таком подходе и actions, reducer etc. лежат в отдельных папках.
Есть хорошее правило описываемое в архитектуре: "храни в одном месте то, что ты будешь изменять по одной и той же причине". Если прямо в компоненте или в thunk/saga вы будете описывать url, method и структуру ответа. Тогда такие изменения как: изменения url адреса, структуры request данных, структуры ответа или вообще миграции с rest на graphql. Потребует от вас редактировать ваши компоненты (и возможно разные в разных частях проекта) вместо отредактировать в одном месте -> package/api. С другой стороны архитекторы твердят, что ваша бизнес логика не должна зависеть от инструментов получения информации. Т.е. внутри бизнес логики может быть метод api.getCars(). И не важно что там под капотом у getCars(), это rest запрос, это сокеты что то прислали или из local storage какую-то информацию достали. Поэтому и используется принцип инверсии зависимостей Я не знаю вашей имплементации, но если она удовлетворяет этим двум идеям, я думаю у вас очень хорошее решение. А мое представленное решение, оно не совсем конечное, скорее размышления про то, как можно еще написать свой проект
@@it-sin9k в моем случае в каждой папке есть файл сервиса, который содержит методы получения данных, условный service.getCars(), а уже в реализации я могу использовать ваш makeRequest. Правда я все же напрямую использую axios
звучит как неплохая альтернатива) Единственное только package/request я бы все таки вынес. Чтобы не использовать напрямую axios, а только через обертку, чтобы текущая страница / модуль не знали ничего об axios, и если вы захотите заменить axios на fetch, то это произошло безшовно в одном или двух файлах :)
Я рад, что удался материал) данный плейлист будет скорее об общей архитектуре не привязываясь к либам или фреймворкам. Какой именно state management интересует? что то типа как работать с Redux?
Хорошо, у меня как раз есть опыт на mobX на сложном проекте, но там сейчас вышла 6 версия mobx-react, поэтому наверное повременю, пока мы мигрируем на 6 версию и свои best practice выработаем)
К обновлению токена через хук есть вопрос конечно, но остальное видео крутое, мысли оч структурированы да и выражают ежедневную боль. мне почему-то трудно объяснить людям важность доменной логики и разбивкой приложени на сервисы, буду прилагать данный плейлист в качестве МАСТРИД!
Только правильней наверное все таки будет этот принцип озвучить как: Компонент должен иметь только одну ПРИЧИНУ для изменения. А то что у него будет одна ответственность уже вытекает из одной причины для изменения.
Суупер полезная информация, автору огромное спасибо! Позвольте поинтересоваться, когда используем ts и хотим как в примере с rest/authorization описать тип передаваемых данных (export const login = (data: loginPayload) => {...}) так вот где бы Вы хранили типы для передаваемых данных (loginPayload) и где типы(интерфейсы) для данных которые придут в качестве ответа с сервера? А ещё, нужно ли их тоже в таком случае экспортировать через index.js (.ts для ts соответственно). Очень хотелось бы разобраться. Спасибо :)
Насколько я помню там 2 варианта работы с ошибками. Один глобальный, при инициализации пакета можно передать callback на ошибки. И локальный на каждый отдельный эндпоинт снаружи вызова метода в try / catch обернуть
Я вот не знаю, как быть. Раньше api писал в отдельной папке, сейчас же помещаю api файл рядом со страницей или компонентом, где используется этот запрос. А что лучше? Кто его знает...
К сожалению, большинство проектов хранят токен не в секьюрных местах (redux / locastorage / indexDB и т.д.). Т.к. выпуск не про секьюрность, я решил не усложнять его более сложными конструкциями. Если у Вас есть желание поделиться историей секьюрного хранения токена, мы будем рады связаться с вами и создать отдельное видео на основании ваших рассуждений. И конечно же в рамках этого видео мы выразим отдельную благодарность вашему участию в создании ролика
@@vladislavstepanov7591 уже много раз так делал, когда на проде лежат сорспамы и девтулзы. Можно спокойно диспатчить ивенты с нужными данными и ломать приложения
Не подскажешь, как этот принцип единственной ответсвенности можно использовать с vue-apollo? Там прикол в том, что внутри компонента приходится указывать свойство apollo, в котором указывать запросы. То есть штука вынести все в api и использовать под капотом fetch/axios/apollo уже не подходит.
У меня нет прямого опыта с такими инструментами. Поэтому даже если я быстро гляну, то скорей всего это будет достаточно сырое решение. Могу лишь дать общие принципы, которыми я пользуюсь. Ваша компонент с вьюшкой по идее не должен знать о том, что у вас существует такой монстр как graphql. Вы должны создать абстракцию между вьюшкой и типом запроса данных. Я не знаю как это сочетается это с apollo, но у меня высока вероятность, что я бы apollo вообще не использовал бы в проекте, а слал бы через обычный fetch на /graphql, как обычный запрос. Для меня он выглядит как jQuery обвязка над DOM методами. В сложных проектах от такого рода абстракций часто избавляются. Но опять же оговорюсь, у меня нет тут экспертного мнения, только мысли вслух
@@it-sin9k по факту да, можно делать запрос через axios/fetch и в граф, но тогда теряется мощь apolloClient`a, где кеши, фрагменты, мутации и прочие штуки, а так же там есть что-то типо своего стора. Но в любом слушае, спасибо за ответ)
Я немного скептичен к кешам от apollo, из того что я понял, он делает кеш каждого запроса. Зачем мне столько данных хранить на клиенте. Я лично если и redux использую большую часть данных там не храню) Но возможно я не очень хорошо понимаю всю идеологию) и я заложник сложных проектов со специфическими нуждами. Возможно для проекта более классического это очень сильно экономит время :)
@@it-sin9k по поводу кеша, там это все настраивается. Итересно стало по поводу Redux. данные что в нем не хранятся, не приходится ли их потом далеко пробрасывать? Ну то есть часто бывает так, что сначала вроде нужны только в одном месте, а потом в 10и и тогда как быть, если изнчально их не убрать в Redux?
перенести в Redux)) чтобы перенести в redux много ума не надо, готовые снипеты в vs code перенесут код за пару минут. Это не проблема. С другой стороны, если я например сделаю экран регистрации всю логику локально: например у меня есть валидация какого либо nickname занята ли он уже кем то, потом подгружу в какой то дропдаун из сервера какие то данные. Я могу работать с этим локально, и пробрасывать сильно не нужно. И завтра окажется, что пользователь редко заходит на страницу регистрации, поэтому ее нужно вырезать из основного чанка. И если ты все локально подгружал, все красиво вырежется. Это лишь один из способов работы с данными)
подскажите пожалуйста как использовать эти модули в проекте? допустим у меня есть компонент MainQuestion в котором мне необходимо выполнить запрос API. Я реализовал данный подход, создав все необходимые папки и файл questions.js, который импортирую в index.js, но как вызвать запрос в комноненте MainQuestion и получить результат запроса? Заранее большое спасибо.
@@it-sin9k на данный момент мой код ничем не отличается от вашего( я просто попытался повторить структуру и остановился на моменте как вызвать функцию запроса из файла index.js в компоненте MainQuesions
вы просто видео это посмотрели только сейчас, а я его делал очень давно) и всех деталей реализации не помню, в разных проектах я делаю схожую реализацию, но они минимально отличаются друг от друга) Поэтому единственное, что я могу предложить, это обсуждать какой-то конкретный код :)
там запросы у меня не ходят на сервер, но общая идеология в примере будет понятна думаю: codesandbox.io/s/smoosh-tree-jw9xw?file=/src/MainQuestions/useGetQuestions.js
я не хотел сильно зацикливаться на таких деталях в этом видео, т.к. они не очень важны, но если очень интересно, набросал на коленке вариант - paste.ubuntu.com/p/4kp9Fyt8FP/
я не хотел сильно зацикливаться на таких деталях в этом видео, т.к. они не очень важны, но если очень интересно, набросал на коленке вариант - paste.ubuntu.com/p/4kp9Fyt8FP/
Хмм, чтобы улучшить читабельность есть несколько способов, вынести этот if в функцию с говорящим названием, таким образом вы спрячете неказистую имплементацию и получите говорящее название функции. Либо можно в самих rest функциях в headers явно вставлять на authorization: true, а authorization: config.token. Либо можно сделать какой-то wrapper над api пакетом, который будет при вызове метода в качестве параметра передавать токен. Можно еще что-то пофантазировать, не знаю какой из вариантов вам покажется более интересным :)
Как вам вариант сделать две функции: makeRequest, и makeRequestWithToken. А вторая будет внутри себя вызывать первую, но уже в хэдерах передавать токен.
*Как API может быть NPM пакетом если у тебя там ПРИНЦЕП ИНВЕРСИИ ЗАВИСИМОСТЕЙ и в API ВСТРОЕНА БИЗНЕС ЛОГИКА??))) У тебя он знает И про юзеров и про авторизацию, и про getCars*
Не вижу никакой проблемы. NPM пакеты это не обязательно публичные пакеты пошареные на весь мир. Вполне себе можно создать приватный NPM пакет, который вы используете на React (web) и React-Native проектах одного и того же продукта. Да это бизнесовые пакеты с инверсией зависимостей
Присоединяюсь к благодарностям Но отмечу, что копировать структуру эндпоинтов на бэкенде для своей структуры API - не лучшая идея. Лучше, как минимум, использовать названия соотвествующих сущностей, над которыми происходят операции. А то слишком сильная связь
@@it-sin9k Отлично Подача супер) и качество на высоте , удивительно, что такое количество подписчиков ) Темы раскрываешь тонкие , мало где о таком говорят )
@@it-sin9k Особенно нравятся примеры SOLID в примере к фронту /React, паттерны так же было бы полезно на примерах React , что бы не просто понять их принцип а именно в процессе работы с Реакт
Спасибо :) Самому такого рода материалов не хватало, вот и решил сделать, то чего не хватает самому. Ну а подписчиков не много потому что сложно привлечь к себе внимания при таком огромном количестве статей / видео / курсов и прочего. Да и видео достаточно узко специализированы
Про архитектуру еще будет, как все это связать во едино, надо сначала реакт пройти, потом какие то стейт менеджменты и там можно уже собирать во едино картину
Я бы уже немного по другому этот пакет api настраивал бы сейчас) но видео не переделать) вообще идея "не деструктуризировать" заключалась в том, чтобы не дублировать 2 раза структуру request запроса. Мол в эту функцию отдаешь уже подготовленные данные для запроса и зря не деструктуризировать.
Отличное объяснение! Единственное что не понятно - последний заголовок, а именно: говорится что подход можно использовать для Session Expired для каждого запроса, а для этого можно добавить функции handler в config.js и в точки входа к каждому поддомену (папка /rest), но разве это не нарушает Single Responsability папки API? Ведь как в конце отмечено, "цель папки - возворящать промис запроса на сервер"? А тут мы вроде как отловкой ошибок занимаемя. Или мб я в ввиду неопытности не знаком с реализацикй Session Expired)) В остальном всё супер, спасибо ;))
Спустя время, думаю это плохой пример Single Responsibility) Это то как можно работать с API, и то я начал чуть иначе работать последние годы) Вот думаю мб даже скрыть это видео)
Отличное структурированное объяснение, спасибо. Нравится ваш подход к организации и визуализации обучающих материалов, редкий )
Спасибо за отзыв!) Нам очень приятно)
Незаслуженно мало аудитории знают о канале. Видосы топ. Это вам не какой-нибудь там Владилен с его курсами, это просто кладесь знаний. А ещё токен в редаксе хранить, как по мне так слишком сложно, куда проще в сешенСторадже
спасибо!)
мы потихоньку растем вашими стараниями)
Аудитории Владилена для туду листов такое не надо.
Согласен на счет Владилена, получить знаний с его видосов крайне сложно. Слишком все поверхностно! Одни презентации курсов и супер проектов)
у меня почти 4 года коммерческого опыта и это лучшее что я находил на эту тему.
На этом канале много всего интересного)
Молодец! Отлично объясняешь! Качественно подготовленный материал, оживленный различными анимациями! Отлично!
Спасибо!) Мы много времени уделяем именно подаче, рады, что это не в пустую)
@@it-sin9k Это очень заметно! Мечтал о таком качественном контенте. Больше чем уверен, что уже в ближайшее время количество ваших подписчиков будет умножаться.
Очень крутое видео, спасибо за труды!
Даже сейчас, при огромном количестве разного обучающего контента, Ваши видео очень ценны - за простоту, качество и наглядность =)
Лучшая награда для меня - это такие отзывы)
Классное видео :) Правда, мне больше нравится начинать рефакторинг с более высокоуровневых компонентов. Насчет авторизации - я обычно делаю что-то вроде такого:
createGetUsersRequest().setAuthToken().execute(), где конструктор конкретного запроса наследуется от родительского класса Request и возвращает экземпляр класса, у которого можно тут же вызвать метод setAuthToken. Компонент AuthTokenHandler я обычно заменяю ивент эмиттером + листенерами - компонент, который ничего не рендерит, может смутить ))
Непонятно, почему так мало подписчиков, сложные вещи очень круто и просто объясняет, топчик.
Я думаю тут дело в 3-ех вещах)
Первое, потому что вещи сложные, не так много людей любит образовательные каналы
Второе, потому что мы не покупаем рекламу
Третье, потому что у нас редко выходят выпуски, т.к. тяжело делать качественный контент быстро, и мы стараемся лучше делать полезный контент, чем делать ежедневный контент)
Если вам нравится, то что мы делаем, поделитесь ссылками на видео со своими коллегами)
Мего годно чел, продолжай в том же духе
Спасибо!)
интересно. спасибо
Очень интересно, спасибо за подачу и материал!
Спасибо :) будем рады и в дальнейшем вашей обратной связи!
Вот это подача, я думал что будет про сборку скучных классов машин, а тут такой прикол! Очень круто. Синяк запиши видосы про функциональщину в js. Интересен именно твой подход подачи и примеры! Жирный лайк Синяку!
Спасибо!)
Я стараюсь темы освещать, которых мы касаемся в ежедневной разработке. А манады мы не пишем особо)
@@it-sin9k я не совсем про манады, скорее про сам функциональный подход- деление на независимые функции, по зонам ответственности. А то иногда даже сеньоры такое г..но пишут, что читать сложно. Но в любом случае респектоз тебе! Ждем серию про тайпскрипт в твоем исполнении.
Возможно позже сделаю блок на эту тему) есть мысли, как это можно подать)
Очень круто! Спасибо за труд, хочу еще :)
спасибо) делитесь видео с коллегами) и мы будем стараться больше видео выпускать)
Невероятное видео! спасибо!
Роста каналу ! Ждем еще видео о архитектуре!
Есть еще плейлист о паттернах) видео немного) но уже что-то)
это просто АХУ***О!! Надо расскачать канал, все кто смотрят, пишите комменты и ставьте лайки !!!
Больше комментариев!)))
Если бы я попал сразу на это видео, я бы просто оставил язвительный комментарий и больше бы не тратил время, НО так как я уже видел другие видео, про кишки React реально круто 😎, а то мне как фулстеку некогда туда лазить 🤣.
Немного критики:
По SRP, конечно, это мелочь, но сейчас модно упомянуть, что причина изменения - это один человек, типа дизайнер, или, для данного примера, бекендер, который меняет API.
По организации проекта, конечно, у всех свой опыт, но все, что я видел с таким подходом - это путь к хаосу. Всё-таки нужно делать модули, как в том же Angular.
А сам клиент для запросов можно получать или как зависимость, или напрямую импортировать.
При чем, организация по слоям, а не по модулям приводит в хаос как на беке, так и на фронте, по моему мнению.
Я всё таки сторонник хранить логику запросов рядом с доменом, в случае с реактом в папке с контейнером который его делает. Иначе, отдельные папки заставляют тебя прыгать по файловой структуре, когда пишешь какой нибудь компонент, так как скорее всего, при таком подходе и actions, reducer etc. лежат в отдельных папках.
Есть хорошее правило описываемое в архитектуре: "храни в одном месте то, что ты будешь изменять по одной и той же причине". Если прямо в компоненте или в thunk/saga вы будете описывать url, method и структуру ответа. Тогда такие изменения как: изменения url адреса, структуры request данных, структуры ответа или вообще миграции с rest на graphql. Потребует от вас редактировать ваши компоненты (и возможно разные в разных частях проекта) вместо отредактировать в одном месте -> package/api.
С другой стороны архитекторы твердят, что ваша бизнес логика не должна зависеть от инструментов получения информации. Т.е. внутри бизнес логики может быть метод api.getCars(). И не важно что там под капотом у getCars(), это rest запрос, это сокеты что то прислали или из local storage какую-то информацию достали. Поэтому и используется принцип инверсии зависимостей
Я не знаю вашей имплементации, но если она удовлетворяет этим двум идеям, я думаю у вас очень хорошее решение. А мое представленное решение, оно не совсем конечное, скорее размышления про то, как можно еще написать свой проект
@@it-sin9k в моем случае в каждой папке есть файл сервиса, который содержит методы получения данных, условный service.getCars(), а уже в реализации я могу использовать ваш makeRequest. Правда я все же напрямую использую axios
звучит не плохо :)
а если вы мигрируете с версии сервера v2 на v3 API, вы обновляете все файлы в проекте? или это в base url зашито?
@@it-sin9k да, создаём инстанс axios с интерсепторами и base url, и всем что нужно
звучит как неплохая альтернатива)
Единственное только package/request я бы все таки вынес. Чтобы не использовать напрямую axios, а только через обертку, чтобы текущая страница / модуль не знали ничего об axios, и если вы захотите заменить axios на fetch, то это произошло безшовно в одном или двух файлах :)
Забавный пример с аксиосом, где вместо инстанса используется анонимная функция с дефолтным экспортом. Очень удобно будет дебажить такие функции.
Уровень - бог
Спасибо :)
Отличная подача материала!
Спасибо!) стараемся сделать это своей фишкой)
Спасибо, это очень полезно!
Спасибо за отзыв) нам помогает это продолжать :)
Великолепное совмещение теории и практики
класс
Мэн, ты крутой! Спасибо за материал. Хотелось бы послушать о state management.
Я рад, что удался материал) данный плейлист будет скорее об общей архитектуре не привязываясь к либам или фреймворкам. Какой именно state management интересует? что то типа как работать с Redux?
@@it-sin9k Redux, мне кажется вымирает. Mobx или xstate.
Хорошо, у меня как раз есть опыт на mobX на сложном проекте, но там сейчас вышла 6 версия mobx-react, поэтому наверное повременю, пока мы мигрируем на 6 версию и свои best practice выработаем)
Крууууто, cпасибо большое
Спасибо!) не пропустите и следующие выпуски по архитектуре)
К обновлению токена через хук есть вопрос конечно, но остальное видео крутое, мысли оч структурированы да и выражают ежедневную боль. мне почему-то трудно объяснить людям важность доменной логики и разбивкой приложени на сервисы, буду прилагать данный плейлист в качестве МАСТРИД!
Спасибо!) вы очень нам помогаете распостранением информации)
маствью
Полезный контент, спасибо
Только правильней наверное все таки будет этот принцип озвучить как: Компонент должен иметь только одну ПРИЧИНУ для изменения. А то что у него будет одна ответственность уже вытекает из одной причины для изменения.
Да, согласен. Я потом тоже подумал, что стоило бы более правильно озвучить принцип. Спасибо за комментарий :)
💥💥💥💥💥💥
Суупер полезная информация, автору огромное спасибо! Позвольте поинтересоваться, когда используем ts и хотим как в примере с rest/authorization описать тип передаваемых данных (export const login = (data: loginPayload) => {...}) так вот где бы Вы хранили типы для передаваемых данных (loginPayload) и где типы(интерфейсы) для данных которые придут в качестве ответа с сервера? А ещё, нужно ли их тоже в таком случае экспортировать через index.js (.ts для ts соответственно). Очень хотелось бы разобраться. Спасибо :)
А для чего нам нужна прослойка в виде редакса, для сеттинга токена? Если мы прямо в запросе на токен будем использовать setToken при резолве?
Да она не нужна по факту. Пример набросал, как можно все это интегрировать с Redux. А так можно заимплементировать многими способами
Советую почитать про re-export модулей. Больно смотреть на эти импорт export, когда есть возможность
export {} from 'path'
А можно, пожалуйста, подсказку где про ошибки посмотреть где их отлавливать в таком случає?
Насколько я помню там 2 варианта работы с ошибками. Один глобальный, при инициализации пакета можно передать callback на ошибки. И локальный на каждый отдельный эндпоинт снаружи вызова метода в try / catch обернуть
Я вот не знаю, как быть.
Раньше api писал в отдельной папке, сейчас же помещаю api файл рядом со страницей или компонентом, где используется этот запрос.
А что лучше? Кто его знает...
Последнее время, я склоняюсь к тому, чтобы хранить рядом с местом использования :)
@@it-sin9k А есть примеры проектов на GiHub с вашей архитектурой? Желательно посложнее)
@@СергейВер-и9ю Есть от разных видео куски только. Сейчас пытаемся делать свою платформу мелкими шажками, там будет больше про архитектуру
Токен в редаксе. Клево. Будем угонять через девтулзы
К сожалению, большинство проектов хранят токен не в секьюрных местах (redux / locastorage / indexDB и т.д.). Т.к. выпуск не про секьюрность, я решил не усложнять его более сложными конструкциями. Если у Вас есть желание поделиться историей секьюрного хранения токена, мы будем рады связаться с вами и создать отдельное видео на основании ваших рассуждений. И конечно же в рамках этого видео мы выразим отдельную благодарность вашему участию в создании ролика
удачи задебажить редакс в продакшене)
Люди ведь тупые, не умеют подключать редакс девтулзы только для дева)
@@vladislavstepanov7591 как показывает практика -- не умеют
@@vladislavstepanov7591 уже много раз так делал, когда на проде лежат сорспамы и девтулзы. Можно спокойно диспатчить ивенты с нужными данными и ломать приложения
Круто, типа свой же токен угнать? 🤣
Хакер уровня Бог 🤣
Не подскажешь, как этот принцип единственной ответсвенности можно использовать с vue-apollo? Там прикол в том, что внутри компонента приходится указывать свойство apollo, в котором указывать запросы. То есть штука вынести все в api и использовать под капотом fetch/axios/apollo уже не подходит.
У меня нет прямого опыта с такими инструментами. Поэтому даже если я быстро гляну, то скорей всего это будет достаточно сырое решение. Могу лишь дать общие принципы, которыми я пользуюсь.
Ваша компонент с вьюшкой по идее не должен знать о том, что у вас существует такой монстр как graphql. Вы должны создать абстракцию между вьюшкой и типом запроса данных. Я не знаю как это сочетается это с apollo, но у меня высока вероятность, что я бы apollo вообще не использовал бы в проекте, а слал бы через обычный fetch на /graphql, как обычный запрос. Для меня он выглядит как jQuery обвязка над DOM методами. В сложных проектах от такого рода абстракций часто избавляются. Но опять же оговорюсь, у меня нет тут экспертного мнения, только мысли вслух
@@it-sin9k по факту да, можно делать запрос через axios/fetch и в граф, но тогда теряется мощь apolloClient`a, где кеши, фрагменты, мутации и прочие штуки, а так же там есть что-то типо своего стора. Но в любом слушае, спасибо за ответ)
Я немного скептичен к кешам от apollo, из того что я понял, он делает кеш каждого запроса. Зачем мне столько данных хранить на клиенте. Я лично если и redux использую большую часть данных там не храню) Но возможно я не очень хорошо понимаю всю идеологию) и я заложник сложных проектов со специфическими нуждами. Возможно для проекта более классического это очень сильно экономит время :)
@@it-sin9k по поводу кеша, там это все настраивается. Итересно стало по поводу Redux. данные что в нем не хранятся, не приходится ли их потом далеко пробрасывать? Ну то есть часто бывает так, что сначала вроде нужны только в одном месте, а потом в 10и и тогда как быть, если изнчально их не убрать в Redux?
перенести в Redux)) чтобы перенести в redux много ума не надо, готовые снипеты в vs code перенесут код за пару минут. Это не проблема. С другой стороны, если я например сделаю экран регистрации всю логику локально: например у меня есть валидация какого либо nickname занята ли он уже кем то, потом подгружу в какой то дропдаун из сервера какие то данные. Я могу работать с этим локально, и пробрасывать сильно не нужно.
И завтра окажется, что пользователь редко заходит на страницу регистрации, поэтому ее нужно вырезать из основного чанка. И если ты все локально подгружал, все красиво вырежется. Это лишь один из способов работы с данными)
подскажите пожалуйста как использовать эти модули в проекте? допустим у меня есть компонент MainQuestion в котором мне необходимо выполнить запрос API. Я реализовал данный подход, создав все необходимые папки и файл questions.js, который импортирую в index.js, но как вызвать запрос в комноненте MainQuestion и получить результат запроса? Заранее большое спасибо.
если бы вы подготовили какой кусок код в sandbox это бы упростило наше общение :)
@@it-sin9k на данный момент мой код ничем не отличается от вашего( я просто попытался повторить структуру и остановился на моменте как вызвать функцию запроса из файла index.js в компоненте MainQuesions
вы просто видео это посмотрели только сейчас, а я его делал очень давно) и всех деталей реализации не помню, в разных проектах я делаю схожую реализацию, но они минимально отличаются друг от друга) Поэтому единственное, что я могу предложить, это обсуждать какой-то конкретный код :)
@@it-sin9k прошу прощение, не подумал) codesandbox.io/s/frosty-firefly-dqnl2?file=/src/packages/api/makeRequest.js вот пример кода
там запросы у меня не ходят на сервер, но общая идеология в примере будет понятна думаю: codesandbox.io/s/smoosh-tree-jw9xw?file=/src/MainQuestions/useGetQuestions.js
А можно показать реализацию функции setToken? Что она вообще делает?
я не хотел сильно зацикливаться на таких деталях в этом видео, т.к. они не очень важны, но если очень интересно, набросал на коленке вариант - paste.ubuntu.com/p/4kp9Fyt8FP/
было бы круто в apple подкасты такое выгружать
Подкасты это же чисто audio контент о_О
Не очень понятно как использовать файл где сеттится токен
я не хотел сильно зацикливаться на таких деталях в этом видео, т.к. они не очень важны, но если очень интересно, набросал на коленке вариант - paste.ubuntu.com/p/4kp9Fyt8FP/
@@it-sin9k спасибо!
4:54 мне кажется эта логика ухудшила читаемость, какая еще есть альтернатива?
Хмм, чтобы улучшить читабельность есть несколько способов, вынести этот if в функцию с говорящим названием, таким образом вы спрячете неказистую имплементацию и получите говорящее название функции.
Либо можно в самих rest функциях в headers явно вставлять на authorization: true, а authorization: config.token.
Либо можно сделать какой-то wrapper над api пакетом, который будет при вызове метода в качестве параметра передавать токен.
Можно еще что-то пофантазировать, не знаю какой из вариантов вам покажется более интересным :)
@@it-sin9k можно просто выделить отдельный хедер для авторизации, fetch, xhr автоматически берет куки для запроса
Как вам вариант сделать две функции: makeRequest, и makeRequestWithToken. А вторая будет внутри себя вызывать первую, но уже в хэдерах передавать токен.
*Как API может быть NPM пакетом если у тебя там ПРИНЦЕП ИНВЕРСИИ ЗАВИСИМОСТЕЙ и в API ВСТРОЕНА БИЗНЕС ЛОГИКА??))) У тебя он знает И про юзеров и про авторизацию, и про getCars*
Не вижу никакой проблемы. NPM пакеты это не обязательно публичные пакеты пошареные на весь мир. Вполне себе можно создать приватный NPM пакет, который вы используете на React (web) и React-Native проектах одного и того же продукта. Да это бизнесовые пакеты с инверсией зависимостей
Присоединяюсь к благодарностям
Но отмечу, что копировать структуру эндпоинтов на бэкенде для своей структуры API - не лучшая идея. Лучше, как минимум, использовать названия соотвествующих сущностей, над которыми происходят операции. А то слишком сильная связь
Ещё про паттерны сними
В планах есть, но очередь из тем так же внушительная)
@@it-sin9k Отлично
Подача супер) и качество на высоте , удивительно, что такое количество подписчиков ) Темы раскрываешь тонкие , мало где о таком говорят )
@@it-sin9k Особенно нравятся примеры SOLID в примере к фронту /React, паттерны так же было бы полезно на примерах React , что бы не просто понять их принцип а именно в процессе работы с Реакт
Спасибо :) Самому такого рода материалов не хватало, вот и решил сделать, то чего не хватает самому. Ну а подписчиков не много потому что сложно привлечь к себе внимания при таком огромном количестве статей / видео / курсов и прочего. Да и видео достаточно узко специализированы
Про архитектуру еще будет, как все это связать во едино, надо сначала реакт пройти, потом какие то стейт менеджменты и там можно уже собирать во едино картину
Почему, деструктуризация входных параметров - это "так себе решение"??
Я бы уже немного по другому этот пакет api настраивал бы сейчас) но видео не переделать)
вообще идея "не деструктуризировать" заключалась в том, чтобы не дублировать 2 раза структуру request запроса. Мол в эту функцию отдаешь уже подготовленные данные для запроса и зря не деструктуризировать.
Отличное объяснение!
Единственное что не понятно - последний заголовок, а именно:
говорится что подход можно использовать для Session Expired для каждого запроса, а для этого можно добавить функции handler в config.js и в точки входа к каждому поддомену (папка /rest), но разве это не нарушает Single Responsability папки API? Ведь как в конце отмечено, "цель папки - возворящать промис запроса на сервер"? А тут мы вроде как отловкой ошибок занимаемя.
Или мб я в ввиду неопытности не знаком с реализацикй Session Expired))
В остальном всё супер, спасибо ;))
Спустя время, думаю это плохой пример Single Responsibility) Это то как можно работать с API, и то я начал чуть иначе работать последние годы) Вот думаю мб даже скрыть это видео)
@@it-sin9k Большое спасибо за видео! А какой хороший пример? Ждем новых видео на эту тему?)
пересмотрел второй раз ) т.к. планируется перепиливать что-то громоздкое
Удачи!)