Мы уже разработали полноценный REST API сервер
с использованием Express и MongoDB в рамках этого курса.
Для того, чтобы этот сервер имел возможность полноценно общаться с нашим клиентом,
мы внесем в него несколько незначительных изменений,
чтобы он возвращал правильные данные, чтобы
наша реализация клиента могла более
эффективно работать с данными, возвращаемыми с нашего сайта сервера.
Итак, чтобы сделать это,
давайте поработаем над несколькими корректировками нашего сайта сервера в этом упражнении.
Прежде чем начать это упражнение,
я предполагаю, что вы не сделали
предыдущий урок по интеграции углового клиента и
сервера, потому что вы делаете этот урок, проходящий через специализацию React.
Таким образом, изменения, которые я сделаю на сервере, будут предполагать, что
версия сервера, который вы изменяете, находится до предыдущего урока.
В случае, если вы сделали этот урок на угловом клиенте,
некоторые из изменений, которые вы сделали на вашем сервере, будут повторены
в этом упражнении, чтобы вы могли пропустить эту часть изменений.
Зайдите на наш сервер в редакторе.
Прежде чем мы начнем работать на сервере,
я бы предложил вам загрузить все изображения, которые я
предоставил в виде zip-файла в ресурсах упражнения под названием images.zip.
Разархивируйте файл, а затем получите все изображения оттуда, а затем скопируйте эти изображения
в общедоступную папку изображений на нашем сервере.
Итак, вы видите, что здесь я скопировал все изображения в мою общую папку изображений здесь
уже потому, что наш сервер - это тот, который будет
обслуживать все эти изображения для нашего клиентского приложения.
Далее мы переходим к CORS и подстраиваем белый список здесь.
Итак, для нашего клиентского приложения React,
если мы запустили команду yarn start,
он запускается под именем вашего компьютера: 3001.
Таким образом, любой запрос, поступающий из нашего местоположения
на сервер, будет нести это как источник там.
Поэтому я собираюсь добавить это в свой белый список, чтобы
любые проблемы CORS были решены автоматически.
Итак, войдя в файл cors.js в моем белом списке здесь,
позвольте мне добавить
имя компьютера http://my: 3001, и это
источник, из которого мой клиент
будет исходить запросы, которые приходят на этот сервер.
Таким образом, мой CORS не вызовет проблем для моего клиента.
Далее, нам нужно обновить несколько маршрутов для
обработки параметров запроса, а также несколько незначительных других корректировок.
Позвольте мне начать с файла promoRouter.js.
Это просто обновить.
Итак, заходя в файл promoRouter.js,
в файле Promorouter для запроса получения, который мы получаем
здесь, вместо того, чтобы делать промо-поиск с пустым объектом JavaScript,
здесь я бы поставил req.query в качестве параметра для промо-акций найти здесь,
то же самое с маршрутизатором лидера.
Итак, позвольте мне перейти к файлу leaderRouter.js.
В маршрутизаторе лидера также,
здесь, где вы найдете leaders.Find с пустым объектом JavaScript вместо того, чтобы
заменить это на req.query, чтобы параметры запроса были переданы в.
Таким образом, это то, где мы передадим функцию: true в качестве параметра запроса здесь.
Теперь, скорректировав эти два,
давайте теперь поработаем над блюдо-маршрутизатором.
Итак, заходите в файл dishRouter.js,
даже в блюдо маршрутизатор также такое же обновление здесь.
Итак, зайдите в эти блюда. Find в методе get здесь,
измените это на req.query.
Итак, с этим обновление моего маршрутизатора тарелок было завершено.
Итак, мы теперь обновили промо-роутер, лидер
и блюдо роутер,
затем перейдем к обновлению любимого роутера.
Теперь вы бы реализовали любимый маршрутизатор как часть вашего четвертого задания.
Теперь, в любимом маршрутизаторе,
вы увидите, что для любимого маршрутизатора,
я не показываю вам оставшуюся часть, потому что
вы должны были сделать как часть вашего задания.
Во-первых, позвольте мне обратить ваше внимание на метод get для Favoriterouter.route:dishid.
Теперь я собираюсь использовать этот метод get, чтобы просто проверить, что
конкретное блюдо с идентификатором блюда уже является любимым для пользователя.
Итак, вместо того, чтобы просто говорить getoperation.suppored,
я просто собираюсь использовать присутствие этой операции get, а затем мы скажем,
favorites.findone, и мы скажем user: req.user. _id.
Таким образом, мы найдем избранное для этого конкретного пользователя, а затем мы скажем, затем
избранное и поймать ошибку далее.
Затем аналогичным образом здесь, мы добавим в ошибку здесь, следующую ошибку здесь.
Итак, внутри этого тогда,
когда мы получим избранное,
то мы проверим, если не фавориты.
Итак, если нет избранного для
этого пользователя, то очевидно, блюдо, которое мы проверяем, не существует,
поэтому мы вернем res.StatusCode 200,
SetHeader, Content-Type,
application/json, а затем мы вернем утверждение существует false.
То, что мы указываем здесь, это то, что если они получают делается до этой конечной точки с идентификатором блюда,
это существует флаг здесь будет установлен в истину, если это блюдо является частью моих любимых.
Если это блюдо не является частью моего избранного,
я установлю там флаг false.
Итак, здесь вы видите, что, поскольку у меня нет фаворитов,
поэтому существует автоматически false на данный момент.
Итак, мы скажем, существует ложь, а затем мы вернем избранное здесь.
Ну, очевидно, в этом случае фавориты будут нулевыми в данный момент.
В противном случае, так что это означает, что избранное не является нулевым,
поэтому мы скажем, если favorites.dishes.indexOf.
Итак, мы будем искать req.params.dishid.
Итак, мы собираемся искать этот массив избранных блюд, чтобы
увидеть, существует ли это блюдо там, и если оно не существует,
очевидно, это вернет отрицательный индекс здесь.
В этом случае также
я верну точно так же, как и здесь.
Итак, если он возвращает отрицательный индекс, то это означает, что
даже если у этого конкретного пользователя есть набор избранных,
это конкретное блюдо не существует в
списке его или ее избранного, поэтому он будет возвращать существует false здесь.
Теперь, в противном случае это означает, что блюдо существует в списке избранного.
Таким образом, в этом случае
я верну код состояния 200 существует true.
Таким образом, когда пользователь выполняет операцию get на этой конечной точке с
/favorites/dishid, где идентификатор блюда поставляется в
качестве параметра здесь, как параметр запроса здесь,
то мы проверим, существует ли это блюдо в избранном.
Если ни один из фаворитов не существует для этого пользователя, то мы вернем существующее false.
Аналогично, если фавориты существует
, но это конкретное блюдо не существует в избранном, то мы вернем false, в
противном случае мы вернем true.
Таким образом, этот флаг существует может быть использован моим клиентом, чтобы проверить, является ли это блюдо
частью списка любимых блюд для этого пользователя или нет.
Кроме того, пока мы находимся в избранном,
всякий раз, когда мы вносим какие-либо изменения в избранное,
мы хотим иметь возможность заполнить информацию пользователя и блюда,
избранное, прежде чем мы вернемся.
Например, в посте, который мы делаем,
когда мы сохраняем избранное, то в этот момент,
мы хотели бы сначала сделать избранное.
FindByID, поэтому, поскольку мы только что внесли изменения, мы скажем favorite_id,
и мы заполним оба пользователя, а также
заполним блюда в избранном.
Затем, когда избранное будет возвращено,
мы вернем это избранное вместо этого.
Итак, позвольте мне внести это изменение.
Итак, мы вырежем это отсюда, а затем внутри,
мы вернем избранное.
После того, как мы сохраним избранное,
то мы будем искать его,
для FavoriteByID, а затем вернем
этот любимый здесь, так что мы скажем, затем любимый возврат и код статуса.
Это изменение, которое мы должны внести.
Если вы уже реализовали это в своем избранном,
вам не нужно вносить это изменение.
Но то, что мы делаем, это всякий раз, когда мы вносим изменения в избранное,
мы заполняем информацию о пользователе и блюдах, а затем возвращаем это значение,
потому что наш клиент React ожидает, что это будет там.
Теперь, такого же рода изменения,
нам нужно будет сделать переменную b, сохранить изменения.
Поэтому в сообщении здесь
мы внесем изменения в это,
поэтому мы скажем favorites.save, а затем сделаем favorites.findByID и внесем это изменение.
Аналогично, под номером блюда,
также в посте,
вы будете аналогичным образом, всякий раз, когда вы вносите изменения в избранное,
сначала будете искать его, а затем заполнять как пользователя, так и блюда, а затем возвращать его,
а затем аналогично в другой части.
Итак, вы, должно быть, реализовали это в своем четвертом задании.
Таким образом, внесите это дополнительное изменение, где вы будете заполнять
пользователя и блюда, прежде чем вы вернете значение.
Также с удалением
мы сделаем те же изменения здесь.
Итак, вы заметили, что в удалении
я уже внес это изменение здесь.
Таким образом, после того, как мы сохраним изменения в избранное,
мы будем искать избранное, а затем
вернемся после заполнения как пользователя, так и блюд и избранного.
Это то, что ожидает от нас наш клиент React.
Таким образом, даже для удаления,
мы сделаем те же изменения.
Теперь, с этим, мой любимый маршрутизатор обновляется,
поэтому мы перейдем к обновлению users.js.
Наконец, мы обновим файл users.js.
Теперь, в файле users.js нам нужно добавить в
другое поле router.options здесь,
потому что иногда почтовый запрос, как вы видели
с логином, отправит параметры сначала проверить,
особенно с автомобилями, будет ли почтовый запрос разрешен.
Вот почему мы проверим курс с вариантами здесь, а затем
просто вернем
сообщение
о состоянии 200 в ответ на это.
Для любой конечной точки под пользователями, если мы получим параметры,
мы просто вернем статус 200 здесь.
Теперь функция входа, которую мы реализовали ранее,
мы просто сделали pasport.authenticate
local здесь и мы проверили для оставшихся значений здесь.
Теперь этот pasport.authenticate локальный,
если пользователь не проходит проверку подлинности,
он просто возвращает несанкционированный в ответном сообщении.
Теперь это может быть не очень значимым для клиентской стороны, чтобы отобразить эту информацию,
поэтому мы улучшим
этот метод входа в систему маршрутизатора
так, что аутентификация будет возвращать более значимую информацию на данном этапе.
Поэтому для этого
мы не будем делать паспорт.authenticate здесь,
вместо этого мы возьмем.
Итак, позвольте мне удалить это оттуда, а затем вы увидите,
как я обновлю сообщение маршрутизатора здесь.
Итак, мы увидим курс с опциями, а затем мы включим req,
res и следующий здесь.
Внутри этого req, res и далее здесь,
passport.authenticate назовет это с локальным.
Теперь, когда мы вызываем это с помощью локального,
если происходит ошибка аутентификации,
passport.authenticate может быть сделан для возврата
значения ошибки, а также он вернет пользователя, если
нет ошибки и третий параметр, называемый info,
который будет нести дополнительную информацию, которая может быть проанализирована обратно пользователя.
Эта ошибка будет возвращена при наличии
подлинной ошибки, которая возникает в паспорте.authenticate.
Но если информация пользователя
отправляется в passport.authenticate, но пользователь не существует,
то это не считается ошибкой.
Вместо этого он будет считаться, как пользователь не существует
, и эта информация анализируется обратно в инфо-объекте, который входит.
Таким образом, ошибка будет возвращена при возникновении
подлинной ошибки, которая возникает во время процесса аутентификации,
но информация будет содержать информацию, если пользователь не существует.
Таким образом, passport.authenticate передает обратно сообщение
о том, что пользователь не существует или либо имя пользователя
неверно, либо пароль неверный и так далее.
Таким образом, эта информация будет передана в информационном сообщении.
Теперь мы увидим, как это полезно для
нас, когда посмотрим на клиентскую сторону немного позже.
Таким образом, в этой ситуации
мы будем обрабатывать это следующим образом,
и не только, что, когда мы вызываем этот паспорт.authenticate,
нам также нужно передать в req
, res, далее как три параметра к нему.
Итак, это структура, когда вам нужно вызвать pasport.authenticate и ожидать, что он
передаст вам такую информацию, как метод обратного вызова здесь,
поэтому вам также нужно предоставить этот req, res,
следующий прямо там.
Теперь, если это происходит,
поэтому мы скажем, если ошибка,
так что если есть ошибка, которая возникает,
мы скажем, вернем следующий ошибку, а затем пусть
обработчик ошибок нашего экспресс-маршрутизатора и позаботимся об этом.
Теперь рассмотрим другие ситуации, если не пользователь.
Итак, если мы достигли этого момента,
то это означает, что это не ошибка, которая произошла,
но вместо этого, возможно, пользователь не может быть найден.
Если пользователь не найден,
то пользователь здесь будет установлен в null в этом случае.
Таким образом, в этой ситуации,
если пользователь не существует,
нам нужно иметь возможность передавать информацию обратно на сторону сервера.
Итак, что мы будем делать, так это мы передадим эту информацию в таком формате.
Итак, я собираюсь вырезать это отсюда, а
затем вставить его сюда, а затем мы отредактируем это.
Итак, если пользователь равен нулю,
то мы отправим обратно код состояния как 401, что означает
несанкционированный, а затем мы отправим обратно информацию об успехе false,
и тогда мы не будем передавать токен,
мы передадим обратно сообщение о состоянии.
Итак, здесь мы скажем
«Вход неудачно», а затем третья информация,
мы передадим эту информацию, что объект, который мы получили здесь в качестве
третьей части в ответном сообщении, которое мы отправляем обратно с нашего сервера здесь.
Таким образом, флаг успеха будет установлен в false,
статус будет установлен Login Unsuccess, а
информация об ошибке, передаваемая в информации, будет передана обратно.
Теперь обратите внимание, что эта ситуация будет происходить, если
либо имя пользователя и пароль неверны,
и поэтому это не ошибка в смысле ошибки, но тот факт, что
аутентификация не может найти ни пользователя, ни пароль пользователя является неправильным.
Таким образом, эта информация будет закодирована в информацию, которая приходит, и так, что я
передам обратно как ошибку на мою клиентскую сторону.
В противном случае часть
обрабатывается как req.login.
Итак, если это успешно,
passport.authenticate мы добавим этот метод req.login пользователю.
Таким образом, на данный момент,
мы просто передадим в объект пользователя, который мы получили.
Итак, если мы достигли этой точки,
то это означает, что объект пользователя не является нулевым и также не произошло ошибки,
так что это означает, что пользователь может войти в систему.
Итак, мы скажем err,
мы попытаемся войти в систему пользователя.
Итак, мы скажем, если ошибка, а
затем мы передадим обратно ту же информацию об ошибках, что мы сделали здесь.
Так что в этом случае, если ошибка,
то мы передадим код состояния как 401 и мы скажем, успех
является ложным и статус как Логин Неуспешно,
а затем информацию об ошибке,
вместо информации,
мы передадим в «Не удалось войти в систему пользователя».
Таким образом, это сообщение, которое мы передадим обратно здесь, если произойдет ошибка.
В противном случае, мы были бы внизу.
Таким образом, на данный момент
мы сможем сгенерировать токен.
Итак, если мы дошли до этого момента, это
означает, что пользователь успешно вошел в систему,
и поэтому теперь мы можем сгенерировать токен.
Итак, мы будем генерировать токен на основе идентификатора пользователя,
а затем мы передадим токен обратно пользователю.
Итак, здесь мы скажем токен var,
а затем мы можем сказать res.statusCode 200, а затем res.json успех true,
поэтому, что означает, что пользователь успешно вошел в систему.
Таким образом, статус будет успешным.
Затем третья часть,
вместо ошибки,
я передам токен обратно пользователю.
Итак, мы скажем токен,
этот токен, который мы только что получили ранее.
Таким образом, этот токен будет передан в качестве свойства токена ответного сообщения.
Итак, здесь, обратите внимание, что успех установлен в true, поэтому,
что означает, что пользователь успешно вошел в систему,
и поэтому пользователь может продолжить дальше на этом этапе.
Это должно быть сделано внутри req.Login здесь.
Итак, на этом этапе
мы закроем req.Login.
Итак, обратите внимание, что это внутри этого req.Login здесь.
Итак, там, мы передадим эти трое назад.
Итак, позвольте мне просто отстукнуть эти три строки.
Таким образом, мы будем обрабатывать метод регистрации пользователя.
Итак, опять же, просмотрев этот код еще раз.
Итак, мы сделаем сообщение маршрутизатора,
но вместо того, чтобы аутентифицировать паспорт прямо там,
мы скажем req, res
, next, а затем внутри,
мы проведем аутентификацию для локального,
и эта аутентификация пройдет обратно.
Таким образом, мы можем предоставить функцию обратного вызова,
и эта функция обратного вызова вернет либо ошибку,
пользователя, либо информацию здесь.
Итак, если это ошибка,
мы просто позволим обработчику экспресс-ошибок позаботиться об этом.
Если пользователь имеет значение null,
то это означает, что вход пользователя был неудачным,
и причина этого будет в информации.
Таким образом, это будет передаваться в качестве информационной ошибки в ответном сообщении здесь.
Если мы подойдем к этому моменту,
то пользователь успешно проверен.
Итак, тогда мы войдем в систему пользователя.
Итак, паспорт аутентифицировать,
мы добавим в этот метод под названием login в req, сообщение запроса.
Таким образом, мы можем вызвать логин с пользователем.
Если это возвращает ошибку,
то мы вернем ошибку здесь соответствующим образом.
Если нет, то мы достигнем точки, где пользователь успешно аутентифицирован.
Таким образом, мы можем сгенерировать JSON Web Token здесь, а затем вернуть
JSON Web Token пользователю, чтобы подтвердить, что пользователь успешно вошел в систему.
Итак, это набор шагов, которые мы будем использовать здесь.
Теперь причина, по которой я делаю более сложный способ обработки, заключается в том, что
я хочу различать ситуацию, когда
происходит подлинная ошибка во время процесса аутентификации, в отличие от ситуации,
когда имя пользователя недопустимо или пароль недействителен.
Таким образом, эти два дела будут обрабатываться этой ситуацией,
когда информация будет нести информацию обратно к нам.
Таким образом, это не ошибка само по себе,
но это ситуация, когда пользователь
не является действительным пользователем или пароль пользователя недействителен.
Таким образом, мы будем обрабатывать процесс входа пользователя в систему.
Кроме того, я добавлю
еще один метод здесь под названием CheckJwtToken.
Вполне возможно, что, хотя клиент вошел в систему и получил веб-токен JSON
, через некоторое время срок действия веб-токена JSON может истечь.
Таким образом, если пользователь пытается получить доступ с клиентской стороны с истекшим токеном
к серверу, сервер не сможет аутентифицировать пользователя.
Таким образом, через периодические интервалы,
мы можем захотеть перекрестную проверку, чтобы убедиться, что JSON Web Token по-прежнему действителен.
Итак, именно по этой причине я включаю это,
другую конечную точку под названием CheckJwtToken.
Итак, если вы получите CheckJwtToken,
включив токен в заголовок авторизации,
то этот вызов вернет true или false,
чтобы указать вам, остается ли JSON Web Token действительным или нет.
Если он недействителен, то клиентская сторона может инициировать другой логин для
пользователя, чтобы получить новый JSON Web Token, если это необходимо.
Итак, чтобы сделать это,
мы скажем Cors.CorsWithOptions и req,
res здесь, как ожидалось.
Здесь мы скажем,
паспорт аутентифицировать jwt
и session: false,
и это вернет ошибку, пользователя, информацию.
Итак, вспомните, как мы используем паспорт аутентифицировать ранее.
Итак, мы вызываем JWT с сеансом false здесь.
Итак, ранее здесь мы говорим, что паспорт аутентифицирует местный.
Таким образом, это для локальной аутентификации.
Таким образом, это для проверки подлинности JSON Web Token.
Итак, когда мы вызываем это,
то, поскольку это собирается проверить JSON Web Token, поэтому мы скажем,
если ошибка вернет следующий ошибку,
а затем пусть обработчик экспресс-ошибок позаботится об этой ситуации.
Затем мы скажем, если не пользователь,
если пользователь не существует, то аналогично иначе.
Таким образом, это означает, что если объект пользователя был
найден из JSON Web Token, а затем загружен в req.user,
то это означает, что пользователь является действительным пользователем,
и поэтому ему может быть разрешено продолжать.
В противном случае, мы собираемся сказать, что пользователь не существует.
Итак, нам нужно сообщить, что срок действия JSON Web Token истек.
Итак, на данный момент
мы отправим res
с кодом состояния 401.
Итак, несанкционированный, SetHeader, Content-Type,
приложение/json, а затем мы вернем res.
Res.json скажет статус JWT
недействительным, а затем
мы вернем флаг под названием success falls, а затем
мы вернем информацию, которую мы получаем, если пользователь
не аутентифицирован как ошибка на этом этапе.
В противном случае, это означает, что мы достигли этой точки,
то пользователь является действительным пользователем.
Итак, в этом случае
позвольте мне просто скопировать этот код здесь,
мы отправим код состояния 200, а затем res.json,
отправит JWT действительный и успешный, истинный.
Третья часть, мы отправим информацию о пользователе.
Таким образом, когда эта конечная точка вызывается с помощью метода get,
это проверит, является ли токен действительным или нет.
Если токен действителен,
то вы получите этот ответ и из флага успеха в ответе,
вы можете проверить, является ли jsonwebtoken действительным или нет.
Это полезно на стороне клиента.
Теперь, этот паспорт аутентифицировать здесь должен быть
снабжен req и res в качестве двух параметров здесь.
Так мы называем паспорт аутентифицированным.
Итак, обратите внимание, что всякий раз, когда вы
вызываете паспорт аутентифицировать и
ожидаете, что эта функция обратного вызова здесь, вам нужно добавить к этому пункту req.res, чтобы паспорт аутентифицировался здесь.
В нашем остальном API сервере
мы реализовали наши комментарии таким образом, что комментарии
формировали вложенные документы внутри документа dishe,
поэтому они покупают каждое блюдо прилагают свой собственный набор комментариев.
Но то, как мы реализовали наш клиент React, заключается
в том, что комментарии хранятся независимо от блюд,
а сами комментарии несли соответствующий идентификатор блюда.
Теперь это два разных способа
реализации на стороне сервера, а также на стороне клиента.
В угловом приложении, которое мы реализованы в нашей угловой специализации,
мы использовали метод поддокумента для
обработки комментариев в нашем угловом клиентском приложении.
Таким образом, оставшийся сервер API был
реализован таким образом, что он был более подходящим для клиента Angular.
Но для клиентов React, так как мы сохранили комментарии независимо от блюд,
а затем используем идентификатор блюда внутри комментария,
поэтому нам нужно реструктурировать наш сервер API отдыха,
так что у нас есть отдельная конечная точка комментария, независимая от конечной точки блюд.
Таким образом, нам нужно реструктурировать наш код на сервере,
чтобы ввести конечную точку /comments REST API на этом этапе.
Итак, чтобы сделать это,
давайте продолжим и реализуем новую модель под названием comment.js.
Итак, перейдя в модели,
позвольте мне реализовать новый файл с именем comments.js.
В файле comments.js
мы собираемся переместить CommentSchema из
файла dishes.js в файл comments.js, а затем удалить его полностью из файла dishes.js.
Но прежде чем мы это сделаем,
нам нужно скопировать мангуст и схему отсюда,
поэтому позвольте мне просто скопировать это из dishes.js в comment.js.
После этого, перейдя в dishes.js,
позвольте мне полностью вырезать эту CommentSchema отсюда,
потому что мы будем иметь это отдельно в модели комментариев здесь.
Итак, давайте переместим это в модель комментариев, а затем вставьте его сюда.
Но, конечно, это не полный,
мы собираемся немного обновить CommentSchema.
Но прежде чем мы это сделаем,
вернитесь в файл dishes.js и в файле блюд,
мы удалим комментарии из DishessChema,
потому что мы будем хранить содержимое отдельно от
блюд в этой версии нашего сервера.
Итак, вот как мы обновим модель посуды здесь.
Итак, мы полностью удалили комментарии из модели посуды здесь.
Перейдя в модель комментариев,
поэтому теперь мы видим, что у нас есть CommentSchema, реализованная здесь.
Но кроме того, в комментариях SSCHEMA
теперь нужно явно указать
на конкретное блюдо, для которого этот комментарий является соответствующим комментарием.
Вот где
наше население мангуста и
то, как мы храним идентификаторы объектов приходит нам на помощь.
Итак, мы будем обновлять CommentSchema, говоря, что у нас будет рейтинг
, комментарий и автор здесь.
В дополнение к автору,
мы представим еще одно поле, называемое как блюдо здесь, которое имеет
тип: Mongoose.Schema Types.ObjectID,
и поэтому это будет ссылаться на блюдо здесь.
Таким образом, это будет объектная ссылка на модель тарелки здесь,
и поэтому с этой модификацией теперь
наши комментарии будут содержать поле рейтинга, поле комментария,
автор, который снова является ссылкой на соответствующего пользователя,
а затем поле тарелки, которое является ссылкой на соответствующий блюдо здесь.
Итак, что означает, что теперь нам нужно будет
заполнить комментарии как автором, так и полем блюда.
Как только мы закончим это,
то мы скажем var Comments
mongoose.model, и мы назовем это «
Comment», а затем это использует CommentSchema, что мы только что определили здесь,
а затем нам нужно экспортировать это отсюда,
comments.model отсюда.
Итак, теперь, когда мы ввели comments.model,
то мы продолжим, а затем представим новый маршрутизатор под названием CommentRouter.
Итак, чтобы ввести маршрутизатор комментариев,
давайте перейдем к маршрутам здесь,
а затем создадим новый файл с именем commentRouter.js.
В commentRouter.js позвольте мне скопировать несколько вещей
из DishRouter.
Итак, у нас будут эти комментарии здесь,
поэтому позвольте мне скопировать эти вещи из, а также,
пока я на нем, позвольте мне просто скопировать их также до этого момента,
а затем я обновлю это немного позже.
Итак, перейдя в CommentRouter,
нам нужны все эти части,
поэтому мы скажем Com, Express, BodyParser, mangoose
, аутентифицировать, Cors, а затем мы
будем импортировать комментарии из модели/комментариев.
Тогда мы назовем это как комментарий Router, который является Express.Router здесь.
Затем мы скажем, CommentRouter использует BodyParser,
а затем это теперь станет маршрутом CommentRouter.
Теперь нам нужно зайти в DishRouter, а затем
удалить все части, которые относятся к комментариям здесь.
Итак, позвольте мне просто вырезать эту часть, а затем мы повторно используем их для нашего комментария Router.
Таким образом, все это больше не нужно в DishRouter.
Итак, я собираюсь удалить все это из DishRouter здесь,
так что позвольте мне вырезать их,
все, что связано с маршрутом комментариев от DishRouter,
затем мы войдем в CommentRouter,
а затем позвольте мне пойти вперед и вставить это на место здесь,
затем мы отредактируем это здесь.
После этого нам нужно экспортировать CommentRouter.
Итак, будет экспортировать CommentRouter для нас.
Но, конечно, этот код не совсем точен.
Итак, нам нужно идти дальше и исправить этот код здесь.
Итак, для этого кода
мы теперь понимаем, что это не маршрут DishRouter,
вместо этого он должен быть
/конечной точкой, потому что мы
собираемся монтировать это в конечной точке /comments здесь.
Итак, мы скажем CommentRouter,
а затем параметры CorsWithOptions (req,
res), которые остаются такими,
а затем получить cors.cors, а затем req.res,
а затем этот станет комментариями.
Найди ID, req.
Таким образом, это будут comments.Find
и req.query здесь.
Итак, когда комментарии будут найдены,
то, в этот момент,
мы будем заполнять автора,
уже есть, заполнять здесь.
Итак, я просто удалю этот comments.author, а затем
мы просто заполним автора здесь.
Тогда это даст нам комментарии здесь.
Тогда, скажем, это можно значительно упростить.
Таким образом, ошибка catch все равно есть.
Итак, когда комментарий придет, он просто вернется.
Извини, это должно быть.
Итак, если для получения,
когда мы получим комментарии,
comments.Find req.query, .populate автора здесь
, а затем, мы скажем,
.then комментарии, а затем, мы скажем, res.statusCode 200, SetHeader, а затем, мы вернем комментарии отсюда,
res.json комментарии отсюда.
Теперь я не заполняю блюда здесь, потому что мне явно не нужны
блюда так, как я использую эту информацию в своем ответном клиенте.
Мне нужен только идентификатор блюда,
и идентификатор блюда уже присутствует там,
и это достаточно хорошо для меня, чтобы использовать эти данные в моем ответном клиенте.
Так что, я оставлю его там как таковой.
Я собираюсь заполнить
информацию об авторе там, потому что нам нужна полная информация об авторе
всякий раз, когда мы создаем элемент комментария в нашем ответном клиенте.
Таким образом, get будет обновляться вот так.
Для сообщения CorsWithOptions
мы скажем, Authenticate.verifyUser req, res, далее.
Очевидно, что для публикации комментария
вам нужно, чтобы автор был действительным зарегистрированным пользователем.
Только тогда вы разрешите пользователю опубликовать комментарий.
Затем сам комментарий приходит в тело входящего сообщения запроса.
Итак, сначала мы проверим тело
, чтобы убедиться, что комментарий включен в тело здесь.
Итак, здесь я собираюсь удалить все эти части, а затем,
упростить его дальше, а затем,
мы правильно реализуем это там.
Итак, прямо в этот момент, мы скажем,
если req.body не равен нулю,
так что это означает, что есть комментарий, который заключен внутри тела.
Итак, позвольте мне сократить это и переместить это в часть if здесь,
а затем, мы отредактируем это здесь.
Итак, если тело не существует,
то мы вызовем ошибку.
Итак, скажем, ошибка новой ошибки,
комментарий не найден в теле запроса.
Итак, мы поднимем эту ошибку здесь.
Состояние ошибки 404.
Затем, скажем, верните следующую ошибку.
Итак, давайте рассмотрим часть ошибки здесь, если тело
не содержит соответствующей информации комментария.
Если он содержит, то, конечно,
то, что мы будем делать дальше,
мы скажем, req.body.author является req.user. _id.
Причина, по которой мы это делаем, заключается в том, что мы напоминаем, что если это
зарегистрированный пользователь и пользователь вошел в систему,
то req.user будет содержать информацию о пользователе.
Итак, мне нужен только идентификатор текущего зарегистрированного пользователя.
Итак, скажем, req.user. _id, а затем,
мы установим req.body.author в req.user. _id.
Теперь пользователь verify автоматически гарантирует, что если вы приземлитесь в этот момент,
то, очевидно, у вас будет пользователь, который правильно вошел в систему.
В противном случае это уже вызвало бы проблему там.
Таким образом, когда вы достигнете в этот момент,
у вас будет действительный пользователь, который уже вошел в систему там.
Итак, это то, где вы сможете сейчас.
Итак, то, что мы делаем, это то, что поле автора,
мы явно устанавливаем его в идентификатор пользователя здесь, так что
req.body содержит остальные части комментария.
Итак, как вы понимаете, комментарий содержит рейтинг,
сам комментарий, и автор, и поля блюда.
Таким образом, остальные части должны были быть заполнены пользователем.
Рейтинг, комментарий
и информация о блюде уже должны быть заполнены
в теле входящего сообщения запроса.
Авторская часть оставлена там незаполненной,
которую мы будем явно вставлять в этот момент в тело здесь.
Итак, теперь req.body будет содержать всю информацию о комментариях.
Итак, на данный момент,
вместо того, чтобы делать это, скажем, comments.create.
Используя req.body, мы создадим комментарии здесь.
Затем это вернет
комментарий, соответствующий комментарию, который мы только что вставили здесь.
Теперь, как только комментарий вернулся,
то мы должны сделать comments.findByID.
Причина, по которой мы должны это сделать, заключается в том, что нам
нужно заполнить здесь информацию об авторе.
Итак, скажем, FindByID комментарии. _id,
а затем, мы заполним информацию об авторе в сам комментарий.
Тогда, скажем, потом комментируем.
Теперь, очевидно, здесь вы обнаружите, что комментарий будет
существовать, потому что мы только что вставили этот комментарий на место.
Итак, здесь мы просто вернем, res.statusCode - 200,
res.SetHeader - Content-Type, application/json.
Сам комментарий скажет res.json, а затем
вернет комментарий в этот момент.
Таким образом, мы будем обрабатывать вставку
нового комментария в нашу клиентскую сторону здесь.
Для пута, как вы понимаете,
вы не сможете сделать ставку на конечные точки /comments/.
Итак, скажем, операция PUT не поддерживается в конечной точке /comments/.
В этом и смысл. Это сообщение, которое ты вернёшь.
Таким образом, StatusCode равен 403,
а затем операция PUT не поддерживается /comments s/.
Теперь, когда мы сделаем удаление,
позвольте мне просто вырезать это отсюда, а затем, скажем,
comments.Remove.
написано пустым. Таким образом, когда вы делаете удаление в конечной точке комментариев косой черты,
вы удалите все комментарии из вашей системы.
Итак, это очень опасная операция, и поэтому
вы не должны делать это нормально.
Таким образом, мы разрешаем только администратору выполнять такую операцию.
Итак, мы удалим все комментарии оттуда.
Итак, когда вы получите ответ,
мы скажем res.StatusCode 200.
Так что, позвольте мне просто скопировать эти части здесь,
а затем приехать и вставить их сюда.
Итак, скажем, comments.remove.
Затем ответ res.statusCode 200 приложение json, а затем res.json (ответ) здесь.
Итак, вот как мы обрабатываем удаление.
Операция удаления в конечной точке комментариев косой черты.
Теперь следующим маршрутом является маршрутизатор комментариев.
Итак, здесь мы скажем commentRouter.Route и
конечной точкой здесь будет косая черта CommentID.
Таким образом, здесь варианты останутся как таковые.
Затем для получения на текущем маршрутизаторе,
для получения мы скажем, comments.findByID (req.params.
Это было бы CommentId.
Итак, как только мы найдем конкретный комментарий,
тогда мы заполним только автора оттуда.
Затем, как только вы заполняете автора,
тогда мы скажем, затем прокомментируем.
Теперь, вся эта часть здесь не нужна,
так что я просто удалю часть.
Это также не подходящая вещь здесь.
Итак, позвольте мне переименовать код.
Итак, мы скажем для получения comments.findByID,
затем заполните автора,
затем прокомментируйте, res.StatusCode 200, SetHeader.
Тогда остальные - JSON.
Мы просто вернем комментарии здесь.
Итак, мы будем возвращать комментарий в этот момент, res.json (comment).
Вы найдете конкретный комментарий,
а затем верните этот комментарий для сообщения.
Для пост-операции, как вы понимаете,
пост-операция не
допускается в комментариях CommentID.
Таким образом, это сообщение, которое мы отправим,
операция POST не поддерживается в комментариях косой черты CommentID.
Итак, это сообщение, которое мы скажем для пута.
Теперь, для положить, мы скажем comments.Find где Id (req.params.commentid).
Итак, мы найдем комментарий там,
и там комментарий, так для пута.
Итак, мы найдем комментарий там,
а затем мы скажем для комментариев.
Итак, если мы найдем комментарий,
если комментарий не является нулевым,
то мы также проверим, comment.author.
Если нет, comment.arthur равно (req.user. _id).
Итак, мы проводим перекрестную проверку, чтобы убедиться, что
comments.author тот же, что и текущий пользователь.
Только текущий пользователь, который вошел в систему - если пользователь тот же, что и автор комментариев,
то пользователю будет разрешено обновлять.
Итак, это первое, что мы проверим.
Итак, комментарии, затем comments.author.equal rec.user. _id.
Если нет, то вы скажете, что не уполномочены обновлять этот комментарий.
Как вы видите .403,
а затем верните следующую ошибку здесь.
Таким образом, мы создадим ошибку там.
Затем после этого мы скажем
req.body.author, req.user. -
Это важно.
Теперь эти два не нужны здесь,
потому что мы напрямую сохраняем комментарий.
Затем таблетки, мы будем говорить comments.Findbyidandupdate,
и req.params.commentid.
Итак, мы найдем этот конкретный комментарий,
потому что нам уже предоставлен идентификатор комментария.
Итак, мы будем делать комментарии findByID req.params.commentid.
Тогда мы скажем тогда (комментарий).
Когда вы предоставляете req.params.commentID,
мы должны явно указать второй параметр,
который мы хотим изменить.
Итак, скажем $ set: req.body.
Итак, второй параметр, по существу,
говорит вам, какую часть вы меняете.
Теперь, так как нам было предоставлено тело, содержащее обновленный комментарий,
мы просто собираемся обновить сам комментарий.
Тогда другая часть, о которой мы попросим, новая: правда.
Таким образом, это гарантирует, что обновленный комментарий будет возвращен
в логове этого вызова comments.findbyidandUpdate.
Итак, мы скажем тогда комментарии.
Когда этот комментарий будет возвращен,
мы скажем comments.findByID (комментарий. _id).
Затем заполняйте автора там.
Мы заполним автора там,
а потом скажем, комментарий.
Итак, вы видите, что мы получим комментарий, а затем вернем комментарий в этот момент.
Итак, вот как мы будем обновлять комментарий.
Таким образом, это ситуация, когда комментарий не является нулевым.
Таким образом, это утверждение if для комментария не является нулевым.
Итак, else если часть,
теперь это не применимо,
так что скажем иначе, ошибка.
Ошибка в этом случае.
Итак, если комментарий имеет значение null, это
означает, что мы не нашли комментарий в нем,
поэтому вы не можете изменить несуществующий комментарий.
Таким образом, мы скажем err,
новый комментарий об ошибке req.params.CommentID не найден, а затем мы вернем ошибку.
Итак, вот как мы будем обрабатывать поставленную часть нашего комментария здесь,
а затем, наконец, удаление.
Для удаления снова мы должны сначала найти
comments.findByID (req.params.commentID),
а затем прокомментировать.
Итак, мы будем искать комментарий.
Итак, сначала проверим, не равен ли комментарий нулю.
Это важно проверить здесь.
Затем следующая часть, которую мы проверим, является ли comment.author равным req.user. _id.
Мы убедитесь, что этот пользователь, который пытается удалить
этот комментарий, является тем же пользователем, который вставил комментарий в первую очередь.
Если нет, то если это ситуация,
то вы увидите «Вы не уполномочены удалять этот комментарий!»
А потом верните статус там.
Затем внизу здесь
мы скажем comments.FindByidandRemove здесь.
Итак, мы скажем comments.findByidAndRemove (req.params.commentid),
тогда мы получим некоторый ответ от комментария.
Итак, на данный момент
мы просто скажем, res.statusCode.
Таким образом, мы скажем comments.findByidAndRemove, затем ответ.
Если он правильно удален,
мы скажем 200, а затем res.json
ответ здесь, и мы также поймаем ошибку на этом этапе.
Итак, позвольте мне просто скопировать это здесь, а затем мы включим уловы ошибки в данный момент.
Итак, это первое, что мы проверим.
Мы гарантируем, что комментарий не равен нулю.
В противном случае, так что это другая часть.
Таким образом, это еще часть ошибки if else
новый комментарий req.params.commentID не найден, а затем
404 и отправить часть else для нас, а затем часть будет обрабатываться соответствующим образом.
Итак, это изменения, которые мы вносим для маршрутизатора комментариев здесь.
Итак, мы обрабатываем сообщение get put и delete для
комментариев косой черты и точки косой черты commentID воздействия.
Поэтому, как только мы завершим это,
нам нужно включить это в файл app.js.
Итак, мы перейдем в файл app.js, а затем скажем,
var commentRouter
требует маршрутов/commentRouter.
Итак, у нас есть маршрутизатор комментариев здесь, а затем мы
спустимся в файл app.js ниже здесь, а
затем мы скажем app.use
косой черты комментарии, commentRouter здесь.
Вот оно. Итак,
мой маршрутизатор комментариев готов.
Итак, давайте продолжим и сохраним все изменения.
Затем наш сервер теперь обновляется,
чтобы обрабатывать все запросы от наших клиентов React здесь.
Теперь, если вы хотите сделать альтернативный способ, то есть
у вас есть свои комментарии в качестве поддокументов вашего блюда, а затем вы хотите справиться с этим,
вам нужно будет обновить клиент React,
чтобы иметь возможность использовать комментарии из каждого блюда соответствующим образом.
Это останется для вас в качестве упражнения.
Подумайте о том, как вы бы спроектировали свой реагирующий клиент таким образом, чтобы он
работал очень хорошо с более ранней версией
сервера, который имел комментарии в качестве поддокументов ваших блюд.
Теперь, это будет интересный способ его реализации.
Конечно, это немного сложнее, чем то, как мы
реализовали клиент React, где мы сохранили комментарии независимо от
блюд, но затем дополнительная работа является ответственностью
клиента, потому что вам нужно выбрать
соответствующие комментарии, когда вы показываете специфическое блюдо.
Вам нужно выбрать комментарии из всех комментариев здесь.
Таким образом, это еще одна работа, которую делает наш клиент React из-за
того, что мы отделяли комментарии от самих блюд.
Аналогичным образом, если вы можете изменить дизайн вашего углового клиента, чтобы иметь возможность
иметь дело с ситуацией, когда комментарии хранятся независимо от ваших блюд.
Итак, это все упражнения, которые вы можете сделать, чтобы увидеть, как вы можете
расширить свои клиентские приложения для обработки любого типа серверов,
двух различных типов серверов там.
Таким образом, с этим мы завершаем обновление на наш сервер здесь.
Таким образом, с этим мы обновили все на стороне сервера.
Итак, давайте сохраним все изменения на стороне сервера.
Теперь наш сервер готов обрабатывать входящие запросы от нашего клиента React.
С этим мы завершаем это упражнение.
В этом упражнении мы подготовили наш экспресс-сервер
для обработки входящих запросов от нашего клиента React.
В следующем упражнении мы рассмотрим
реагирующий клиент более подробно, чтобы понять, как он взаимодействует с этим дополнительным сервером.
Это хорошее время для вас, чтобы сделать
покрытие git с сообщением, интегрирующим клиент и сервер.