Feature: Notification Placeholder component

[alaca]

Description

This PR adds a new NotificationPlaceholder component to the form builder library.

Backend impress-org/givewp#7356

There are two types of notifications, user and system.
User type notifications when dismissed, won't be shown again only to the user that dismissed the notification, while system notifications when dismissed, won't be shown again to any user.

Testing Instructions

import {NotificationPlaceholder} from '@givewp/form-builder-library';

function App() {
    return (
        <div>
            <h1>
                My app title
            </h1>
            <NotificationPlaceholder
                id="notificationUniqueId"
                render={dismiss => (
                    <div>
                        <p>User notification - if dismissed it won't be shown again to this user only.</p>
                        <button onClick={dismiss}>Dismiss</button>
                    </div>
                )}
            />
            <NotificationPlaceholder
                id="sysNotificationUniqueId"
                type="system"
                render={dismiss => (
                    <div>
                        <p>System notification - if dismissed it won't be shown again to any user.</p>
                        <button onClick={dismiss}>Dismiss</button>
                    </div>
                )}
            />

            <div>
                My app content
            </div>
        </div>
    );

}

Pre-review Checklist

• Self Review of code and UX completed

[jonwaldstein]

I'm wondering if we should elevate some of these specific endpoints to props so they can be more agnostic and changed during implementation. What do you think?

[alaca]

The whole idea behind this is that we have a centralized place for handling dismissable notifications. Having endpoints as props means you will have to set the endpoint each time you use this component, which is unnecessary because we already have registered endpoints that won't change. If you want to set a different endpoint, then you will also have to implement the backend logic for that endpoint. For me, I just want to import the component and use it, and not worry about where the requests will go.

[jonwaldstein]

I totally understand that, in terms of ease of use that would be great!

What i'm really wrestling with is the GiveWP dependency that this component will be bound to (and this package in general). This was something we talked about when first making this package and being careful about using the window to access things like the currency (in the currency component) so we decided to make those props so the components are more agnostic.

For example, if an add-on is attempting to use this component they would have to require a specific version of GiveWP that this component depends on. It's funny because that was the reason we created this library in the first place, so add-ons are not depending on the window to access components from GiveWP.

That's also where the discussion around a GiveWP data store came up so we're not relying on the window for data as well.

So, the question i'll raise here is: how do we create a library of re-usable components that are agnostic enough to be used throughout our add-ons without necessarily being bound to specific GiveWP versions?

I'd love to chat about this with you in person 😄

[alaca]

@jon Good question. I remember we talked about creating a Give custom store and I think that would be a good approach. So instead of mounting everything to a window object, we can create a custom store and have everything there. The only potential drawback with this is that we won't be able to fully interact with the store outside the FB context - which makes sense.
Example: This PR - notifications.
I want to add a dismissible notification component in the Donation Form list table app. If I try to use the Give custom store outside the FB context, which in this case I do, I won't be able to use useSelect or useDispatch hooks. We can still dispatch or get the data outside the FB context using dispatch and select, but since we are outside the FB context, the component from which we call these functions won't re-render. This is an edge case, but still something to have in mind.

I can put together a simple store (proof of concept) next Friday, and we can start from there.

[jonwaldstein]

I feel like we should have some options for choosing retrieval from session storage, server or both - what do you think?

[alaca]

I'm thinking of changing this to use localStorage instead of sessionStorage. The whole purpose of caching the notification data in sessionStorage is to avoid making requests to the server each time the component is loaded.
What we might consider is having an option to select where we want to store the notification data. Currently, everything is stored in user meta, which is great for 99% of cases, but maybe we will want to have a dismissable notification that can be dismissed for all users, not just for the current one. For example, if the user did some upgrade action that can be done only once, then it doesn't make sense to show that notification to all users if action is already taken and notification is dismissed.

[alaca]

I removed the fetch entirely and I'm loading data from the window object. I don't have to cache data anymore, or fetch notifications from API. This is a much cleaner and simpler solution.