Localhost — гэта не працоўны сервар: дыягностика аплікацый React, якія не працуюць пасля развязвання

Прыклад аплікацыі на React, якая працуе ідеальна на localhost, але перестае функцыянацыяваць як толькі ёй даюць розмістыць, являе сабою адну з найболей знаёмых проблем у роботе з фронтэндам. Запыткі перестаюць вяртаць данні, апдэйт сторанкі дае код 404, знімкі зникаюць, процес заходжання практычна не выконваецца, альбо платформа для хоставання адмовяецца скомпіляваць код, які чыстаўся на вашам ноутбуку. Практычна жадная з гэтых проблем не выходзіць з-параду самога React. Яны вынікаюць з разліку межу сяродавым, у яком вы розвіваеце продукт, і тым, з яким сталкаюцца вашы корыстувальнікі. У гэтым кялечку практычна розглянуты дзесяць найболей частых прычын, показана, як кожная з іх выражаецца, а таксама прадстаўлены метод дэбаггінгу і чарткі перапрыявы, якія можна викорыстоўваць практычна ў кожнай версіі.

Чаму той самы код працуе інакша ў продакшэне

Фронтэнд на React рэдкасцю ёст канчатковыя часткі всей аплікацыі. Ён выступае у зв’язку з API, а API — з базайнам дадзеных; кожны элемент у гэтой ланцуговай структуры залежыць ад налашоўкаў: зменных сяродовішча, назв домэнаў, правілаў сеті, настройкаў аутентыфікацыі і таго, што платформа хостынгу робіць з прыходзячыми запитамі. На вашай машыне вы неявна кантролюеце все гэта: вы знаеце, на якім порту працюе бэкенд, канфігурацыйны файл .env які чытаны і якія пакеты знаходзяцца ў каталозе node_modules. У працоўным режыме кожна з гэтых прыпускаў заменяецца на ўсё бол явныя параметры, і будзь-яя неспаўнасообразнасць можа змусіць правільны код выглядаць несправнам.

Згадвайце гэты падход, чытаючы нижэйшыя раздзелы. Большасць парадактаў вырашваецца за дапамогою змян у налашоўках, а не за дапамогою змян у кодзе.

1. Адреса URL API яшчэ вядома на localhost

Калі запусканыя прыемка не паказвае ніяных дадзейнаў, першыя рэчы, якія варта пераканацца, — гэта куды падаюць яе запиты. Пад час разработкі ўжываецца стандартная практыка — запускаты бэкенд локальна і вбудовваць яго адресу ў фронтэнд:

const API_URL = "http://localhost:8080/api";

Гэта працюе таму, што ваш браузер і бэкенд запускаюцца на той самы комп’ютар. Калі фронтэнд размешчаецца на такой адрасе, як https://my-app.example.com, тая ж сама лінія продовжвае надсылать запиты на http://localhost:8080/api. Проблема заключаецца у тым, што localhost адначасова рашуецца браузерам, які запускае код. Для візітара гэта означае яго сябе, а не вашу машыну для разработкі. Тады шлях запита фактычна становіцца:

User's Browser
      ↓
localhost:8080
      ↓
User's computer

Як толькі у візітара бэкенд не запускаецца на порту 8080, кожны запит збываецца.

Рашэнь — це перастаць кампілявацыя адресы ў кодзе і чытаць яе з аб’екта сераўнавальных зменных. У проекте Vite значэнне адзначаецца ў файле env:

VITE_API_URL=https://your-backend.example.com/api

і чытаецца ў вашам кодзе за дапамогай import.meta.env:

const API_URL = import.meta.env.VITE_API_URL;

Таким чынам, падчас розрабоцтва можна выкарыстоўваць адресу http://localhost:8080/api, а пад час выпуску — кантрольную адресу на кшталт https://api.example.com/api, пры чым код не патрабуе змян. Хоць це і мінімальная переработка, яна пазбегае ад аднаго з найчастэйшых галючынак у развертванні: прасунуць браузер трохі чужог чалавека працаваць з вашым ноутбукам.

Адзін з спосабоў захавання — гучна парадка, калі зменная не існуе. Якщо API_URL становіць undefined, запиты падаюць на такі шляхі, як undefined/users, што ускладнюе діагностику. Перапалоўка на адной лініі пад час запуску, яка фіксуе або выклекае парадку, калі значэння відсутнае, заўсёды дапамагае захаваць час пазней.

2. Зменныя сераўнавальной среды ніколі не былі настроены

Зменныя сераўнавальной среды — наступны звычайны варант. У локальных умовах, верагодна, у вас ёсць файл .env, які мае ў сабе все, што патрэбна прыстанку:

VITE_API_URL=http://localhost:8080/api
VITE_APP_NAME=MyApp

Гэтыя значэнні існуюць толькі на вашам комп’ютеры. Платформа для хоставання не чытае ваш файл .env (і не должна, адколі гэты файл зазвычай выключаецца з кантролю версій). Ваша версія для сераўнавальной среды павінна отрымаць свае сабственныя значэнні, настроеныя ў настройках зменных сераўнавальной среды прадастаўця:

VITE_API_URL=https://your-backend.example.com/api

Пасля дадзення або зменшэння значэння там неабяжна запусціць новую разгрузку. З Vite гэты крок не ўзначыць выборны: толькі зменныя, прадзефісаваныя VITE_, стаюць доступнымі для коду кліента, і Vite заменяе іх у пакете час разбірання. Зменшэнне зменнай у панелі керування нічога не даст для пакета, які вже быў створаны з старым значэнням.

Зменныя фронтэнду не ўзначаюць секрэтных дадзеных

У гэтым крыўдзіцца урок безпекі. Размешчэнне значэння ў .env не робіць яго прыватным. Усе, што стае доступным для кліента, компілюецца у JavaScript, які кожны візітар завантажае і можа прачытаць. Паролі да базы дадзеных, прыватныя ключы API і іншыя аутентифікацыйныя даныя сервера ніколі не должны знаходзіцца ў зменныях VITE_*. Храніце іх на бэкендзе або за функцыяй сервера, і нехай фронтэнд вызывае канцэнтры, якія викорыстоўваюць іх за ўпамінанне.

3. Правіла CORS дазваюць толькі ваш адміністрацыйны выхад

Памылкі крос-выхадных рэсурсоў ёсць яшчэ аднай класычной неспадзячкай пасля развяртання. Уявіце фронтэнд, які служыць з:

https://myapp.example.com

і бэкэнд, які служыць з:

https://api.example.com

Это разныя выхады, таму што выхад — это сума схемы, хоста і порту. Браузеры выкананяюць політыку адно-выхаднага доступу, таму каб фронтэнд мог узяць дадзеныя з API, бэкэнд павінен адпаведаць з загаловкамі CORS, якія чыста разрываюць выхад фронтэнда.

Пад час разработкі бэкэнд, верагацейна, быў настроены так, каб прымаць запиты з сервера разработкі Vite:

http://localhost:5173

Усё працавала, таму легка ўявіць, што CORS налажана. Аднак пасля развяртання выхад фронтэнда ёсць:

https://myapp.example.com

Для прыгульніка гэта ўсё новы кантынент. Якщо бэкенд усё ўсё толькі паводзіць http://localhost:5173, то розміщаны фронтэнд будзе заблокаваны. Для бэкенда Spring Boot разрэшэнне кантыненту працы ў режыме продакшэна для кантролера можа выглядаць так (фрагмент на Java):

@CrossOrigin(origins = "https://myapp.example.com")
@RestController
public class UserController {
    // ...
}

Анотаванне кожного кантролера падходзіць для маленькіх сервісаў, але у большай базе коду ўнічыжная цэнтральная настройка CORS лёгкей у адтульненні і менш верагатліва быць забутайя пад час дадавання канчыкаў. Незалежна ад тэхнологій, правілле застаецца адно: дазволеныя кантыненты павінны точна падходзіць да рэальнага кантыненту фронтэнда ў режыме продакшэна, уключаючы https і любыя паддомены. Паўзучы, працэсабельны патэрн — це чытанне спісу дазволеных кантынентаў з сэрвысу настройкі середавішча бэкенда, таким чынам кожны режым — разработка, стэйджінг і продакшэн — дазваляе правы фронтэнд.

Пам’ятайце, што CORS — это механізм браузера. Запрос, які не працюе з помилкай CORS у браузеры, можа запрацаваць за дапамою curl або Postman, таму тэставанне API параду з браузера можа даць хыбны результат пра адгук.

4. Апавершэнне маршруту на стороне кліента вяртае 404

Гэта проблема часта заставляе разработчыкаў перагледваць кодіх свайго роутера, калі ён працуе нормальна. Падазроўваючы, што у прыкладнай програме є такі маршрут:

/dashboard

Вы прайходзіце на галоўную сторону, нажымаете лінк на панель керавання, і ёна адобразжваецца ідеальна. Вы можете навігаваць без проблем. Потым вы апавершваеце сторонню, і сервер адпавядае:

404 Not Found

Пасловік крыўцяе ў тым, як працуюць аплікацыі з адной сторанай. Калі вы нажмете на лінк, React Router апдэйтуе URL і выводзіць усю вялікую складовую цэлкам у браузеры; жадання да /dashboard ніколі не дасягае сервера. Калі вы апавернуце сторанку чыста чыгунна адкрыце гэты URL, браузер запытае сервер-хоста пра /dashboard. Якщо сервер ведае толькі пра рэальныя файлы, ён шукае ресурс з такім шляхам, нічога не знаходзіць і вяртае код 404.

Рашэнь — это запасныя правілы на хосте: кожны запит да маршруту фронтэнду, які не падае пад рэальны файл, должен быть перапісаны або перенаправлены на index.html. Потым браузер завантажвае дапрыягу, а React Router чытае URL і адразу відобразвае правильны экран. У дасведчыцтві па размешчэнні React Router описваецца гэтая патрабова, і большасць статычных хостоў прысвячае гэтаму настройку або невеликі файл конфігурацыі. Таму, калі клікаванне працюе, а аднаўленне — ні, не трэба чыніць змяны ў маршрутах, а спачатку пераканацца ў настройках перапісваму SPA на хосте. Якщо хочаце падтвердзіць, як самыя маршруты выказваюцца, адзірніце основы React Router.

5. Шляхі імпорту з неправым родам літер

Дзеякіі багі застаюцца непазначальнымі, пакуль кампіляцыя не выканаеца на іншай аператывной сістэме. Уявіце файл компонента з такім іменем:

Header.jsx

Імпортуецца так:

import Header from "./components/header";

Едынаковая разліка — адна велика літера, якую лёгка працязьнуць пад час перагляду. Сістэмы файлаведання не падтрымляюць аднаковасць роўнародных і вялікіх літер; у macOS і Windows настройкі ўключаюць нечутлівасць да роўнародных літер, таму імпорт выконваецца і прыстанок запускаецца. Большасць сервераў для складання і контейнероў работаюць пад Linux, дзе сістэмы файлаведання є чутлівыя да роўнародных літер, таму Header.jsx і header.jsx є двума разнымі іменамі, і складанне збягаецца з адной ошибкай «модуль не знайдзены».

Рашэнне — проста зробіць так, каб кожны імпорт адпавядаў файлу на дыску па кожнаму символу. Прыклад:

components/Header.jsx

Запісаць імпорт так:

import Header from "./components/Header";

Такое жа адзыяванне трэба прыменаваць да назва каталогаў. Ішчэ адна падступка, якую варта знать: перайменаванне файла толькі за дапамою розліку верхніх і ніжных букв можа не быць зафіксавана Git на файласистеме, якая не разлічае верхнія і ніжныя буквы, таму рэпазітарый можа застацься з старой назвай, нават як ваш рэдагувальнік паказвае новую. Пераканаленне назвы, якую на самай працоўвае Git, быстра расплывае гэту загадку.

6. Адпраўкі і статычныя ресурсы зникаюць

Інодзе сама прыкладка запускаецца, але яе адпраўкі, шрыфты чы іконкі — няма. Гэта зазвычай значыць, што ресурсы аднароўваны па шляхах, якія працавалі на сервере разработчыка, але не існуюць у фінальнай версіі прыкладкі.

Vite адказвае двума разнымі механізамі, і важна знать, які з іх вы используеце. Першы — гэта імпорт ресурса з коду выхадных дасягоў:

import logo from "./assets/logo.png";

і выкарыстоўванне імпортаванага значэння як джерела адпраўкі:

function App() {
    return <img src={logo} alt="Logo" />;
}

Пакалькі ўсталяванні праходзяць через граф модулаў, таму Vite обрабоюе іх пад час стварэння проекта, копіюе іх у выходны файлы з генераваным іменем і дае правильную URL. Вам ніколі не трэба будзе здагадваліцца пра канечны шлях.

Другі механізм — это каталог public, дыкія файлы, якія павінны быць выданы без жадных пераборак:

public/
└── logo.png

Файлы з гэтага каталога копіююцца ў корань выходных файлоў, таму да іх прайшліваецца за дапамогою абсалютнага URL-шляху:

<img src="/logo.png" alt="Logo" />

Асалідны прынцып — это разлік межу шляхам на вашым дыску і URL-адрэсамі, якія можа запрашваць браузер. Ваш рэдагар можа точна ведаць, дзе знаходзіцца src/assets/logo.png, але браузер разумее толькі URL-адрэсы, якія фактычна выдае розмешчаны сервер. Якщо прыложэнне размешчаецца пад падшляхам, а не пад корнем домэна, абсалютныя шляхі на кшталт /logo.png таксама можу не працаваць, і самэў гэтага існуе опцыя base у Vite для рашэння.

Калі які-небудзь ресурс з’являецца недоступным, ачынітэ карточку Network у браузеры і перагляньце неудачны запит. Часта вы пабачыце або шлях, які не існуе ў готовай версіі прыложэння, або код 404 ад сервера, і гэта пакажае, калькі з двух механізмаў трэба выправіць.

7. Сервер для разработкі — гэта не готовая версія прыложэння

Запуск прыложэння з:

npm run dev

Запускаецца сервер разработкі з можласцю гэтайчаснага замены модуляў, дакладнымі паведамленнямі пра адхыленнія і перетварэнням модуляў за патрэбай. Тое, што выкладваецца, — гэта іншы элемент: аб’еднаны, оптымізаваны набор статычных файлаў. Для проекту Vite яго ствараюць за дапамою:

npm run build

а ваш хост выдае гэты результат. Паколькі два шляхі обрабоцвання коду адбываюцца разна, цэлкам можліва ситуация, калі прыстанок працюе пад:

npm run dev

але не працюе пад:

npm run build

Такая неудача ёсць хорашай новынкай, якщо вы яе самі з’явілі, таму што можете яе выправіць перш чым ўсё дасягне корыстнікаў. Vite таксама дазволяе выдаць готавы результат локальна за дапамою:

npm run preview

Гэта ўсё ближэй да таго, што побачыць візітары, чым на сервере разработчика. Стаць прывыкам ствараць і пераглядваць проект у локальных умовах пры кожнай разгрузцы, а не даваць платформе хостінгу быць першым месца, дзе запускаецца фінальная версія проекта. Падключэнне команды npm run build да процеса CI дае вам тую ж гарантію аўтоматычна пры кожнай заявцы на падключэння коду.

8. Каталог node_modules у локальных умовах маскіеяць відсутныя залежнасці

Дырэктарыя node_modules, якая залишаецца дзейнаўной праўільна дзялёў часу, може змусіць падазроўваць, што проект у стане, кращым, чым ён на самай працэ. За тыя ж недзелі розработкі там накаплююцца пакеты: тыя, якія вы інсталавалі раз для працэў, транзытныя залежнасці іншых пакетаў, залишкі з відмовленага галузевога рэпозытария. Ваш код можа імпортуваць адны з гэтых пакетаў і працаваць лишта таму, што ён там проста ўсё ж такі є.

Сераўскае атмасфэра пачынаецца чыстая. У яй установляецца толькі тое, што описваюць package.json і файл lockfile, нічога больш. Таму, якщо ваш код містіць:

import axios from "axios";

тады Axios павінен быть заявлены як справжняя залежнасць проекта, напрыклад:

{
  "dependencies": {
    "axios": "^1.0.0",
    "react": "^19.0.0",
    "react-router-dom": "^7.0.0"
  }
}

Нумеры версій у гэтым фрагменте є ілюстратыўнымі; выкорыстоўвайце тыя, якія насправды патрэбны вашаму проекту. Мета — каб чыстая копія, пасля якой адбываецца чыстая установка, мела ў сабе все неабходнае для стварэння і запуску прыкладу. Зберагаюце як package.json, так і файл lockfile і падтрымайце ў ніх сінхронізацію, каб кожная установка выкарыстоўвала тыя ж версіі.

Ёнколі хочаце перадаць умовы развяроўкі на местных сурэччах, трэба выдаліць папку node_modules і зноў яе установіць, жадаўна за дапамогою npm ci, які установляе элементы строга на адвярнутым файле і даўае памылку, якщу адвярнуты файл і package.json не састаюцца. Якшчы пасля гэтага будова зламаецца, значыць вы знайшлі незаявленую залежнасць раней, чым гэта зробіў хост.

9. Фронтэнд працуе нормальна, а бэкэнд не функцыонуе

Ёсць спадчына караць React кожны раз, калі экран выглядае некоректна, але прычына часта знаходзіцца далей у ланцугу задач. Падазроўваючы, што развярочаны фронтэнд завантажваецца успешна:

https://myapp.example.com

Вы ачынайце панель керування і бачыце, што яна порожня. У вікні Network вы знаходзіце:

GET https://api.example.com/api/dashboard
500 Internal Server Error

Гэтыя рэчы многа сказываюць. Аплікацыя React выканала свою задачу і адправіла запит; бэкенд яго прыjąў, але пасля таго зазнаў неудачы пад час обробкі. Якія можаць быць прычыны: зламаная наладка з’ѐднання з базай дадзеных, відсутная змэнная сераўерскай супэрфісу, проблемы з аутентыкацыяй, неконтрольваная асывчанне чы ўстановкі, якія не зусім адпаведаюць вашай локальнай наладке.

Тыповы запит для фул-стака праходзіць через гэтыя слоі:

React Frontend
       ↓
REST API
       ↓
Backend
       ↓
Database

Неудача на нижнім роўні паследуе на верхні. Якщо до базай дадзеных немагчыма дасягнуць, панель керавання выглядае несправнай, нават якшо кожны рядок коду фронтэнду правільны. Самэй тым дыагностика не должна заканчывацца на браузэре. Калі запыт да API не выйшоў, прачытайце вікно Network, а пасля — логі бэкенду. Якшо браузэр паказвае код 500, а логі сервера гаворяць:

Database connection failed

Вы сталкнуліся з проблемайю бэкенду чы рыхтавання інфраструктуры, а не з багам у адрадзенні. Фронтэнд, які паказвае чысты статус абэрации для нявясканых запыткаў у змене з порожней сторонай, дапамагае як корыстнікам, так і разрабоцам разбіраць гэтыя адразы.

10. Автанацыя працуе локальна і не работае пасля развяроцьбы

Працэс зайшчыцтва ў систему ўскладнены выключна разлікамі сяродавысцей. Локальна парадокс можа выглядаць так:

localhost → Login → Dashboard

У працоўнай сяродавысці ён становіцца таким:

Production → Login → Dashboard doesn't load

Некалькі паканялых проблем можа самыя по сабе спрычыніць гэта. Фронтэнд можа яшчэ вызываць некоректны URL API, правілы CORS бэкенду можа не ўключаць адресу працоўнай сяродавысці, або токены можа не быць належна настроеныя для новай сяродавысці. Аднак кукі є самым частым прычыной.

Чаму кукі паводзяцца інакш у працоўнай сяродавысці

Тое, чы гэты браузер зберагае і адправляе кукі, залежыць ад яго атрыбутаў: Secure, HttpOnly, SameSite, Domain і Path. У локальных умовах апштоськія дадзеныя часта знаходзяцца на аднам хосте, таму гэтыя атрыбуты рэдка калі маюць значэнне. У працоўных умовах фронтэнд і API могу знаходзіцца на разных доменах, через HTTPS, і тады браузер пачынае прыменяць правіла. Напрыклад, кукі, пазначанаяя як SameSite=None, прыймаецца толькі тады, калі яна таксама пазначанаяя як Secure.

Запыткі між рознымі каналамі, які перадаюць аутентыфікацыйныя даны, таксама выклікаюць неабходнасць саўместных дзеянняў з обох бакоў. Кліент должен пацэльна з’явіцца пра перадачу аутентыфікацыйных даных, а сервер должен чыста разрэшыць ўжыванне такіх даных для конкрэтнага каналу; каналы у вигляде „вільных знакоў“ не прыймаюцца для запыткаў з аутентыфікацыйнымі даныма. Якшто аднак з бакоў не будзе выпанавана ўсё, запытка аб входзе можа здавацца успешной, пры тым як кукус сесіі ніколі не будзе прыбываць пад час наступных запыткаў.

Увага: процес входзу, які працюе на localhost, быў перапытан толькі ў найпростейшай можлівай средзе. Перапытайте яго знову ў средзе, нацэлёванай на рэальную працу, з HTTPS, доменамі, настройкамі кукусоў і правіламі CORS.

Метод дыбаггавання па шарах

Калі выклікаецца бяда пад час развёртвання, найменш эфектывае рашэнне — це праверкі абыяковых компанентаў і надзея. Эфектывае рашэнне — глыбокае выявлення таго, які шар не працуе, перш чым прыступляць да праверкі коду.

Пачніце з консолі

Ачыніце інструменты разработчыка браузера (зазвычай F12) і прачытайце рэжым Console. Паведамленні на кшталт Failed to fetch, адмовы CORS, неконтрольваныя выключэнні JavaScript і коды 404 для скрыптов або ресурсаў кожна вядуць да разныя прычыны.

Прачытайце вікно Network

Перейдзіце на вікно Network і перазавантажыце сторунку. Для кожнага запиту вы можетэ паказаць точны URL, метод HTTP, код статусу, тэла адпаведзі і часта заголовкі. Для проблем з API гэты ўвесь самы інформатывны відзор. Можаце пабачыць:

GET /api/users
Status: 404

альбо:

GET /api/users
Status: 401

альбо:

GET /api/users
Status: 500

Кожны код статусу сужае пошук:

• 404: запрошаны ресурс або маршрут не існуе па гэтым URL.
• 401: трэба аутентыфікацыя, альбо надаслены данні аутентыфікацыі не існуюць або ў некоректным формате.

403: сервер разумее, хто вы, але адмініструўваць дзеянне адмовляецца.

500: сервер падчас обробкі запиту зіткнуўся з внутранім бягам.

Пераканайцеся, які URL насправды викорыстоўвае браузер

Не пакладайцеся на тое, калі вы думаеце, што робіць выконвальны код; паглядзіце на запит, який браузер фактычна адправіў. Якщо продакшн выкалікае:

http://localhost:8080/api/users

тады як бэкенд насправды знаходзіцца ў:

https://api.example.com/api/users

вы практычна напэўна знайшлі проблему, і ёю є праблема з URL API з раздзелу 1.

Следзіце за памылкамі сервера ў журналах бэкенду

500 означае, што адказ знаходзіцца на серверы. Логі бэкенду можа паказаць неудачны з’яўленне на базе дадзенаў, відсутнае зменнайкі аб выключэнне, пра якое фронтенд не можа дапамогчы. Самэ гэта звычка пераходзіць да наступнага слоя, калі паказаныя дапамогі на гэта вказуюць, якраз і спрыяе шырокамасштабнаму адлучэнню бягаў.

Аналіз рэальнага выключэння

Разглядзім прыклад аплікацыі з фуль-стаком, якая запускаецца без адказоў на проблемы, але панель керування адображаецца порожней. Інстынктыўная рэакція — прыпусціць, што ў компоненте панелі керування є баг:

"Чыго-небудзь не так у компоненте панелі керування."

У замяне адкрывання самога компонента трэба адкрыць вікно Network. Там вы пабачыце:

GET https://api.example.com/api/dashboard
Status: 500

Гэта вже выключае фронтенд як асновную прычыну: запит быў адправлен. Далей у логах бэкенду паказуецца:

Database connection failed

За дапамою обох паказаных доказаў вся ланцуговая структура станавіцца ясной:

React Frontend
       ↓
API request
       ↓
Backend
       ↓
Database connection failed
       ↓
500 response

Компонент панелі керування ніколі не быў прычыной проблем. Дзесяць хвілін чытання інструментаў прыглядача і логаў сервера заменілі тыя гадзіны, якія моглі пацягнуцца на перерабку вучорашняго коду. Умэнне чытаць кешэўкі прыглядача, трафік сеті і логі сервера адно з найцэннейшых навыкаў у паўсячнай роботе з програмным апаратам.

Спіс пераконтрацыяй перед запускам

Найнадзейныяй спосаб развучыць неспакоў, якія можуць выйсці пад час запуску, ёст тое, каб перад аплывамі выявіць кожны шлях, які запит праходзіць ад прыглядача да базы дадзенаў. Практычны спіс пераконтрацыяй:

• Заўядзіце npm run build локальна і пераканаўцеся, што ён успехуе, пасля чаго пераканаўцеся з npm run preview.
• Пераканаўцеся, што URL продакшн-API заданы і што жадны запит не накіраваны на localhost.

Пераканаўцеся, што на платформе для хоставання існуюць усі неабяжныя зменныя сераўіса, і што ніякіх секрэтных даных немае ў зменныях фронтэнду.

Якщо фронтэнд і бэкэнд знаходзяцца на разных адресах, пераканаўцеся, што бэкэнд разрашае самэ гэтую адресу фронтэнду для працы.

Для аплікацый на базе React Router ачынайце важныя маршруты безпосередна і аднавляйце іх, а не толькі пераходзьце праз галоўную сторону.

Пераканаўцеся, што адобразяюцца картынкі, шрыфты і іншы статычныя ресурсы ў запусканай версіі аплікацыі.

Для аплікацый з аутэнтыкацыяй працавайце з функціямі заходжання/выходу, захаваных маршрутаў і аднавленняя стороні, якая ўжо автэнтыфікована.

Пасле запуску старожыце карточкі Console і Network, а таксама чытайце логі бэкэнду, калі выкананыя запыты API не вядуцься.

Няма жаднага списку пераконтроўкаў, які гарантаваў бы бездыяковую выпускную версію, але гэты список выяўляе большасць распашчытых проблем, калі іх яшчэ лёгка вылечыць. Чым болей шырокае уявленне пра тое, калі мае складвацца надзейны проект з самага пачатку, базаваны на React прынцып для выпуску раскрывае аспекты інструментаў.

Чаму фраза „гэта працуюе локальна“ мало чаго дазволяе сказаць

Ваша машына — это контролюемая, спрыяючая среда. Вы знаеце, дзе запускаецца бэкенд, якія зменныя заданы, што інсталаванае ў node_modules і якая база дадзеных викорыстоўваецца прыложэнням. У рэальных умовах практычна все зменяецца: іншы домэн, іншая адреса API, іншыя зменныя среды, іншая база дадзеных, строгейшыя правілы CORS і кукі, сервер, якому трэба падказаць, як кераваць маршрутамі з боку кліента, і часта іншая операцыйная система. Код можа быць абсалютна правільным, хоця конфігурацыя навакола яго будзе некоректная.

Самэй таго развёртванне павінна адносіцца як да іншай среды, проты якой трэба теставаць, а не да фінальнага крока, які выконваецца пасля завершэння розрабоцтва. Среды стэйджынгу, практычныя запускі CI і прэвю-развёртванні існуюць для таго, каб тэставанне велічылася раней.

Ключовыя выводы

• Калі ўсё зламаецца пасля развяртання, спытайце, які слой не працуе, перш чым спытваць, што не так з React.
• Якщо нічога не завантажваецца, паглядзіце на выходны матэрыял будовы та ресурсы; якщо сторанка завантажваецца, але данныя — ні, паглядзіце на вкладку «Сеть» та URL API.
• Код 500 перадае вас да логаў бэкенду; адказ пра памылку CORS перадае вас да спісу дазволеных выкананняў бэкенду.
• Маршрут, який працюе пасля кліку, але выдае 404 пасля апдэта, трэбуе фаллбека для SPA на хосте, а не змян у рутэры.
• Відсутныя значэння зазвычай означаюць, што параметры середовішча прыменення так і не былі заданы, або дапрыга не была перабудована пасля ўстановкі гэтых параметраў.
• Памылкі аутантыкацыі часта ствараюцца ўнаследке сумешання URL API, прынтара CORS та атрыбутаў кукі, таму пераканайцеся, што всё гэта правільна.

Застосунак, які быў розгорнуты, — это система фронтэнду, API, бэкэнду, базы дадзеных, настройкаў, хостынгу, сеті і прыстрою для перегляду. Дыягноставайце кожны з эых слоёў по аднаму, і проблемы падчас розгортання больш не будуць загадкамі.

Заступленне на такія проблемы — гэта не знак слабых навыкаў програмавання; гэта спосаб, якім усе вучыцца, з чаго складаюцься рэальныя системы. Мета не ў тым, каб ніколі не бачыць аднойчын, а ў тым, каб шыбкаа знаходзіць месца, дзе яны насправды з’яўляюцца.