Skip to content
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

Ignore some types of events #193

Open
davidlesieur opened this issue Aug 9, 2023 · 8 comments · May be fixed by #197
Open

Ignore some types of events #193

davidlesieur opened this issue Aug 9, 2023 · 8 comments · May be fixed by #197

Comments

@davidlesieur
Copy link

Description

My understanding is that django-browser-reload listens for four types of events: server reload, change to Django template, change to Jinja template, change to static asset.

I really enjoy django-browser-reload, but have started using Parcel to build static assets. Its watch command provides hot module replacement. As you might guess, the issue is that if I use both django-browser-reload and parcel watch, the page reloads twice when a static asset changes. To avoid this, I can disable Parcel's reloading, but then I lose its superfast HMR (it can hot reload CSS stylesheets without requiring a full page reload).

Thus, it seems to me that it might be useful to have a way of telling django-browser-reload to ignore some types of events. In my specific case, I would simply disconnect it from static asset changes. Thanks!

@adamchainz
Copy link
Owner

Correctly understood.

I think this is a reasonable feature to add.

Let’s use a dict setting like:

DJANGO_BROWSER_RELOAD = {
    "events": {"static", "templates"},
}

My biggest concern is that server reload “events” work differently and may not make sense to disable.

Would you like to make a PR?

@davidlesieur
Copy link
Author

Right, it may not make sense to disable server reloads.

I'll work on a PR.

davidlesieur added a commit to davidlesieur/django-browser-reload that referenced this issue Aug 25, 2023
@davidlesieur
Copy link
Author

davidlesieur commented Aug 25, 2023

About the setting, I feel it might be strange to ask users to explicitly list all the events they want to enable, when all they want is (most likely) to disable just one.

Also, future upgrades might be easier for users if they specified just the events they want to ignore. If new events ever get added to django-browser-reload in the future, then users would benefit from those being enabled by default even if they had disabled a specific event in their config. Of course, it doesn't seem very likely that new events will be needed in the future, but who knows...

What do you think?

davidlesieur added a commit to davidlesieur/django-browser-reload that referenced this issue Aug 25, 2023
@davidlesieur davidlesieur linked a pull request Aug 25, 2023 that will close this issue
@twidi
Copy link

twidi commented Aug 28, 2023

I use this great tool (thanks @adamchainz and contributors) and I just went there because I have a need that looks like this one, but with more granularity: ability to ignore changes on some extensions.

My use case may be too specific but just in case here it is: I use normal django templates, statics, EXCEPT for a specific part where I write some typescript that is compiled to js. The problem is that the reload is triggered by the typescript change and often not by the compiled js changes because it happens too fast. Or at the best I have two reloads. So the ability to ignore ".ts" files, for examples (why not ".less" files, or other) would be great.

Do you think it is something that may be in this project and if yes, if it's in the scope of the current issue? I can help write a PR for this based on the one from @davidlesieur if needed.

@davidlesieur
Copy link
Author

@twidi Have you considered placing your .ts files in a separate directory from your other static files? I think django-browser-reload won't trigger if the files are not found by Django's static files finder.

@twidi
Copy link

twidi commented Aug 28, 2023

yes of course I can do that, I just wanted to have everything "front" related at the same place ;)

thanks for the tips

@davidlesieur
Copy link
Author

@twidi On some projects, I have started putting assets that Django does not really need to know (Sass stylesheets, uncompiled JS) into static-src directories, which are siblings to my static directories. In fact, it seems nice to distinguish which directories matter to build tools (static-src), and which matter to Django (static). This way, collectstatic also leaves out anything from static-src, which don't need to go public.

@twidi
Copy link

twidi commented Aug 28, 2023

This totally makes sense

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

Successfully merging a pull request may close this issue.

3 participants