Best practice for widget media files?

[michaeljones]

Hi,

Thank you so much for creating this set up. I've always found doing asset hashing with Django quite daunting but your work makes it super easy.

That said, I have custom widgets in my code base for which I have webpack built javascript assets. Previously I've used the media option on the widget to provide the direct path to the asset but now that path needs to be dynamic. I've ended up writing the code as:

from webpack_loader.utils import get_loader

class VenueByNameWidget(VenueWidget):

    url_name = 'venues:name-suggestions'
    target_id = 'venue-name-suggestions'
    js_app_name = 'venue-name-suggest-app'

    @property
    def media(self):
        loader = get_loader('DEFAULT')
        bundle = loader.get_bundle(self.js_app_name)
        paths = tuple(map(lambda entry: webpack_loader.get_chunk_url(entry), bundle))
        return widgets.Media(
            js=paths
        )

But I felt that maybe there should be a webpack_loader.utils function to help with this?

I am no Django expert so I might be approaching the whole thing incorrectly but I wanted to share my experience. I'm happy to attempt a pull request if this would be useful.

Kind regards and thanks again,
Michael

[owais]

Hi Michael. Could you share the structure of your actual JS widget implementation? For most cases, you shouldn't need to have a reference to your assets managed by Webpack in Django. You can use assets in your JS components like <img src=require("path/to/image.png") /> and webpack will take care of the rest. Django's doesn't even need to know this image exists.

[michaeljones]

Thank you for the quick reply. I'm not sure that we're on the same page. My confusion is around Django Form Widgets and how the widget references the compiled javascript file using the media property rather than how the javascript files reference further assets.

My Django Widget makes use of a javascript file compiled by Webpack. Before adding [hash] to the javascript file name I used to just reference the javascript file directly by the expected output path but now I need to do a look up through the stats file and I feel that that look up from within Python code (rather than a template) could be assisted by an extra utility function or something.

I hope that makes sense. I might be missing something or using the wrong terms :/

[michaeljones]

Yeah, sorry, re-reading my first post, it is far from clear that I was referring to a Django widget.

[owais]

I see. Your suggestion about utils function sounds good to me. I think it'd be great to have a core set of functions that replicate the template tag functionality but deal with pure python objects (no django). Then the templatetags can also call those functions internally instead of implementing their own thing.

[michaeljones]

Cool, yeah, that would make sense. As suggested, happy to try to make a pull request if that would be useful.

[owais]

A PR would be great Michael. Thanks.

[gabn88]

While the latest update (0.4.1, with utils functions) made this a breeze to install for form Media, I did find out that a server restart is required if the included files change if you use a hash in the name of the static file. This is only a small drawback, but I'd thought I'd share it here :)

[owais]

Thanks @gabn88 I'm planning a major reorg of the internals. I'll see if I can handle this case as well.

[gabn88]

Ok, may I ask why?

By the way, I meant a Django server restart (not a node.js/webpack dev server restart) :)

[owais]

I've received a lot of requests that I don't want to implement as part of the core package because they are edge cases. I want to provide extension points so users can write a little bit of code to add even fairly complex features themselves and release their own open source plugins that work with webpack-loader.

…

On Mon, Mar 13, 2017, 11:42 PM gabn88 ***@***.***> wrote: Ok, may I ask why? By the way, I meant a Django server restart (not a node.js/webpack dev server restart) :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#95 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC0ajYFD9Uw737lAkTVgivHd7Cb0jwhks5rlYcLgaJpZM4LYtDO> .