Do the cases in which you need to observe always be for computed style data? What I mean is can the library be setup to be more generic such as watching for:
<link rel="stylesheet"> element is added/removed to <head> (or other element)
A class is added/removed from an element.
An inline style has been applied / updated on an element.
Just looking at this from another potential point of view.
Coder, writer, nonconformist 🤘
Ex-SWE @ Facebook 🤩
Sharing experience and notes on building a career, sharpening coding skills and creating great things 🏆
Thanks for your reply! For my original task I wanted to supply with this library, I think it makes even more sense to just know about the possibility of style change like the ones you listed. If a stylesheet was added or removed, or a classname, or so on.
For a general-purpose tool, I don't know. Maybe if performance becomes a real issue for a real user (which I don't believe exists now) and I don't find a way to tackle the problem in any other way, it might be a solution. But then even the MutationObserver usage itself may become a bottleneck.
Regardless of this reasoning, thanks for your ideas - they're really valuable to me.
If you see any way in which this tool can be tailored to your personal needs, feel free to raise an issue or even a PR on GitHub.
Ah I see, thanks for clarifying. I think the idea could be served as a general purpose for specifying cases in which you'd expect something to change. For example, if an external stylesheet was injected into the page via a widget. That widget might present some style issues that you would need to counter or clean up.
The library could be constructed to establish rule cases to watch for, using the MutationObserver. When one of those cases rings true, it could then perform an implemented callback function.
I've found the MutationObserver an excellent tool, as long as it's used liberally on the page. I seem to run into issues when I try to use it for everything on the page. However, breaking it down into smaller cases to watch for didn't hurt performance as much.
Just some additional thoughts. I dig what you are trying to do here and appreciate the thinking going into this. Hopefully through collaboration you get what you are looking for.
Regards,
Patrick
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Do the cases in which you need to observe always be for computed style data? What I mean is can the library be setup to be more generic such as watching for:
<link rel="stylesheet">element is added/removed to<head>(or other element)Just looking at this from another potential point of view.
Hey Patrick,
Thanks for your reply! For my original task I wanted to supply with this library, I think it makes even more sense to just know about the possibility of style change like the ones you listed. If a stylesheet was added or removed, or a classname, or so on.
For a general-purpose tool, I don't know. Maybe if performance becomes a real issue for a real user (which I don't believe exists now) and I don't find a way to tackle the problem in any other way, it might be a solution. But then even the MutationObserver usage itself may become a bottleneck.
Regardless of this reasoning, thanks for your ideas - they're really valuable to me.
If you see any way in which this tool can be tailored to your personal needs, feel free to raise an issue or even a PR on GitHub.
Kind regards,
Oleg
Ah I see, thanks for clarifying. I think the idea could be served as a general purpose for specifying cases in which you'd expect something to change. For example, if an external stylesheet was injected into the page via a widget. That widget might present some style issues that you would need to counter or clean up.
The library could be constructed to establish rule cases to watch for, using the MutationObserver. When one of those cases rings true, it could then perform an implemented callback function.
I've found the MutationObserver an excellent tool, as long as it's used liberally on the page. I seem to run into issues when I try to use it for everything on the page. However, breaking it down into smaller cases to watch for didn't hurt performance as much.
Just some additional thoughts. I dig what you are trying to do here and appreciate the thinking going into this. Hopefully through collaboration you get what you are looking for.
Regards,
Patrick