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

[Feat]: Event / callback for categories #643

Open
GeoJGH opened this issue Feb 14, 2024 · 1 comment
Open

[Feat]: Event / callback for categories #643

GeoJGH opened this issue Feb 14, 2024 · 1 comment
Labels
enhancement New feature or request
Milestone

Comments

@GeoJGH
Copy link

GeoJGH commented Feb 14, 2024

Description

V3.0.0

Services have the onAccept() and onReject() callbacks. There is no such things at the category level. The application has the onConsent() event.

The sequence of events occurs as follow:

  1. service onAccept()
  2. script execution for the enabled categories or services (ex <script type="text/plain" data-category="necessary">...</script>)
  3. app event onConsent()

This is problematic if we want to do something when a category is accepted, before related scripts execution.

I am aware of two workarounds:

  1. don't prevent scripts execution, but rather add, within the scripts, an onConsent() event listener and when the desired category is received, run the code. (see this post)
    The limitations of this approach are the non negligible extra code (vs simply adding a data-category attribute to an existing script), and the difficulties if a script execution should be impacted by the accepted/rejected status of multiple categories.
  2. add a single service to the category.
    This limitation is more graphical than else, we now have 2 accepted/rejected sliders for the same category, as depicted here

Proposed solution

I propose to add the onAccept() and onReject() callbacks to the categories.

Alternatively, the app onConsent() event should be fired before executing the scripts associated with allowed categories or services .

Additional details

No response

@GeoJGH GeoJGH added enhancement New feature or request triage yet to be reviewed labels Feb 14, 2024
@orestbida
Copy link
Owner

Look like a nice addition to me, extra flexibility.

@orestbida orestbida removed the triage yet to be reviewed label Mar 3, 2024
@orestbida orestbida added this to the v3.1.0 milestone Mar 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants