Consider using wp.data layer instead of custom event dispatch

[mcsf]

Hello.

Given the heavy investment in WordPress's data module, especially in the context of the development of the Block Editor, has it been considered for supporting for the Consent API's client-side interface?

Stores under wp.data support subscribe, select and dispatch. There are a couple of benefits to it, from useful deprecation mechanisms for backwards compatibility, to the fact that consumers of the API may choose to consume it via a traditional "subscribe and dispatch" design, or declaratively from within wp.element-powered UIs (cf. useSelect). There are also affordances in place for client-side persistence of preferences.

Of course, the drawback to consider is the addition of dependencies.

I'm interesting in hearing how you weigh this approach against the current event-based one.

[rlankhorst]

hi @mcsf,

thanks for your input. I haven't worked with the data layer before. Can you give an example how you would see this? Would it work like a wrapper function to handle the consent state?

[mcsf]

Can you give an example how you would see this?

Sure! Consulting the Consent API would look like:

wp.data.select( 'core/consent' ).hasConsent( category )
-> true

where hasConsent is a standard selector, i.e. a function of consent state and any arguments such as category. Different selectors may be provided to consult state differently, even if they overlap. This is similar to how, when inside the block editor, we can call:

wp.data.select( 'core/block-editor' ).getBlocks()
-> [ { ... }, { ... } ]
wp.data.select( 'core/block-editor' ).getBlockCount()
-> 2

For actions representing state changes and other effects, you would have:

wp.data.dispatch( 'core/consent' ).setConsent( category, value )

Would it work like a wrapper function to handle the consent state?

For the consumer, the wrappers would be the selectors and action-dispatchers as seen above. For the implementer, you'd register the Consent store by providing these selectors and actions and, most importantly, the reducer, which is the internal mediator of state and actions.

The store for core/nux is a small enough example that may be more approachable than core/block-editor. If you are generally unfamiliar with the concepts of store, reducer, etc., I suggest reading up on Redux. :)

[rlankhorst]

@mcsf thanks for your input on this. I've given it some thought, and don't think the datalayer would be an appropriate solution for the consent levels.

I think it's very important that end users can see where their consent is stored (and for how long) in the most simple way possible, which is most transparant and publicly known with cookies. Additionally, it looks like the expiration period of the data can't be set. The expiration is something that explicitly needs to be adjustable, depending on the configuration of the cookie banner plugin that fires the consent.

Please let me know what you think @phpgeek, @mrxkon, @mundschenk-at

[aduth]

Hi @mcsf @rlankhorst ! As one of the people who helps maintain parts of the data module, I thought I'd drop in and share a few of my own thoughts.

First, I think this sort of discussion would make for an excellent topic in one of the weekly #core-js weekly JavaScript chats. I'd be happy to help coordinate for this to be on the agenda for an upcoming meeting if there's an interest.

To clarify a point about the data module: The data module isn't particularly opinionated about data storage. In fact, even the "default" persistence mechanism is implemented as a plugin that WordPress opts-in to. Furthermore, while it does use localStorage by default, the persistence implementation can be overridden to use something completely different (documentation, cookies example). I'm not familiar with all the requirements here, but based on my loose understanding, I'd agree that cookies might be a better storage mechanism here than localStorage, especially considering a potential need to access the same values between the server and client.

Where the data module is more opinionated, and which I think could still apply here, is in providing a consistent public interface for accessing, mutating, and subscribing to changes in state. What I see in the documentation with wp_has_consent, wp_set_consent, and document.addEventListener align quite well respectively with data's select, dispatch, and subscribe mechanics. Adopting a unified approach for these common patterns can help toward a goal of establishing a consistent developer experience.

To the point about expiration, while this could be implemented today as an extension of the data module, I think it's also worth highlighting that the feature-set of the module isn't set in stone and can be improved upon to better support these sorts of use-cases. Enhancements driven by real-world requirements like those outlined here could go a long way to help improve its utility for the benefit of all usage.

[garretthyder]

Thanks @aduth I'd be happy to join that chat if you can coordinate.

[aduth]

@garretthyder Great! I added it to the agenda for tomorrow's chat at 14:00 UTC. If that's too soon and there's nobody who can attend, we can punt it to next week's meeting. I added some rough notes based on my understanding of the needs, but feel free to suggest (in the document) any revisions, or bring them up during the chat.

[garretthyder]

Awesome thanks @aduth, agenda looks good and I'll try to wake up that early.

[garretthyder]

Following on a discussion in slack #core-js this seems like a very valid idea. @rlankhorst let's discuss further if you're around Wednesday for our #core-privacy chat at 19:00 UTC.

[rlankhorst]

I'll dive into this and will try go get a branch setup for this.

[roborourke]

Interesting discussion. My initial reaction was that the consent API primarily operates on the client side for site visitors. What is the overhead / impact of making wp.data a dependency for end users? From what I can tell it's about 9-10kb of code.

I'm definitely not saying it isn't still worth considering, especially if there are other client side uses for wp.data in the works but at the same time it's good to be mindful of sending additional JS to the client when there's a lightweight native alternative such as custom events.