Добро пожаловать на наш канал, где вы сможете обнаружить обширный выбор курсов по веб-технологиям. Начиная с основ HTML и CSS, мы предлагаем полное погружение в мир веб-разработки, включая изучение продвинутых фреймворков.
кстати про защищенные авторизации очень интересно. типа шифрование данных пользователей и тд. я щас изучаю express и в проекте использую bcrypt (тоже изучаю как работает). интересно было бы узнать есть ли похожая тема у неста под капотом. ну или какие то еще реализации
Интерфейсы для ООП. Я не знаток TS, но в других языках интерфейсы это классы с методами (обычно без реализации), которые расширяют обычные классы. Таким образом объект типизируется интерфейсом, а фактически создается любой класс, который расширен интерфейсом и таким образом получаем меньшую связанность между объектами. В TS что-то типа interface Printer { print(data: string): void } class ConsolePrinter implements Printer { print(data: string): void { // Печать в консоль } } class WindowPrinter implements Printer { print(data: string): void { // Печать в окно } } const printer: Printer = ConsolePrinter() printer.print("Hello World!") А type это как структуры в C или Go, или дата-классы в Kotlin/Python.
Что значит dto с ts? При помощи class-validator и class-transformer можно гибко настраивать валидацию, а ts максимум выкинет ошибку несоответствия типов
@@hiyoutube6769Лучше сначала TS выучить хорошо, в Несте часто используются возможности именно TS, которых нет в джс и может быть трудно для понимания. И Экспресс тоже по хорошему нужно знать, т.к. внутри Неста можно обрабатывать запросы при помощи Express/Fastify
Я не знаю, но уже какого человека смотрю и все допускают одну ошибку, по умолчанию при использование fetch в next.js он будет SSG он по умолчанию использует force-cache. Маленький не дочет, но почему тут все путают? В доках написано же. А так видос хороший, для начинающих топ! В свое время мне пришлось изучать на методе проб и ошибок, такое видео бы пригодилось! :) VIDEO: 30:00 force-cache (default) - Next.js looks for a matching request in its Data Cache. If there is a match and it is fresh, it will be returned from the cache. If there is no match or a stale match, Next.js will fetch the resource from the remote server and update the cache with the downloaded resource. no-store - Next.js fetches the resource from the remote server on every request without looking in the cache, and it will not update the cache with the downloaded resource. Good to know: If you don't provide a cache option, Next.js will default to force-cache, unless a dynamic function such as cookies() is used, in which case it will default to no-store. The no-cache option behaves the same way as no-store in Next.js.
Я столько видосиков пересмотрела по этому курсу и засыпала на первых 5 минутах, так и не досматривала. Спасибо за интересный курс! Есть желание посмотреть все ваши работы
🌿Здравствуйте, спасибо как раз не мог нормально работать с middleware, теперь разбиваюсь нормально.🌿 ❓ Кстати, как вы относитесь к тому, что Next js используется как Full-stack фреймворк? 🤔 Я пробовал использовать его с MongoDB, но в итоге получился какой-то треш. Да и структура проекта выросла настолько что мне пробила крышу.
Я пробовал засовывать back-end в next и мне это очень не понравилось. Я больше люблю разделять back-end и front-end. сервер я пишу на nest js, а клиент на next. Мне так больше нравится
Очень крутое видео, однозначно лайк!! Я сам тоже пишу один сайт на нексте и у меня есть проблема, которую я давно не могу решить. Например у меня в локальном хранилище есть какое-то значение, от которого я отталкиваюсь и решаю показывать контент или нет. Проблема в том что после перезагрузки, он не сразу видит это значение в локальном хранилище из-за чего, мой сайт возвращается в исходное состояние и только потом, после того как он увидит что в локальном хранилище что-то хранится меняет. Есть ли способ пофиксить такое поведение? Все это дело происходит на клиенте с директивой use client.
А middleware можно создавать только в корне проекта или в каждой папке внутри app? Спрашиваю вот почему - если я хочу обработать разной логикой различные пути - прописать всё в одном middleware и добавить кучу if на нужный мне путь (звучит довольно громоздко). Хотелось бы это декомпозировать, есть такая возможность? Как я это вижу, разбить на несколько middleware`ов только для нужного URI соответствия
Да, можно создавать middleware не только в корне проекта, но и в каждой папке внутри app. Это позволит декомпозировать логику обработки различных путей и сделать код более модульным и масштабируемым. Можно создать отдельные middleware-файлы для каждого набора путей, которые требуют специальной обработки. Например, можно создать dashboard.middleware.ts для обработки путей, связанных с панелью управления, и auth.middleware.ts для обработки путей, связанных с аутентификацией. Чтобы использовать middleware в разных папках, можно импортировать его в файл middleware.ts в корне твоего проекта и добавить его в массив middleware: import { middleware as dashboardMiddleware } from './app/dashboard/dashboard.middleware' import { middleware as authMiddleware } from './app/auth/auth.middleware' export { default } from 'next/server' export const middleware = [ dashboardMiddleware, authMiddleware ] export const config = { matcher: [ '/dashboard/:path*', '/auth/:path*' ]
Привет! Спасибо! Отличный курс с прекрасной подачей материала! Ничего лишнего, легко слушать. Просьба, пожалуйста сделай еще видео с разработкой каких-нибудь небольших полноценных проектов на react с использованием redux toolkit, typescript, backend на node.js, БД postgresql или mongodb. Было бы классно!
