Giter Club home page Giter Club logo

Comments (3)

jeancahu avatar jeancahu commented on June 12, 2024 1
  • Uso de la herramienta NPM para mantener control de las dependencias de Javascript y de CSS del frontend del proyecto
  • Reducir en todo lo posible el uso de jQuery ya que este es código viejo (legacy) y sus funcionalidades ya son soportadas por los estándares ES6 y posteriores de Javascript, y por ende la mayoría de navegadores modernos (respecto a esto los sitios web más importantes están tratando de migrar completamente de esta tecnología)
  • Configurar la dependencia development, Webpack como minificador y transpilador para generar el bundle de bibliotecas de frontend
  • Hacer uso de las herramientas que ya bootstrap pone a disposición para autogenerar la hoja de estilos minificada. (CLI, disponible en NPM)
  • Identificar todas las bibliotecas utilizadas más de una vez pero con diferentes versiones para usar solo una de las versiones que soporte todo lo necesario, con el fin de no descargar tantas megas en la carga inicial.
  • Opcional: Es posible utilizar al propio GitHub como servidor de ficheros estáticos, de esta manera se puede diversificar las fuentes y reducir la carga sobre el servidor central.

from buses.

jeancahu avatar jeancahu commented on June 12, 2024

Esta es una de las herramientas junto con las otras que ya ustedes conocen

from buses.

jeancahu avatar jeancahu commented on June 12, 2024

Estamos teniendo un problema y es que antes de remover los estáticos es necesarico comenzar a usar las dependencias propias del proyecto por medio del manejador de paquetes JavaScript, es por esto que hice commits revert al branch de tree-shaking la idea es que antes de borrar cosas de /static que deberían estar en el tema lo mejor es mantener el package.json lo más cercano a stable para comenzar a trabajar dependencias desde esta rama ya que están evolucionando por aparte y esto tampoco es sano. Los reverts solo anulan los commits de borrar estáticos, el branch de tree-shaking es equivalente a que solo se hubiera agregado el package.json y las dep de vue, webpack, pero con la diferencia que la historia permanece entonces en caso de necesitar esos commits destructivos se puede regresar en el tiempo y usarlos.

Lo primero que habría que hacer antes de sacar todo el lastre estático y usar el tema correctamente sería automatizar el minificado y el pull de dependencias del código propio del proyecto, es decir, aquel JS que solo habita en este repositorio y no es thirdparty

  • Estabilizar la rama y los ficheros asociados a NPM dependencias y scripts, lo suficiente como para sentarla en stable y construir los JS partiendo ya de esta configuración de webpack para los scripts del proyecto.

  • Hacer un rebase a treeshaking de las ramas enfocadas en frontend para agregarlas ya al esquema de webpack

  • Sacar todo el JS de rutas o django-apps específicas del static/ global y ponerlos en el respectivo static/ de cada directorio, realizar los cambios pertinentes en templates etc.

  • Respecto a este tercer punto lo que pasa es que cada fichero estático que solo se usa en X página debería mantenerse en el directorio django-app/static/ por orden, a la hora de hacer el deployment de la versión de producción ahí sí se toman todos los static/ y se colocan en el mismo directorio todo para que NGINX lo sirva todo junto, pero es hasta ese punto que se juntan y se hace de forma automático por medio de comandos de Django.

Static de rutas lleva adentro otro directorio llamado rutas porque a la hora de moverlo al static global entonces en la URL quedará ese rutas que identificará a los estáticos de esta Django-app con respecto a los de todos los demás, por eso parece redundante pero no lo es, lo que pasa es que está pensado para cuando ya todos estén juntos en el NGINX no se mezclen y no haya colisiones de cosas que se llamen igual.

rutas/
├── admin.py
├── apps.py
├── fixtures
│   ├── agency.json
│   ├── calendar_dates.json
│   ├── calendar.json
│   ├── fare_attributes.json
│   ├── fare_rules.json
│   ├── feed_info.json
│   ├── routes.json
│   ├── stop.json
│   ├── stops.json
│   ├── stoptime.json
│   ├── stop_times.json
│   ├── trip.json
│   ├── trips.json
│   └── zones.json
├── migrations
│   ├── 0001_initial.py
│   ├── __init__.py
├── models.py
├── static
│   └── rutas
│       └── terminal.png
├── templates
│   ├── proximobus.html
│   ├── ruta.html
│   ├── rutas.html
│   ├── tabla-tarifas.html
│   └── tarifas-cards.html
├── tests.py
├── urls.py
└── views.py

Comparar luego del revert

from buses.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.