[Front-End] Implement persistent caching layer in the project

[chadstewart]

Type of feature

Select the type of feature request, the lowercase should also be the PR prefix.

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation Update
• 🎨 Style
• 🧑‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🤖 Build
• 🔁 CI
• 📦 Chore (Release)
• ⏩ Revert

Current behavior

Is your feature request related to a problem? Please describe.

Currently the project is leveraging caching through the use of the SWR package. Through this issue we would like to explore a more robust caching solution.

Suggested solution

Describe the solution you'd like.

Here are some ideas based on the research I did:

• SWR provides caching for data that uses the hook but it is an in memory cache and will clear as soon as the application is closed. I've found an article describing implementing a persistent cache using SWR here
• @bdougie has implemented a solution that is also a persistent cache in the open-sauced repo, detailed here
• Building a whole new caching solution ourselves leveraging React Hooks and Local Storage
• @bdougie did some work on this on stream and found this article was helpful

Code of Conduct

By submitting this issue, you agree to follow our Code of Conduct.

• I agree to follow this project's Code of Conduct

Contributing Docs

If you plan on contributing code please read - Contribution Guide

• I agree to follow this project's Contribution Docs

[chadstewart]

Hey @0-vortex, just created an issue for the caching discussion we had yesterday. Just wanted to make sure if this was the idea you wanted and I added some preliminary research I did.

Let me know if this was your thoughts on what we need for caching and what you think about some of the solutions presented so far.

[brandonroberts]

Catching up on context here, but the options seem reasonable to me. How long do we expect the cache to persist before expiring? And how much data are we caching from the API?

[0-vortex]

Catching up on context here, but the options seem reasonable to me. How long do we expect the cache to persist before expiring? And how much data are we caching from the API?

IMHO that's all to be discussed/tested, the limitation being, if we have a list of 10 repos, we need to hit the contributors endpoints for each of the repositories, so 10 times; using stale revalidation in the background we can improve user experience by using any cache value right now, while fine tuning the details based on whatever we find to work best :D

[bdougie]

Spent some time working on this for the hot repo on stream. This article in the docs was helpful in understanding

Currently the project is leveraging caching through the use of the SWR package. Through this issue we would like to explore a more robust caching solution.

Per the OP, we can add a provider that connects to local storage. Either localstorage directly or a mobx, redux, useContext etc. Correct me if I am wrong, the provider to localstorage is what is needed.

[0-vortex]

Spent some time working on this for the hot repo on stream. This article in the docs was helpful in understanding

Currently the project is leveraging caching through the use of the SWR package. Through this issue we would like to explore a more robust caching solution.

Per the OP, we can add a provider that connects to local storage. Either localstorage directly or a mobx, redux, useContext etc. Correct me if I am wrong, the provider to localstorage is what is needed.

Exactly! 👍

[bdougie]

I spent some time Friday messing with this and localStorage and it didn't quite work. My thought is to put the ContextProvider in there instead. But I question if if the initial cache is not enough.

Pre-1.0 example using Context

[OgDev-01]

Here are some options i would consider us looking into for solving caching in this project

• Switching to Recoil for state management
• It has a built in support for Localstorage persisting. recoil-atom-effects#local-storage-persistence

What Makes Recoil Different?

Recoil has unique advantages compared to other state management libraries used for React applications.

• Fewer boilerplates.
• Simple to learn and understand.
• The data flow is simple to comprehend.
• More in line with React.
• Asynchronous data is queried using pure functions.
• Hooks help us to retrieve and update states.

Link to their documentation Recoil

I've used this on some projects and understand quite to an extend how this works.

FWIW, I think we should check this out and see if it will be a good solution 🙏🙏

[0-vortex]

• Switching to Recoil for state management

This is worth testing for state management, I've seen the other part of this called refine too.

• It has a built in support for Localstorage persisting. recoil-atom-effects#local-storage-persistence

This doesn't solve the SWR issue that we are having and it would not make sense to overload our current fetchers (that can do mutation outside of our global state) but it is definitely useful for some of the private information that belongs to a user that we would likely not cache with nextjs SWR always.

• Hooks help us to retrieve and update states.

Not sure if this is a real plus but it's the only one I count 🍕

Overall I think it's worth considering but during the state management talks and for that purpose only, making the global and application state that doesn't fully rely on github data more easier to manage and develop with! 👍

[github-actions]

🎉 This issue has been resolved in version 1.8.0-beta.5 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀