Estoy construyendo un proyecto con reaccionar como frontend y matraz como backend. Quiero que la aplicación creada por 'create-react-app' use el enrutamiento front-end con el paquete 'react-router-dom'. Código relevante en index.js:
<BrowserRouter> <Switch> <Route exact path="/" component={Home} /> <Route path="/about" component={About} /> <Route component={Notfound} /> </Switch> </BrowserRouter>Luego, quiero servirlo a través de un matraz, por lo que en el matraz tengo las siguientes configuraciones y reglas de enrutamiento:
app = Flask(__name__, static_folder="../build/static", template_folder="../build") @app.route('/', defaults={'path': ''}) def serve(path): render_template("index.html") Donde index.html se construye con npm run build . Cuando hago clic en la barra de navegación y redirijo a /about , la aplicación devuelve 404 no encontrada.
También hay otro error en la consola del navegador, que muestra: Manifest: Line: 1, column: 1, Unexpected token.
Cualquier ayuda es apreciada.
Consulte este tutorial para obtener información sobre cómo configurar el back-end de Flask para una aplicación de una sola página. Necesita una ruta general para servir el index.html para la página Acerca de:
@app.route('/', defaults={'path': ''}) @app.route('/<path:path>') def catch_all(path): return render_template("index.html")En el enlace del tutorial, también puede encontrar más información sobre cómo configurar una página 404 en el enrutador front-end (el front-end descrito es Vue, pero el concepto es el mismo).
Es mejor dejar el enrutamiento a una parte, ya sea python (en su caso, matraz) o reaccionar. El enrutamiento catch_all desde la aplicación de matraz que se sugiere en otro comentario, solo debe usarse con fines de desarrollo, porque normalmente las aplicaciones de reacción son solo aplicaciones web estáticas que se pueden servir con un servidor http genérico (como nginx o apache en producción). Si usa la alternativa catch_all del matraz en producción, terminará desperdiciando recursos, ya que la misma solicitud podría manejarse directamente desde el servidor http en lugar de recopilar la respuesta de un servidor wsgi. Es como si A, B y C estuvieran hablando, A quiere llamar a C, podría llamar directamente a C, pero en lugar de hacerlo, le pide a B que llame a C, y C responde a B, luego B transmite la respuesta a A. Totalmente innecesario el uso de recursos. Además, se volverá muy confuso si comienza/intenta mezclar el enrutamiento del matraz y la reacción. usa uno