Skip to content

Inline bundle rendering #104

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
IlyaSemenov opened this issue Feb 8, 2017 · 10 comments
Closed

Inline bundle rendering #104

IlyaSemenov opened this issue Feb 8, 2017 · 10 comments

Comments

@IlyaSemenov
Copy link

That would be great to allow rendering bundles inline rather than linking to them. This will speed up page loading for smaller bundles (e.g. having facebook/twitter sharing scripts combined into a single bundle).

For example, the following syntax:

{% render_bundle 'social' 'js' inline=True %}

would emit:

<script type="text/javascript">
// here goes the content of social.e9e35ae5.js
</script>
@imelnych
Copy link

imelnych commented Feb 20, 2017

This might also be useful for including standalone chunk manifests.

@owais
Copy link
Collaborator

owais commented Feb 20, 2017

Sounds reasonable but I'll need some time to think about how to implement it and how to handle all cases (bundles stored at remote location, caching, code extension points). If anyone wants to take a stab at this, please share your proposed solution here before starting the work.

@IlyaSemenov
Copy link
Author

FYI, there is a similar project python-webpack-manifest where the maintainer has already merged my PR for inline manifests (markfinger/python-webpack-manifest#5).

I like the framework-agnostic approach better. Architecture wise, there is no real need to be dependent on Django to pull manifest info.

@yourcelf
Copy link

It seems to me that the solution to this will cover a lot of the same territory as #103 (subresource integrity support). Both will require addressing the content of assets, and caching details beyond the filename.

matthiask added a commit to matthiask/django-webpack-loader that referenced this issue Sep 9, 2017
@matthiask
Copy link
Contributor

I have some code in a project of mine which works quite well. The idea is to add an additional setting, BUNDLE_PATH, and a template tag which first tries to render the bundle inline, then falls back to including a reference to a remote bundle. This also works well when using webpack-dev-server, because then the files never exist on the hard disk, and because of that the fallback is always used.

(Of course we'd probably want to add a new argument to render_bundle, for example prefer_inline=False, instead of adding a new template tag.)

I added the code in a gist: https://gist.github.com/matthiask/a4c301f61021614b19cd14d4e8979774

@owais Any feedback? If you like the proposal I'll happily clean it up for integration into the official repo.

@ghost
Copy link

ghost commented Sep 14, 2017

@matthiask After referring to gist link, I found a reasonable solution to this issue.
add static assets inline output features

@matthiask
Copy link
Contributor

@liuliangsir STATICFILES_DIRS and WEBPACK_BUNDLE_DIR both are not guaranteed to be set. I'd much rather have an additional key in the WEBPACK_LOADER dicts than some non-obvious (to me) concatenation of other variables. Also; I'm not sure why you'd want to (ab)use attrs to pass the inline argument -- it overloads the meaning of attrs. Adding another argument to the template tag seems much cleaner to me.

@owais
Copy link
Collaborator

owais commented Nov 24, 2017

This requires not only support for reading files from local disk but also from remote sources as assets are often stored at remove locations in production. Anyone wants to take a shot at this, please don't forget to handle remote assets in a reliable way

@matthiask
Copy link
Contributor

I published a good enough solution here: https://pypi.org/project/django-webpack-bundle/

It's not perfect and it especially does not support remove static assets but that's out of scope for me.

@fjsj
Copy link
Member

fjsj commented Nov 29, 2023

Closing, but keeping #234 open.

@fjsj fjsj closed this as completed Nov 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants