Visited frequently

[nikdo]

The user can see names of the frequently visited spots on the homepage to quickly navigate to them.

• persist visits in local storage
• sort only by the number of visits (weights later in Weighted frequent spots #124)
• limit number of displayed spots to 12
• spots with a single visit are displayed too
• when no spots visited, do not show heading

[nikdo]

Subtasks

• research local storage
  • find out what are size limitations for local storage
  • calculate visit size (datetime + spot ID)
  • calculate how many visits I can store
  • learn how to use local storage
  • find out redux best practices for local storage
  • refresh middleware knowledge
  • find out if redux-persist updates only when necessary
  • decide whether to keep visits in redux store
  • read again about types of data in store
• add event on spot detail load
• define visits store shape
• add visit to store
• replace number of visits by date
• calculate spots
  • return all visited spot IDs
  • use reselect
  • map to spot data
  • sort by # of visits
  • return only top 12 spots
  • sort same number of visits by last visited date
• show frequent spots on homepage
  • IDs only
  • IDs with links only
  • name, region, country
  • dispatch spotsVisited only after spot is fetched
• add visit to local storage
• style frequent spots
  • create component for container
  • upgrade storybook
  • upgrade stories to CSF
  • upgrade outdated packages
  • upgrade storybook again
  • create stories
  • consider abstracting from SpotTitle, SearchSuggestion and this new component
  • style list for mobile
  • fix list item vertical rythm
  • find out how to do gradient line
  • fix gradient in safari: not from transparent, but rgba
  • rename component to SpotList
  • add separator
  • read two articles about 8pt grid
  • add and style heading
    • add heading
    • style heading
    • hide heading when no frequent spots
    • add heading icon
    • learn how line-height affects height
    • fix vertical rhythm
    • decide whether to set SVG size to 1em
    • fix heading space before and after
  • stretch to full width
    • see layout-section styles
    • read article about 8px grid
    • learn about Bootstrap grid
      • mentioned as a good base for 8px grid
      • how to customize it for 8px
    • decide how to stretch to full width
    • center list correctly
    • align heading
  • style hover
  • fix header content scrolling
  • style list for larger screen sizes
  • add borders
  • style hover for larger screen sizes
  • fix header fold/unfold animation (slow it down to see)
• fix sliding header before spot is loaded
• plan checking local storage size

---

• use storybook args for all stories
• find out why am I not using redux-thunk
• use redux-persist transformation to have normalized visits (id: { _id, visits }) while keeping compact local storage shape (id: [visits])
• separate data, communication and control states in redux store
• normalize state using normalizr
• consider using redux-toolkit

[nikdo]

Takeaways

Web storage size limits

Web storage size per origin is roughly 10MB. But it can be configured to less or it does not have to be available at all.

JavaScript date object takes 26 bytes. Spot ID 24 bytes. Object containing both ~70 bytes. (How to calculate it)

Local storage with 10 MB quota can hold up to ~ 143.000 id-date pairs. Even with 50 spot visits daily it will take 8 years to fill the available storage.

If the format won't be id + date pair for each visit, but id + array of dates, it will take even less space.

Conclusion: There is no need to limit or clear visits from storage. User will change browser, delete cache or I will move the visits to database before anyone hits the limit.

Redux and localStorage

The usual approaches are:

1. Subscribe to store changes and save (part of) it to local storage.
2. Use redux-persist.
3. Write middleware to do that.

Even though web storage size limit won't be a problem, object containing all visits will be huge and JSON.stringify is performance-heavy. Hence saving visits to local storage should happen only when new visit is recorded.

Doing it in middleware would mean it happens before the store is changed. Doing it in subscribe would mean we cannot distinguish visits store tree updated from other updates.

redux-persist updates only keys that have been changed.

I can see two options:

1. Do not have visits in redux, keep them only in local storage. This works as a single source of truth, similar to what I do with URL. Change local storage on "record visit" action.
2. Keep visits in redux. Use redux-persist to save this part of redux state to local storage. It optimizes local storage writes, it should not be a problem.

Let's use redux-persist.

Misc

Accessing local storage should be wrapped in try-catch block to solve gracefully all possible problems like missing or full local storage.

Be careful that local storage shape might be outdated. This is why redux-persist provides migrations config.