-
Notifications
You must be signed in to change notification settings - Fork 13
Add templatetag and staticfiles storage for Django #20
Conversation
Wow, that looks really cool. I'll get back to you when I've got some free time to give the code a proper read |
Regarding the settings and testing, it's probably easiest to accept the values as args in the constructor. This'll mean we can test them easily, rather then relying on access to the |
If that's not too easy, you could maybe use a factory which stubs out enough to get things working |
9c1ec07
to
c72f218
Compare
now with tests and lots of mocking I think there is one controversial piece of code in here, which you can see in this test My idea was that I might only have the js-host server running during collectstatic, or I might run collectstatic locally and rsync the files to the production server. So I was planning on disabling the webpack bundling in-request if |
Cool, thanks for all of that. I'll have some free time in a day or two to properly look it over and merge this in. Regarding the disabling of bundling, I'm inclined towards the same. Given the build times required for most bundles, you don't want a production instance to freeze while the bundle's being generated. If someone opts-in to using a manifest, it's better to be explicit and simply throw an exception when an unknown bundle is encountered. When I merge it in, I'll take a stab at opening up pre-compilation for non-django systems - I work with django myself, but it'd be nice to decouple it. This might mean changing the Another TODO is to handle programatically generated config files which have dynamically generated names, which happens in python-react. I suspect that the list of bundles will need to take callbacks, so that you can generate them during runtime. Once again, thanks for this! |
Merged into the @rockymeza, thanks again! |
Thanks! -rocky
|
There's something akin to your PR on master now, although it's deviated quite a bit. I moved the manifest generation up into webpack-wrapper; where it generates them as part of a caching layer. The caching layer massively improves the time to first build when you first boot a server, it also keeps track of the bundle's file deps and checks mod. times on the deps and config files before serving the compilation output, so that'll hopefully avoid most issues regarding stale caching. In dev, it'll still spin up the watcher and - once it's ready - let it take over from the cache, so perf should be a lot better. The python layer knows how to read those cache files, so a precompilation stage boils down to just iterating over every config file and letting the compiler generate the file. In prod, you can turn on I stripped out the file storage which precompiled things during collectstatic. It seemed a bit magical to me, and in a lot of use cases it requires you to either override the global file storage or have a stage where you mixin a bunch of classes. I can appreciate the convenience, but I think it's better to have it as an explicit stage, hence I added a Anyway, this is all on master, but I'll push a new version up to PyPI in a couple of days. There are a couple of breaking changes still to land - mostly setting changes. Thanks again, @rockymeza! |
I think yours is probably a better solution for eventual other-framework interop. Thanks for getting something like this merged! |
Hi,
I made a templatetag and a storage backend that allows you to pre-compile the webpack bundles. I modeled the interface sort of close to django-compressor's offline mode and the code for the WebpackOfflineStorageMixin is based on the ManifestFileStorage from django.
I also adding some docs for how to use it, but I wasn't sure where you would have put the docs, so I just made a new section for it.
Before you merge this, I think we need to write some tests for the WebpackOfflineStorageMixin, but in order to do that, we need a way of overriding the settings, which is a little hard with the optional_django stuff. Do you have any idea for what we could do with that?
Thanks!