[ChrEx] Restructure data

[mrvivacious]

Is your feature request related to a problem? Please describe. Right now, the user data is kept in chrome.storage without any clear data access protocols. For instance, to get the redirect links, we issue a get(null) to get all the values saved in storage and then loop over them to grab just the URLs. The loop is necessary to sift between URLs and firebase related stuff / user metrics / literally any other data hahaha it's not ideal or friendly for future feature introductions. Suppose we had an API and a data scheme, we could introduce more APIs and storage-dependent features much easier compared to the current state of PorNo!.

Describe the solution you'd like Data scheme implemented. Code in place to port users' current data into the new scheme (to avoid loss of user data during migration). APIs / DAO implemented. Shipped to the chrome web store.

Describe alternatives you've considered If we keep going with the current data practices, we are digging a deep hole of if-else conditions....

Additional context File for reference

Summary

As a user, developer, ....? I want dark mode, custom banlist, etc So that using PorNo! becomes easier

Work description

• [ ] Step one
• [ ] Step two (link to code sample, if relevant)

Exit criteria

Testing and verification of intended changes + more info

Feature is released in ChrEx / Android update

[mrvivacious]

Some planning:

chrome storage local:
realtimeBannedLinks: list of strings

chrome.storage.sync:
userData
|- redirectLinks: object with urls as keys and labels as values
|- lastRedirectTimestamp: long, used for Streak calculation
|- redirectHistory: list of longs, can be used if/when a calendar is ever implemented
|- userBanList: user custom list of sites to redirect from
|- ???

To smoothen this transition, a few ideas:

Add the links from firestore db to the source code and empty the db list. This way, all those sites are available in-app and keeps chrome.storage.local from inflating with data it doesn't really need to hold.

Test the speed of accessing redirect links when theyre a nested object. Redirection time is the a very very especially important metric, haha.

Figure out how I can improve the UI for the chrEx in general, to make space for the custom banlist feature.

[mrvivacious]

for speed, can do something like:

chrome.storage.sync:
redirectLinks: object with urls as keys and labels as values (introduces JSON.parse in the URL evaluation step)
userBanList: user custom list of sites to redirect from

userData
|- lastRedirectTimestamp: long, used for Streak calculation, not dependent on performance
|- redirectHistory: long[], can be used if/when a calendar is ever implemented, not dependent on performance
|- ???

[mrvivacious]

sample methods to make API calls easier, courtesy ChatGPT:

getUserRedirectLinks (if empty, redirect to my github as the default) setUserRedirectLinks (on popup submit button click)

getUserBanList (first check against the provided lists in the app. then check against user list.) setUserBanList (on Ban This Site? popup submit button link)

getUserData (for streak in the popup. and eventually history i guess, so a history page?!?!) setUserData (can initialize lastRedirectTimestamp as time of install. can init redirectHistory as [empty] at time of install)

[mrvivacious]

first, migrate the existing streak data into a UserData object. then push an update, to make sure we can actually migrate shit without things breaking horribly Link to streak API call in codebase

then, the user banlist if it already isn't an object.

finally, the redirect links.

[mrvivacious]

note: we dont need lastTimestampSynced bcuz we have the history... funny how dat happens