您需要 登录 才可以下载或查看，没有帐号？立即注册
browserify, webpack are too good to ignore.
Problems with the currect approach
What about django-npm, pipeline and compressor?
- Manually maintaining dependencies is a pain.
- No integration with managers like npm and bower.
- Horrible for frontend engineers and designers to work with.
- Backend and frontend systems are tightly coupled and sometimes limit each other.
Problems with wrappers
So should we abandon staticfiles?
- They are opaque, slow and hard to debug.
- Limited by django’s staticfiles system.
- Limited by staticfiles.
- Very tightly coupled with django.
No, but we should limit it to just collecting pre-bundled static assets to the target directory or static file servers. We should not hook post-processors into it. The build process for frontend assets should be completely decoupled from staticfiles.
How do we integrate the frontend tools with django then?
For simpler cases, we don’t even need to integrate. We can use things like gulp or grunt to compile assets and then use collectstatic to sync the builds, but we need some sort of integration to make things a bit smoother. During development, it makes sense to return 500 error code when a build fails so one knows immediately where to look for the problem. It also makes sense to block a request while a build is being compiled to make sure you don’t test older code in the browser. For production use, we can configure our frontend tools to use hashed names in the builds; It would be nice to have an easy way to get reference to hashed bundles in django. In my opinion, integration should stop here. We should not spawn processes from python, translate config in settings.py to native JS config.
webpack-bundle-tracker + django-webpack-loader
django-webpack-loaderand webpack-bundle-trackerimplement a system like this. webpack-bundle-tracker plugin emits necessary information about webpack’s compilation process and results so django-webpack-loader can consume it. django-webpack-loader does not care how you use webpack. You could control it from gulp, use the dev server, use the —watch mode or manually run it after every change. Head over to https://github.com/owais/django-webpack-loader/to see how it all works or readthis guide for setting it all up with optional live reload for react components.
What this solves
Limitations of this approach (for now)
- Use proper package managers like npm and bower instead of manually managing source files.
- Use webpack transparently without any limitations and leverage all the documentation and resources.
- Handle your frontend assets however you want. Run webpack in watch mode, use grunt, gulp, webpacks’ dev server or anything you desire. No limitations.
- Make your frontend engineers and designers happy! :)
- Completely decouple frontend build process from django. You could build and serve your static assets from a completely different system as long you give django access to the stats file generated by webpack-bundle-tracker.
- Harder to store static files in app directories (totally worth it).
- Doesn’t integrate with static files provided by 3rd party apps yet.
- Need to setup your frontend toolchain manually but that is very easy most of the time.
下一篇：It looks like Facebook motivated a lot of people to register to vote