Совершенно не факт. Нужно тестирование проводить. Хотя вряд ли разница будет ощутимая. Но есть разница в восприятии и объеме кодовой базы.
Если правильно понимаю - и по времени быстрее должно работать?
Очень интересный урок, который хотелось бы обсудить... К своему удивлению, я не нашел здесь во всех уроках по Javascript уроков, касающихся методов типа Array.find(), Array.filter(), Array.findIndex() и т.п. При этом это очень полезные методы, используемые чуть ли не каждый день. И на мой взгляд они, во-первых, более короткие, чем конструкции типа for(...), а во-вторых, более логичны в плане восприятия. Сразу отмечу, что я не хочу сказать, что другие решают не правильно. Я просто хочу показать другие варианты. Сравним код большинства ответов в этой задаче: и одно из моих решений: Какое решение вам кажется более наглядным? Как мне кажется, вариант с перечислением for (let i = 0; i < contacts.length; i++) более громоздкий и в нем больше отвлекающих переменных. То есть мы создаем переменную-счетчик i, сравниваем ее со значением длины массива, каждую итерацию увеличиваем ее значение, используем для получения элемента массива и т.п., и все это вместо того, чтобы работать просто с массивом и его элементами. В моем варианте используется метод массива find(condition). Уточню, что прототипом всех массивов является Array. Соответственно, все методы его наследуются и конечным массивам. Метод find(condition) принимает в качестве параметра функцию, используемую для поиска элемента в текущем массиве (первого, удовлетворяющего условию). То есть массив перечисляет все свои элементы до тех пор, пока применяемая к ним функция не вернет истину (или то, что может быть преобразовано в логическое true). В моем случае это n => n.firstName === name. Для кого-то данная конструкция может быть не понятна, уточню: это стрелочная функция. Если переводить на более понятный синтаксис, то это так: Подробней о стрелочных функциях в этом уроке. Итак, применив метод Array.find() вместо перечисления for(...) я попытался найти нужный мне элемент. const item = contacts.find(n => n.firstName === name); В данном случае (если понять синтаксис) все сильно понятней и логичней: я выполнил метод поиска у самого массива и получил найденный элемент из него и присвоил в переменную item (или присвоил undefined, если элемент не был найден). Далее я уже работаю с проверками на самом элементе То есть вроде тоже все понятно: если элемент item есть, то в нем проверяю значение, если нет, то возвращаю сообщение об ошибке. И никаких лишних i и т.п. В погоне за сокращением можно и вовсе вот так написать: То есть я сразу проверил есть ли объект и если нет, возвращяю '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-схему (включая типы) на основе нашего кода. Для примера Таким образом мы описываем структуру GraphQL-типа User. Этот тип генерируется и попадает в server/nexus/generated/schema.graphql Это именно та схема, которую использует GraphQL-сервер. Посмотри внимательно эту схему у себя в проекте. Если ты там не видишь того, что ожидаешь получить на фронте, то ты этого не получишь. К примеру, у меня сейчас так (помимо прочего): То есть то, что я прописал в нексусе, попало сюда. И вот теперь этот тип я вижу и в плейграунде Вот пока ты в GraphQL-Playground не увидишь то, что ожидаешь, на фронте ты не сможешь это получить. И лишь только тогда, когда ты там увидишь желаемое, только тогда ты можешь добавлять фронтовые файлы .graphql и выполнять yarn generate:types, а иначе ты просто будешь получать ошибку.
Николай, посмотри, пожалуйста, последовательность действий: все ли верно понял. Для того, чтобы добавить новую таблицу: 1. Добавляем описание таблицы в prisma https://github.com/prisma-cms/nextjs-nexus/blob/ff3bea887b1cdc902ae0510534ca3927dd057d4d/prisma/schema.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, соответственно, тоже. Что забыл добавить ,чтобы изменения подхватились и добавились?