-
Notifications
You must be signed in to change notification settings - Fork 952
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
Update notify dependency #2077
Comments
I would like to have a go at this but I'm not sure what approach to take for collecting the received messages. My understanding is that the watcher will send a message for each individual file changed. Should we log the changed files and cache these received messages, and then evaluate that cache separately or is there an easier approach that I am not seeing |
Yeah I'm not entirely sure to be honest. Maybe we can write our own debouncer that handles that rather than use the notify mini debouncer? |
If you mean "report only once per interval": debouncer-mini does that by default (otherwise it's a bug). There is also debouncer-full if you need more features. |
Can we get a list of all the debounced events in the interval? We want to do some additional filtering after, eg if 10 different templates files have been modified, we want to reload the templates only once. |
It should report all timed-out events in one interval. So that sounds to me like what you want. Not sure if some "cooldown" window could be added / helps more. |
I played with this a bit, and the implementation gets messy if we try and be smart about handling a batch of events minimally. We're lucky if the batch of events requires a full site rebuild, because then we can let the rebuild cover all other events. If we have multiple events and none require a site rebuild, we have to add logic to make sure that the union of all changes required is applied correctly, and its this logic that gets messy due to a variety of checks and sensitive ordering (ex: check for full rebuild cases, then partial update cases, etc.). I have a local implementation based on I played with behavior on master by using this toy script and a personal project:
Master shows (truncated in places):
In my local usage of Are you okay with me just iterating through the events in the batch and applying updates in series for now? That way we can reuse a lot of the existing handling logic in |
Can we be a bit smart about the changes? Eg only emit one change for any templates and CSS since we do the same thing for each. For all the other changes it's fine to run them in series |
There will be more logic and special-casing, but in general, definitely doable. When I next have time I'll see how clean I can make it. |
v5 has been released and it involves some changes.
The main one is that with the debounced version you do not get the type of event which is probably fine since we don't really care about that.
We do want to only react to a single file in the debounce time though: we should get all the changes to print them but then only do the minimum required.
Eg if 3 Sass files have been changed, we should print those 3 files that have changed but only recompile Sass once.
If a Sass file and a Content file have changed, we can skip the Sass compilation since it will be done when rebuilding the content.
The text was updated successfully, but these errors were encountered: