Mike_Ro
@Mike_Ro
Python, JS, WordPress, SEO, Bots, Adversting

Как правильно в ReactJS отрисовывать компоненты и показывать загрузку, при запросе данных со стороннего ресурса?

Предположим, у нас имеется родительское приложение, которое запрашивает продукты со стороннего ресурса. Пока идет запрос, нужно показывать загрузку.

Как я вижу решение текущей задачи данный момент:
1. Родитель запрашивает все сам и выставляет статус "показывать или нет" дочернего компонента.
2. Дочерний компонент ждет статус, и на основе одного из статусов - показывает заготовленный DOM.

В связи с этим пару вопросов:
1. Как правильно отрисовывать компоненты, которые должны показывать запрошенные продукты, если они пока не загружены?
2. Как и где правильно размещать индикатор загрузки?

Хочу увидеть алгоритм, что где расположено и когда вызывается. Для наглядности всего процесса, написал пример "как это вижу я".
class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      products: [],
      sectionProductsVisible: "hide",
    }
  }

  // при старте, запрашиваем продукты и разрешаем показ секции с продуктами
  componentDidMount() {
    this.setState({sectionProductsView: "preloader"});

    this.get_products()
      // если запрос успешен, то добавляем список продуктов в состояние, а так же меняем статус показа секции с продуктами
      .then((products) => this.setState({...products, sectionProductsView: "show"}))
      .catch(() => this.setState({sectionProductsView: "error"}));
  }

  // метод получения продуктов
  get_products = () => {
    // предположим, это продукты, которые мы получаем fetch-ом
    const products = [{id: 1, title: "Чистейший колумбийский JS"}];
    
    return new Promise((resolve, reject) => {
      setTimeout(() => {
        if(products.length) resolve(products);
        else reject();
      }, 1000); // имитация задержки при получение продуктов
    });
  };

  render() {
    const {sectionProductsVisible} = this.state;
    return <App_Template visible={sectionProductsVisible}/>;
  }
}


// компонент шаблона секции с продуктами
function App_Template(props) {
  const {
    visible = "hide",
  } = props;

  switch(visible) {
    case "preloader": // получение продуктов, результат получения не известен (показываем загрузку)
      return null;

    case "show": // если продукты получены успешно
      return null;

    case "error": // если при получение продуктов произошла ошибка
      return null;

    case "hide": // по умолчанию, скрыт
    default:
      return null;
  }
}
  • Вопрос задан
  • 197 просмотров
Решения вопроса 1
@vs101ff
Frontend разработчик
Я не очень помню React.JS классовый, боюсь ошибиться.

Поэтому могу просто порекомендовать пример с хуками: https://github.com/kentcdodds/react-hooks/blob/mai...

Здесь описание: https://github.com/kentcdodds/react-hooks/blob/mai...

Классовый React.JS сейчас не используется (используется только в поддержке старых компонентов).
И вообще, я думаю, вам определенно стоит пройти курс https://epicreact.dev/ , а классовый React.JS миновать.
На github есть репозитории с *.md материалами, их и блога более чем достаточно, и то, все не нужно.

Предупреждаю, у меня нет коммерческого опыта разработки React.JS.
Несколько позже, если нужно, скину статьи из документации, которые, на мой взгляд, необходимо изучить после курса Кента Доддса.

Отрывки по Software Design:

https://www.livelib.ru/book/1003548149-refaktoring...

Фундаментальное практическое правило гласит: то, что изменяется одновременно, лучше хранить в одном месте.


Мы структурируем программы, чтобы облегчить внесение в них изменений;

Планируя изменение, мы хотим иметь возможность перейти в определенную точку программы и внести изменения именно в ней.



Когда я сталкиваюсь с кодом, который имеет дело с двумя разными задачами, я ищу способ разделить его на отдельные модули. Я стараюсь выполнить такое разделение, поскольку, если мне нужно будет вносить изменения в программу, мне придется иметь дело с каждой задачей в отдельности и не потребуется держать их обе в голове. Если мне повезет, то, возможно, будет достаточно внести изменения только в один модуль без необходимости запоминать детали другого.



модульность, которая обеспечивает возможность вносить множество изменений в программу, в то же время понимая лишь небольшую ее часть. Чтобы добиться этой модульности, я должен убедиться, что связанные программные элементы сгруппированы и связи между ними легко найти и понять.



Если у меня хороший набор структур данных, соответствующих поставленной задаче, то реализующий поведение код прост и понятен. Плохие структуры данных приводят к большому количеству кода, работа которого заключается просто в обработке плохих данных. И это не просто сложный код, который трудно понять; это также означает, что структуры данных скрывают то, что делает программа.


И главы 1 - 4.

Из книги https://www.ozon.ru/context/detail/id/136939101/

Очень важна легкость внесения изменений в систему при изменении требований. Для этого нужно использовать наиболее простые решения:
программная сущность (класс, модуль, метод) должна по возможности решать лишь одну задачу, но делать это хорошо.

Чем меньше у метода, класса или модуля вспомогательных задач, тем ниже вероятность случайных изменений.


Но нужно спрашивать себя:
не приведут ли меня принципы и паттерны в мир ненужной сложности (overengineering): стал ли мой дизайн после внесения изменений проще? Не решаю ли я проблему, которой на самом деле не существует?
Не попал ли я в сети преждевременного обобщения (premature generalization)?


Полезно будет пройти часть 4.

https://kentcdodds.com/blog/when-to-break-up-a-com...

Совершенный код С. Макконнелла, я читал с с. 76 по с. 152, про остальное ничего сказать не могу.

Р. Мартин Чистый код, я читал Функции, Содержательные имена и Обработка ошибок, про остальное аналогично, не знаю. SOLID у него плохо объяснен.

Понравившиеся проекты:
UI библиотека для CMS Sanity https://github.com/sanity-io/design
CMS Sanity (Фронтенд код сейчас в процессе перехода на @sanity/ui. Наверное, будет лучше изучать по pull request'ам) https://github.com/sanity-io/sanity

По чтению кода: https://www.youtube.com/watch?v=6J4ZejMsKKY

P.S. Не знаю, что из этих книг нужно для Junior Frontend разработчика. Мое мнение лучше воспринимать на половину серьезно, т. к. я где-то между Junior и Middle). Работал к этому времени только в бэкенде.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы