Стойкие локальные данные на клиентском столе в Meteor

Question

Я работаю с Meteor + React. Вопрос о правильный способ для хранения постоянных данных локально на клиенте.

Скажем, у меня есть компонент List со списком 5 статей:

export default class List extends Component { 
    render() { 
    return(
     <ul> 
     <li><a href='/article1'>Article 1</li> 
     <li><a href='/article2'>Article 2</li> 
     <li><a href='/article3'>Article 3</li> 
     <li><a href='/article4'>Article 4</li> 
     <li><a href='/article5'>Article 5</li> 
     </ul> 
    ); 
    } 
} 

Тогда давайте говорить, что Article компонент должен быть оказаны по маршрутам, как /articleN.

export default class Article extends Component { 
    render() { 
    return(
     <main> 
     .. 
     </main> 
    ); 
    } 
} 

Моя цель заключается в создании VisitedList компонент, который containes список уже посещенных статей.

Мое решение использует пакет persistent-session (link). Есть несколько пакетов, таких как persistent-minimongo, но мне нужно решение . Более 27 тыс. Загрузок u2622:persistent-session заставило меня думать, что он довольно стабилен. Но опять же - я не знаю точно. Теперь о моем решении.

В компоненте Article в части ComponentDidMount Я работаю с постоянными переменными сеанса, такими как элементы массива. Позволь мне объяснить. Во-первых, я проверяю, существует ли переменная Session с keyhistoryLength. Если нет (это означает, что пользователь впервые посещает страницу статьи), я устанавливаю новую постоянную переменную, называемую historyLength, и равен 0. Я использую эту переменную для хранения длины моей собственной «массива» моей истории.

Затем я проверяю, находится ли текущая статья в истории, а если нет - добавьте ее в историю. Добавление к истории на самом деле - устанавливает новую постоянную переменную с keyhistoryN, где N = historyLength.

Проще всего смотреть на код, а не на мои попытки объяснить это словами.

Так код Article компонента:

export default class Article extends Component { 
    componentDidMount() { 
      if (Session.get('historyLength')) { 
       console.log('history exists'); 
      } else { 
       Session.setPersistent('historyLength', 0); 
       console.log('first history init'); 
      } 

      var articleInHistory = false; 

      for(i = 0; i < Session.get('historyLength'); i++) { 
       var key = 'history' + i; 
       if(Session.equals(key, this.props.articleName)) { 
        articleInHistory = true; 
        console.log('already in history:', i); 
       } else { 
        console.log(i, 'product is not in history'); 
       } 
      } 
      if(!articleInHistory) { 
       var newHistoryKey = 'history' + (Session.get('historyLength')); 
       Session.setPersistent(newHistoryKey, this.props.articleName); 

       var curHistoryLength = Session.get('historyLength'); 
       Session.setPersistent('historyLength', curHistoryLength + 1); 
      } 
    } 
    render() { 
    return(
     <main> 
     .. 
     </main> 
    ); 
    } 
} 

Этот код работает правильно. Я могу получить доступ Session.get('historyLength') в любом компоненте, а затем получить имена посещаемых статей с for цикла:

for(i = 0; i < Session.get(historyLength); i++) { 
    let key = "history" + i; 
    console.log(key, Session.get(key)); 
} 

Наконец, VisitedList компонент:

export default class VisitedList extends Component { 
    renderVisited() { 
    var visitedArticles = []; 
    for(i = 0; i < Session.get(historyLength); i++) { 
     let key = "history" + i; 
     visitedArticles.push(Session.get(key)); 
    } 

    return visistedArticles.map((each) => { 
     return <li> {each} </li> 
    } 
    } 
    render() { 
    return(
     <ul> 
     { this.renderVisited() } 
     </ul> 
    ); 
    } 
} 

Мой вопрос: ли мое решение правильным способом хранения и использовать локальные постоянные данные? Этот пример прост, а не из реального проекта, но он показывает проблему и решение проблемы.

Я собираюсь построить такой блок истории в моем проекте и корзину покупок. Поэтому, если есть более эффективный, быстрый и правильный способ решения этой проблемы, я хочу знать об этом до начала. Спасибо за ответ!

Answer 1

Использование Meteor Session в настоящее время несколько обескуражено (поскольку оно загрязняет глобальное пространство имен, может быть сложно отслеживать его содержимое и сохранять его в чистоте и т. Д.). Поскольку u2622:persistent-session работает с объектом Meteor Session, я не думаю, что это будет самый вероятный вариант будущего доказательства. Поскольку вы используете реакцию, считаете ли вы вместо этого redux для управления вашим клиентом? Redux быстро (если он еще не стал) становится самым популярным контейнером состояния приложения в пространстве javascript/react. Redux сам по себе не является постоянным, но есть несколько дополнительных библиотек, которые предоставят вам возможности сохранения, например redux-persist.