You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should document and stick to some pattern for what URLs are used, in both the development server and a production deploy.
The rationale is, if you are setting up a proxy, you might want to route a certain path to a different server. You need to choose a path that isn't used by this React app, which means you have to know what paths are used. If you route /files/* to a different port, and later we switch the build script so that it generates files prefixed with /files/, your setup will break.
My suggestion is, in production only use the URL patterns / and /static/*. In the dev server, use those two but also /dev/* for non-static content - ie the websocket. Then any routing layer only has a few things to worry about.
The text was updated successfully, but these errors were encountered:
We consistently use /static for any assets, and we serve index.html or proxy fallback for any other URL depending on whether you have proxy and whether accept header contains text/html. Seems pretty consistent to me.
We should document and stick to some pattern for what URLs are used, in both the development server and a production deploy.
The rationale is, if you are setting up a proxy, you might want to route a certain path to a different server. You need to choose a path that isn't used by this React app, which means you have to know what paths are used. If you route
/files/*
to a different port, and later we switch the build script so that it generates files prefixed with/files/
, your setup will break.My suggestion is, in production only use the URL patterns
/
and/static/*
. In the dev server, use those two but also/dev/*
for non-static content - ie the websocket. Then any routing layer only has a few things to worry about.The text was updated successfully, but these errors were encountered: