javascript - and - Flujo de trabajo y estructura de proyecto de AngularJS típico(con Python Flask)

python angular 5

Question

Soy bastante nuevo en todo este frenesí del marco del lado del cliente MV *. No tiene que ser AngularJS, pero lo elegí porque me parece más natural que Knockout, Ember o Backbone. De todos modos, ¿cómo es el flujo de trabajo? ¿Las personas comienzan con el desarrollo de una aplicación del lado del cliente en AngularJS y luego conectan el back-end a ella?

¿O al revés construyendo primero el back-end en Django, Flask, Rails y luego adjuntando una aplicación AngularJS? ¿Existe una forma "correcta" de hacerlo, o es solo una preferencia personal al final?

Tampoco estoy seguro de si estructurar mi proyecto de acuerdo con el Flask o AngularJS? Prácticas comunitarias.

Por ejemplo, la aplicación minitwit de Flask está estructurada así:

minitwit
|-- minitwit.py
|-- static
|-- css, js, images, etc...
`-- templates
|-- html files and base layout

La aplicación tutorial AngularJS está estructurada de esta manera:

angular-phonecat
|-- app
`-- css
`-- img
`-- js
`-- lib
`-- partials
`-- index.html
|-- scripts
`-- node.js server and test server files

Podría imaginarme una aplicación Flask por sí misma, y ​​es bastante fácil ver la aplicación AngularJS como ToDo List por sí misma, pero cuando se trata de usar ambas tecnologías, no entiendo cómo funcionan juntas. Casi parece que no necesito un marco web del lado del servidor cuando ya tiene AngularJS, un simple servidor web Python será suficiente. En la aplicación de tareas pendientes de AngularJS, por ejemplo, usan MongoLab para comunicarse con la base de datos utilizando la API Restful. No era necesario tener un framework web en el back-end.

Tal vez solo estoy terriblemente confundido, y AngularJS no es más que una biblioteca jQuery elegante, por lo que debería usarlo como si usara jQuery en mis proyectos de Flask (asumiendo que cambio la sintaxis de la plantilla de AngularJS a algo que no esté en conflicto con Jinja2). Espero que mis preguntas tengan sentido. Principalmente trabajo en el back-end y este marco del lado del cliente es un territorio desconocido para mí.

Answer 1

Comenzaría organizando la aplicación Flask en la estructura estándar de la siguiente manera:

app
|-- app.py
|-- static
|-- css
|-- img
|-- js
|-- templates

Y como mencionó btford, si está haciendo una aplicación Angular, querrá enfocarse en usar las plantillas del lado del cliente Angular y mantenerse alejado de las plantillas del lado del servidor. El uso de render_template (''index.html'') hará que Flask interprete sus plantillas angulares como plantillas jinja, por lo que no se procesarán correctamente. En su lugar, querrás hacer lo siguiente:

@app.route("/")
def index():
return send_file(''templates/index.html'')

Tenga en cuenta que usar send_file () significa que los archivos se almacenarán en caché, por lo que es posible que desee usar make_response () en su lugar, al menos para el desarrollo:

 return make_response(open(''templates/index.html'').read())

Luego, construye la parte de AngularJS de tu aplicación, modificando la estructura de la aplicación para que se vea así:

app
|-- app.py
|-- static
|-- css
|-- img
|-- js
|-- app.js, controllers.js, etc.
|-- lib
|-- angular
|-- angular.js, etc.
|-- partials
|-- templates
|-- index.html

Asegúrese de que su index.html incluya AngularJS, así como cualquier otro archivo:

<script src="static/lib/angular/angular.js"></script>

En este punto, aún no ha construido su RESTful API, por lo que puede hacer que sus controladores js devuelvan datos de muestra predefinidos (solo una configuración temporal). Cuando esté listo, implemente la API RESTful y conéctela a su aplicación angular con angular-resource.js.

EDITAR: armé una plantilla de aplicación que, aunque un poco más compleja que lo que he descrito anteriormente, ilustra cómo se podría construir una aplicación con AngularJS + Flask, completa con la comunicación entre AngularJS y una simple API de Flask. Aquí está si quiere echarle un vistazo: https://github.com/rxl/angular-flask

Answer 2

Creo que es importante determinar en qué extremo desea realizar la mayor parte de su procesamiento de datos: front-end o back-end.
Si es la parte delantera, entonces vaya con el flujo de trabajo angular, lo que significa que su aplicación de frasco funcionará como una api en la que una extensión como la de un frasco descansará.

Pero si, como yo, está haciendo la mayor parte del trabajo en el backend, vaya con la estructura del matraz y solo con el tapón angular (o en mi caso vue.js) para construir el extremo delantero (cuando sea necesario)

Answer 3

Este video oficial de Jetbrains PyCharm por John Lindquist (angular.js y jetbrains gurú) es un buen punto de partida, ya que muestra la interacción de webservice, database y angular.js dentro del matraz.

Construye un clon interesante con matraz, sqlalchemy, flask-restless y angle.js en menos de 25 minutos.

Disfrute: http://www.youtube.com/watch?v=2geC50roans

Answer 4

Otra opción es separar completamente los dos.

project |-- server |-- client

Los archivos relacionados con el matraz van debajo de la carpeta del servidor y los archivos relacionados con angularjs van debajo de la carpeta del cliente. De esta manera, será más fácil cambiar el backend o el front-end. Por ejemplo, es posible que desee cambiar de Flask a Django o AngularJS a ReactJS en el futuro.

Answer 5

Puedes comenzar en cualquier extremo.

Tiene razón en que probablemente no necesite un marco completo del lado del servidor con AngularJS. Por lo general, es mejor servir archivos estáticos HTML / CSS / JavaScript y proporcionar una API RESTful para que el cliente la consuma. Una cosa que probablemente debería evitar es mezclar las plantillas del lado del servidor con las plantillas del lado del cliente de AngularJS.

Si desea usar Flask para servir sus archivos (puede ser una exageración, pero puede usarlo), debe copiar el contenido de "app" de "angular-phonecat" en la carpeta "static" de "minitwit".

AngularJS está más orientado a aplicaciones similares a AJAX, mientras que flask le brinda la posibilidad de realizar tanto aplicaciones web de estilo más antiguo como crear API RESTful. Cada enfoque tiene ventajas y desventajas, por lo que realmente depende de lo que quiera hacer. Si me da algunas ideas, podría hacer más recomendaciones.

Answer 6

edición : la nueva guía de estilo Angular2 sugiere una estructura similar, si no la misma, con mucho más detalle.

La respuesta a continuación se dirige a proyectos a gran escala. He pasado bastante tiempo pensando y experimentando con varios enfoques para poder combinar un marco del lado del servidor (Flask con App Engine en mi caso) para la funcionalidad de back-end junto con un marco del lado del cliente como Angular. Ambas respuestas son muy buenas, pero me gustaría sugerir un enfoque ligeramente diferente que (en mi opinión al menos) se amplía de una manera más humana.

Cuando implementas un ejemplo de TODO, las cosas son bastante sencillas. Cuando comienzas a agregar funcionalidades y pequeños detalles agradables para mejorar la experiencia del usuario, no es difícil perderse en el caos de estilos, javascript, etc.

Mi aplicación comenzó a crecer bastante grande, así que tuve que dar un paso atrás y repensar. Inicialmente, un enfoque como el sugerido anteriormente funcionaría, al tener todos los estilos juntos y todos los JavaScript juntos, pero no es modular y no es fácil de mantener.

¿Qué sucede si organizamos el código de cliente por característica y no por tipo de archivo?

app
|-- server
|-- controllers
|-- app.py
|-- models
|-- model.py
|-- templates
|-- index.html
|-- static
|-- img
|-- client
|-- app.js
|-- main_style.css
|-- foo_feature
|-- controller.js
|-- directive.js
|-- service.js
|-- style.css
|-- html_file.tpl.html
|-- bar_feature
|-- controller.js
|-- directive.js
|-- service.js
|-- style.css
|-- html_file.tpl.html
|-- lib
|-- jquery.js
|-- angular.js
|-- ...

y así.

Si lo construimos así, podemos envolver cada directorio nuestro en un módulo angular. Y hemos dividido nuestros archivos de manera agradable para que no tengamos que pasar por un código irrelevante cuando trabajamos con una función específica.

Un corredor de tareas como Grunt correctamente configurado, podrá encontrar y concatenar y compilar sus archivos sin mucha molestia.