NUX: bootstrap a NUX module

[youknowriad]

refs #3670 Still WIP but worth a review

This PR bootstraps the work on the NUX.

Functional Side:

• This doesn't do much aside adding an example "dot" tip for the inserter. It's just an example for now. The main purpose of this PR is to setup the technical aspects
• a DotTip show up only once. Once you close it or reload the page, it will never show again.

Technical Side:

• I added a nux module allowing any WP module to add "tips".
• This module can be used by using a Provider and then inserting several DotTip components in the different places we want to show tips. (Other type of tips will be added later)
• This module uses the data module to store a local state
• This local state is persisted to local storage for now. This is not great, it's better if we could persist this server side but the "user preferences" API is not good enough to store non string values. It could be changed later.
• I've moved the persist enhancer to the data module as helpers and updated it to be able to use it several times.

Testing instructions

You can reset the state of the already shown dots by clearing the local storage.

[chriskmnds]

Any chance this would return undefined?

[youknowriad]

good point, I think it's possible which still produces a "falsy" value but might better to force false

[karmatosed]

Firstly, thanks @youknowriad for a great start on this! I really do like the pulsing dot. I am not so sure we need to add in a speech arrow to the block though as that adds in confusion, could we have more like the mockup in future iterations? Similarly, could it be to the side and wider? These are all cosmetic suggestions.

Here is a visual of what we have right now:

Excited to see how this shapes up more!

[karmatosed]

Added a few visual changes I'd like to see as a comment.

[aduth]

Does this need to be a separate module, or merely a small set of components files? Is it required to be this way because it manages its own state (and primarily to take advantage of existing persistence helpers)? I guess this is in line with the thinking that an individual module has 0 or 1 stores? Would we ever consider accommodating the need for component stores without needing to extract into separate modules?

[youknowriad]

Is it required to be this way because it manages its own state (and primarily to take advantage of existing persistence helpers)?

Yes, that's the idea. The persistence though is just a convenience though. I'd prefer if we had a server-side API for user preferences here.

Would we ever consider accommodating the need for component stores without needing to extract into separate modules?

The advantage of separating modules is the possibility to use it in other pages than the "editor" page. This could be useful in any WP page.

Does this need to be a separate module, or merely a small set of components files?

My understand of the components module is a set of stateless generic UI modules.

[youknowriad]

Closing this for now, I'll revisit on clean PR when the time comes