Allow more fine grained control over blocking elements
This PR introduces a new option blockElementFN to rrweb.record options. This option allows the consumer to add a callback function to have more control over if the element is blocked or not. This will allow consumers to have a very strict blocking policy and whitelist content.
🦋 Changeset detected
Latest commit: b0a72d2bc198097de09a8b574fa8c7d68855b684
The changes in this PR will be included in the next version bump.
This PR includes changesets to release 19 packages
| Name | Type |
|---|---|
| rrweb-snapshot | Patch |
| rrweb | Patch |
| @rrweb/types | Patch |
| rrdom | Patch |
| rrdom-nodejs | Patch |
| rrweb-player | Patch |
| @rrweb/all | Patch |
| @rrweb/replay | Patch |
| @rrweb/record | Patch |
| @rrweb/packer | Patch |
| @rrweb/utils | Patch |
| @rrweb/web-extension | Patch |
| rrvideo | Patch |
| @rrweb/rrweb-plugin-console-record | Patch |
| @rrweb/rrweb-plugin-console-replay | Patch |
| @rrweb/rrweb-plugin-sequential-id-record | Patch |
| @rrweb/rrweb-plugin-sequential-id-replay | Patch |
| @rrweb/rrweb-plugin-canvas-webrtc-record | Patch |
| @rrweb/rrweb-plugin-canvas-webrtc-replay | Patch |
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
There was an effort in #1541 to merge the two previous block methods into one argument that could be passed down. That's not a requirement to get this merged, but just to make note.
Oh interesting. It seems that they were thinking about something similar: https://github.com/rrweb-io/rrweb/pull/1541#issuecomment-2245420570. Happy to tackle that and remove the other two options, but that would be a breaking change and bigger than just a patch. Also willing to do it as a follow up.
@eoghanmurray what are your thoughts on this?