#javascript #reactjs #react-native #caching #design-patterns
Вопрос:
Во время моей карьеры разработчика в React я видел, что мы можем использовать несколько видов кэша/сохранения в приложении RN.
- Первый, который напрямую предоставляется react native, — это AsyncStorage. Это позволяет нам хранить данные в сохраняемости пользовательского устройства.
- Также мы можем разработать наш собственный кэш в памяти, который может повысить производительность нашего приложения, избегая ненужных запросов к нашему серверу.
- И последнее, что для меня не является кэшем, — это контекст реакции. Этот инструмент отлично подходит для синхронизации маршрутов наших приложений. Например, типичный поставщик пользователей, контекст, в котором мы можем хранить данные пользователей. Я видел, как некоторые программисты тоже использовали этот инструмент в качестве «кэша».
Мой вопрос здесь касается чистого кода. В архитектуре React, которая объединяет эти 3 «инструмента», как мы можем правильно делегировать использование всех из них каждому разделу нашего приложения?
Например, в проекте, в котором есть следующие папки
components/
auth/
AuthForm.js
contexts/
users/
UsersContext.js
screens/
Profile/
EditProfile.js
services/
api/
firebase/
content/
getContentFeed.js
cache/
contentCache.js
users/
getUserData.js
cache/
usersCache.js
Не глядя на третий инструмент, контексты, которые являются исключительно потребляемыми/доступными из крючков/компонентов, где следует использовать каждый «memoizer» (хранилище данных и кэш в памяти) без нарушения какого-либо шаблона или правила «чистого кода»?
Предназначен ли AsyncStorage для использования везде? Я имею в виду внутренние компоненты, крючки, контексты, классы, утилиты, помощники, API … с полной свободой?
А как насчет кэшей в памяти? Например, взгляните на мой «usersCache.js», где я храню данные пользователей, которые получаю с сервера. Как вы можете видеть, я определил свой собственный api для выполнения запросов к серверной части… Итак, если в моем «getUserData.js» Я храню/получаю/обновляю данные из своего кэша, чтобы избежать ненужных запросов, считаете ли вы, что использование такого кэша вне api (внутри компонентов или где-либо во внешнем интерфейсе) является продуктом плохой организации или анти-шаблоном?
Какие-нибудь советы или рекомендации?
Комментарии:
1. Мммм интересно