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

post 2.0 feature: smarter close #38

Open
mariusa opened this issue Dec 22, 2022 · 2 comments
Open

post 2.0 feature: smarter close #38

mariusa opened this issue Dec 22, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@mariusa
Copy link
Contributor

mariusa commented Dec 22, 2022

Desired UX:
As a user visiting a site, I want to

  • be able to close an announcement and never see that again (in that browsing session or never?)
  • see multiple announcements if more are published, even though I closed others

To make this possible, I propose for h-bar

  1. When close is clicked, save in sessionStorage or localStorage an md5 hash of that announcement as being closed
  2. When initialized with multiple announcements, skip those already closed

This behavior could be enabled when passed a storage option, which developer can set to either sessionStorage or localStorage.

What do you think?

@ReeceM ReeceM added the enhancement New feature or request label Dec 22, 2022
@ReeceM
Copy link
Owner

ReeceM commented Dec 22, 2022

Hi @mariusa,

Thank you for your interest in features for the package. It's quite nice to know someone is using it.

So for tracking which ones were closed I was leaning towards doing a hash on the content originally. With that though I am thinking of providing two ways to go about it:

  • From the package side there will be a default way of just hashing the entire announcement object (text, links and such) then this is what will be used.

  • The other way is that a user can provide their own hashing function that will return the object that should be hashed, if they want to use a specific value that should go through the md5 hash.

With providing a new storage option on the main config will be alright as it won't be a breaking change.

When you say a dev can set the storage option, is that just a 'local' / 'session' string. Or providing the actual function? I prefer just a text option, the internals can handle browser compat then.

@mariusa
Copy link
Contributor Author

mariusa commented Dec 22, 2022

Thank you Reece for building this :)

I think only the title / content needs to be hashed. no need for custom hashing function. Even if there's an edge case where admin changes the link, but keeps same title, users won't realize that's changed and will simply close again.

With the other proposal to have content, it would be just content to be hashed :) And it doesn't need to be md5, just something very fast, we don't care about some edge case collisions, this isn't a crypto lib. eg https://gist.github.com/hyamamoto/fd435505d29ebfa3d9716fd2be8d42f0

I prefer just a text option, the internals can handle browser compat then.

Ok, that' great!

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

When branches are created from issues, their pull requests are automatically linked.

2 participants