wonderingpeanut

лифтишь стейт, назовем его shouldDisplayMain в родительский компонент App, передаешь функцию изменения стейта в Verification компонент.

Внутри этого компонента сетишь shouldDisplayMain в то значение, которое тебе надо.

Внутри App делаешь {shouldDisplayMain && }

Бест практис согласно Кенту Додсу

// MyContext.js
const Context = createContext(null);

const Provider = ({children}) => {
  return (
    <Context.Provider value={/* your state */}>{children}</Context.Provider>
  )
}

const useYourValue = () => {
  const value = useContext(Context);
  if (!value) { /* handle case when context is used outside of Context provider */ }
  return value
}

export {useYourValue, Provider}

// App.js
...
return (
  <Provider>
    <ComponentA />
    {/* other components */ }
  </Provider>
);

// ComponentA.js
import {useYourValue} from '../Context'

const ComponentA = () => {
  const myValue = useYourValue();
  // rest of component code
}

1) Удалить папку .next и перезапустить дев сервер
2) Удалить папки .next, node_modules и lock файл, переустановить зависимости и запустить девсервер
3) Удалить папку с приложением и развернуть бойлерплейт заново

Одно из этого должно помочь. Скорее всего

Из других известных мне реализаций только Gatsby и vite-plugin-ssr. За gatsby ничего не могу сказать, ибо не работал. vite-plugin-ssr интересная штука, позволяет гибко управлять всем чем ты захочешь в приложении. Next.js это т.н. opionated решение, т.е. за тебя уже придумали как приложение должно быть построено.

Если сравнивать vite-plugin-ssr и Next.js, то это как arch linux (vite-plugin-ssr) и ios (next.js).

Для коммерческих проектов всегда использовал next.js, ибо проще и быстрее.
Насколько я знаю gatsby прегенерирует страницы (SSG), в то время как некст поддерживает и прегенерацию (ssg), и генерацию по запросу (ssr), и даже статичную регенераци (isr)

Каких-то особых подводных камней у некста нет.

Не вижу смысла использовать SSR для генерации статичной страницы. Поэтому я бы сказал, что getStaticProps будет лучше.

Твой вопрос можно поделить на две части (как минимум): получение файлов на клиенте через input/dropzone и отправка этих файлов на сервер.
Получение файлов на клиенте
Насчет выгрузки фото на сервер в монго - по-моему не самая лучшая затея хранить фото да и вообще медиа файлы в бд. Лучше залить их куда-нибудь в облако через апи и записывать в монго только их url.
Если прям хочется хранить в монго сами фотки, то нужно определиться в каком формате ты их будешь хранить: буфер, base64 или какие там еще есть, и исходя из выбора конвертировать пользовательское фото в соответсвующий формат и записывать

простая проверка на наличие window исправит ошибку

if (typeof window !== 'undefined') {
  // кодище
}

Можно вынести тип пропсов в отдельный тип/интерфейс

type ComponentProps = {
  prop1: string;
  prop2: number;
  prop3: boolean;
}

и указать тип пропсов "ComponentProps"

export const Component = ({ prop1, prop2, prop3 }: ComponentProps) => {
  ...
}

Можно так же воспользоваться типом FC (дженерик) и передать этому типу тип пропсов

export const Component: FC<ComponentProps> = ({ prop1, prop2, prop3 }) => {
  ...
}

Для начала нужно выяснить ширину экрана.

const [screenW, setScreenW] = useState(undefined);
useEffect(() => {
  setScreenW(window.innerWidth);
}, []);

Когда знаем ширину экрана, дальше все просто.
Если ширина экрана такая-то, отрисовываем один элемент. Если другая, отрисовываем другой элемент

const Component = () => {
  ...
  return (
    ...
    {screenW >= 1024 && <BigScreenComponent />}
    <SomeOtherComponent />
    {screenW < 1024 && <SmallScreenComponent />}
    ...
);

interface MyLittleInterface {
  age: number;
  name: string;
}

const someVar: MyLittleInterface = {}; // ой-ой! 
const someOtherVar: MyLittleInterface = {} as MyLittleInterface; // Ура!

Привет.
В твоем коде validate.required всегда будет true.