dom-gdpr-guard
v3.2.0
Published
Vanilla JavaScript binding to use gdpr-guard as efficiently and easily as possible
Downloads
18
Maintainers
Readme
dom-gdpr-guard
Vanilla JavaScript binding to use gdpr-guard as efficiently and easily as possible
This library defines logic to display GDPR settings and allow to easily modify and save them.
If you need any help, you're more than welcome on my official Discord server dedicated to my open-source projects.
You can read the online documentation here and take a look at a very simple example.
How to import
//// ES6
import {
gdprGuard, // everything that gdpr-guard exports
// you could also directly import from gdpr-guard as it's a dependency
render,
renderInside,
} from "dom-gdpr-guard"
//// Node
const {
gdprGuard, // everything that gdpr-guard exports
// you could also directly import from gdpr-guard as it's a dependency
render,
renderInside,
} = require("dom-gdpr-guard");
//// Browser
const {
gdprGuard, // everything that gdpr-guard exports
render,
renderInside,
} = window.domGdprGuard;
What's available ?
import { GdprManager } from "gdpr-guard";
declare const renderInside: (target: Element, manager: GdprManager, payload: RenderPayload) => Promise<ReRenderFunction>;
declare const render: (manager: GdprManager, payload: RenderPayload) => Promise<Rendered>;
// render function : (subRenderFunction, savior, gdprItem) => Rendered
declare interface RenderPayload {
renderManager: ManagerRenderFunction;
renderGroup: GroupRenderFunction;
renderGuard: GuardRenderFunction;
}
type Rendered = Element;
type ReRenderFunction = () => Promise<void>;
render
render
is a function that allows to render the GDPR state using the provided render functions, manager factory and
gdpr savior.
interface GdprRenderResult {
rendered: Rendered;
manager: GdprManager;
}
It returns the rendered element so that you can mount it yourself in the DOM. It also returns the manager so that you can query its state for conditional logic.
renderInside
renderInside
is a function that allows to render the GDPR state inside a container using the container as well as the
provided render functions, manager factory and gdpr savior.
interface ReRenderResult {
render: ReRenderFunction;
manager: GdprManager;
}
It returns a function that when called will smartly re-render the GDPR state to avoid the pain of manually handling updates efficiently (it uses DOM diffing). It also returns the manager so that you can query its state for conditional logic.
Savior API
The Savior API is mainly designed for library
developers, therefore you might need an additional library to provide with the savior you may need (
e.g. gdpr-guard-local
for local storage).
Since v3.0.0, you handle the savior however you wish, it is no longer part of the render API.
Design choices
From a design standpoint, it's been a common trend across all my libraries to expose my APIs as asynchronous if users might need to use their own asynchronous code inside. That comes from the idea that integrating asynchronous code inside code that is required to be synchronous makes it really difficult to interface properly.
As such, even though I use the term return
in the previous descriptions, it's more accurate to say that the returned
promise resolves to the described value.
That does not mean in any way that you have to return a promise, we can await
on non-promise values, and they will
resolve immediately. Although, for good measures, if you can mark your functions as async
, that would avoid any issues
and the code inside would still be the same.
One of the advantages of using promises and asynchronous functions as an API designer is that error handling is "covered for free" with the promises' exception propagation mechanisms.
Changelog
V3.1.0
Fixing the deserialization issues caused by bugged versions of gdpr-guard (updated it to 2.3.0).
V3.0.0
The render API was flawed: it re-generated the manager on every render. As such, a decision was made that the user of
this library should get an instance of a GdprManager
before rendering. As such, this package is now fully decoupled
from the Savior API: it's no longer the render API that calls GdprSavior
methods, the user has full control of it.
The fact that you have to have a manager to render also means you can use the Events API from gdpr-guard@^2.2.1
before even rendering anything, which avoids input lags and reduces time-to-first-input.