Совершенно не факт. Нужно тестирование проводить. Хотя вряд ли разница будет ощутимая. Но есть разница в восприятии и объеме кодовой базы.
Если правильно понимаю - и по времени быстрее должно работать?
Очень интересный урок, который хотелось бы обсудить... К своему удивлению, я не нашел здесь во всех уроках по Javascript уроков, касающихся методов типа Array.find(), Array.filter(), Array.findIndex() и т.п. При этом это очень полезные методы, используемые чуть ли не каждый день. И на мой взгляд они, во-первых, более короткие, чем конструкции типа for(...), а во-вторых, более логичны в плане восприятия.
Сразу отмечу, что я не хочу сказать, что другие решают не правильно. Я просто хочу показать другие варианты.
Сравним код большинства ответов в этой задаче:
function lookUpProfile(name, prop){
// Only change code below this line
for (let i = 0; i < contacts.length; i++){
if (contacts[i].firstName === name){
if (contacts[i][prop]){
return contacts[i][prop];
}
return "No such property";
}
}
return "No such contact";
// Only change code above this line
}
и одно из моих решений:
function lookUpProfile(name, prop) {
// Only change code below this line
const item = contacts.find(n => n.firstName === name);
if (item) {
if (item[prop] === undefined) {
return 'No such property';
}
return item[prop];
}
else {
return 'No such contact';
}
// Only change code above this line
}
Какое решение вам кажется более наглядным?
Как мне кажется, вариант с перечислением for (let i = 0; i < contacts.length; i++) более громоздкий и в нем больше отвлекающих переменных. То есть мы создаем переменную-счетчик i, сравниваем ее со значением длины массива, каждую итерацию увеличиваем ее значение, используем для получения элемента массива и т.п., и все это вместо того, чтобы работать просто с массивом и его элементами.
В моем варианте используется метод массива find(condition). Уточню, что прототипом всех массивов является Array. Соответственно, все методы его наследуются и конечным массивам. Метод find(condition) принимает в качестве параметра функцию, используемую для поиска элемента в текущем массиве (первого, удовлетворяющего условию). То есть массив перечисляет все свои элементы до тех пор, пока применяемая к ним функция не вернет истину (или то, что может быть преобразовано в логическое true). В моем случае это n => n.firstName === name.
Для кого-то данная конструкция может быть не понятна, уточню: это стрелочная функция. Если переводить на более понятный синтаксис, то это так:
function condition (n){
return n.firstName === name;
}
Итак, применив метод Array.find() вместо перечисления for(...) я попытался найти нужный мне элемент.
const item = contacts.find(n => n.firstName === name);
В данном случае (если понять синтаксис) все сильно понятней и логичней: я выполнил метод поиска у самого массива и получил найденный элемент из него и присвоил в переменную item (или присвоил undefined, если элемент не был найден).
Далее я уже работаю с проверками на самом элементе
if (item) {
if (item[prop] === undefined) {
return 'No such property';
}
return item[prop];
}
else {
return 'No such contact';
}
То есть вроде тоже все понятно: если элемент item есть, то в нем проверяю значение, если нет, то возвращаю сообщение об ошибке. И никаких лишних i и т.п.
В погоне за сокращением можно и вовсе вот так написать:
function lookUpProfile(name, prop) {
const item = contacts.find(n => n.firstName === name);
return !item ? 'No such contact' : item[prop] || 'No such property'
}
То есть я сразу проверил есть ли объект и если нет, возвращяю 'No such contact', иначе возвращаю свойство объекта (если оно есть) или сообщение 'No such property'
Да, такой стиль может показаться более сложным и запутанным, но сейчас чаще именно так и пишут, потому что меньше кода - меньше над чем думать приходится.
Понял, спасибо! Ковыряю дальше)
Дима, в целом правильно, но очередность чуть другая. Надо так:
3. Сюда https://github.com/prisma-cms/nextjs-nexus/tree/master/server/nexus/types надо добавить описание таблицы для nexus, который проверяет соответствие типов полей в gql
4. Сюда https://github.com/prisma-cms/nextjs-nexus/tree/master/src/gql добавляем .graphql для новой таблицы
Судя по всему, ты думаешь, что сначала должно что-то появиться в /src/gql и только потом уже можно добавлять что-то в типы /server/nexus/types. Это не так. Если разбирать наименование папки /server/nexus/types, то здесь types - это не тайпскриптовые типы, а графкюэльные. То есть здесь надо более хорошо прокачаться в GraphQL и понимать, что там все есть типы (даже скалярные). При этом есть типы на чтение (все типы, что мы перечисляем в теле запроса для получения данных), а есть входящие типы (input-types), это все то, что мы передаем в параметрах. Nexus - это библиотека, которая позволяет генерировать GraphQL-схему (включая типы) на основе нашего кода. Для примера
import { objectType, extendType, inputObjectType, nonNull } from 'nexus'
export const User = objectType({
name: 'User',
description: 'Пользователь',
sourceType: {
module: '@prisma/client',
export: 'User',
},
definition(t) {
t.nonNull.string('id')
t.nonNull.date('createdAt', {
description: 'Когда создан',
})
t.string('email')
t.string('fullname')
t.string('username')
t.boolean('sudo')
t.string('image', {
description: 'Avatar',
})
},
})
Таким образом мы описываем структуру GraphQL-типа User. Этот тип генерируется и попадает в server/nexus/generated/schema.graphql
Это именно та схема, которую использует GraphQL-сервер. Посмотри внимательно эту схему у себя в проекте. Если ты там не видишь того, что ожидаешь получить на фронте, то ты этого не получишь. К примеру, у меня сейчас так (помимо прочего):
"""
Пользователь
"""
type User {
"""
Когда создан
"""
createdAt: DateTime!
email: String
fullname: String
id: String!
"""
Avatar
"""
image: String
sudo: Boolean
username: String
}
То есть то, что я прописал в нексусе, попало сюда. И вот теперь этот тип я вижу и в плейграунде
Вот пока ты в GraphQL-Playground не увидишь то, что ожидаешь, на фронте ты не сможешь это получить. И лишь только тогда, когда ты там увидишь желаемое, только тогда ты можешь добавлять фронтовые файлы .graphql и выполнять yarn generate:types, а иначе ты просто будешь получать ошибку.
Николай, посмотри, пожалуйста, последовательность действий: все ли верно понял.
Для того, чтобы добавить новую таблицу:
1. Добавляем описание таблицы в prisma
2. prisma:db:push - в БД появляется новая таблица
3. Сюда https://github.com/prisma-cms/nextjs-nexus/tree/master/src/gql добавляем .graphql для новой таблицы
4. Сюда https://github.com/prisma-cms/nextjs-nexus/tree/master/server/nexus/types надо добавить описание таблицы для nexus, который проверяет соответствие типов полей в gql
5. generate:types - генерация кода
Правильно понял или что-то забыл?
-----------------------
6. Действия предыдущего поста
И еще: не забудь по завершении всего выполнить еще yarn prisma:migrate:create, чтобы сформировать новую миграцию. То, что ты обновляешь призма-схему и пушишь руками в БД - это еще не формирует скриптов миграции, которые срабатывают на yarn prisma:deploy. Этот момент тоже есть в видео.
Только тут важный момент: при создании миграции у тебя будет очищена база данных. Почему так происходит? Потому что ты уже выполнил prisma:db:push и в базе данных уже есть изменения структуры. Нельзя поверх выполнить еще такие же структурные запросы. Поэтому призма удаляет все таблицы, выполняет имеющиеся миграции и создает новую миграцию, накатывает ее и сохранят файл миграции в prisma/migrations/.
По этой причине, чтобы не потерять данные, надо делать так:
1. Прежде чем внести какие-либо структурные изменения в БД, снимаешь полный дамп базы.
2. Вносишь изменения.
3. Создаешь миграцию (данные все при этом будут потеряны).
4. Удаляешь все таблицы в базе данных.
5. Выполняешь импорт своего дампа.
6. Выполняешь yarn prisma:deploy чтобы накатить новую миграцию. При этом данные не будут потеряны, если все ОК. Если не ОК, то миграция просто не будет выполнена.
То есть в режиме разработки не редко теряется база данных при внесении изменений таким образом, но на боевую yarn prisma:deploy обычно проходит без проблем.
Спасибо, изучаю заново)
Дима, пересматривай начиная с 25 минуты минут 10-15, там все это подробно объясняется (слишком подробно и растянуто, но все же).
Уточняю в чем твоя ошибка:
>> - Добавил модель Post в schema.prisma
- выполнил prisma:db:push - получил новую таблицу в БД
Это фаза 1 (работа с базой данных).
>> - выполнил generate:types
А вот это уже фаза 3, то есть подтягивание GraphQL-API на сторону фронта и формирование методов и типов.
Ты пропустил фазу 2 - не поправил GraphQL-API. За это отвечает Nexus. То есть пока ты не обновишь схему для фронтового АПИ, ничего у тебя на фронте нового не появится. Призма - отдельно, GraphQL-API - отдельно.
Николай, всё-таки нужно подтолкнуть в верном направлении)
- Добавил модель Post в schema.prisma
- выполнил prisma:db:push - получил новую таблицу в БД
- выполнил generate:types - ошибок нет, но в папках gql в src никаких изменений нет, в api, соответственно, тоже.
Что забыл добавить ,чтобы изменения подхватились и добавились?