В React, где мне хранить свои переменные и функции. Я хранил их до операторов рендеринга и возврата (в / в верхней части класса), но, судя по тому, что я видел от других, это не кажется правильным. Я предполагаю, что они должны храниться в методе рендеринга, но над методом возврата, в котором находится HTML-код.
С другой, отчасти связанной с этим заметкой, конструкторы все еще необходимы в React или они неявны.
Я также понимаю, что состояние должно быть по большей части вне родительского компонента, поскольку одно небольшое изменение вызовет повторную визуализацию всех дочерних компонентов, что, очевидно, нежелательно.
Любая помощь с ними была бы потрясающей. Первый вопрос для меня определенно самый важный.
Очень философский вопрос, на который можно дать только такой же философский ответ: «вы должны держать свои переменные там, где они должны быть». Если вы используете var только в одном методе, он должен быть определен в этом методе, если в нескольких - оставить в конструкторе, если в нескольких компонентах - в redux. О функциях: в большинстве случаев проще использовать метод класса, чем определять несколько функций в одном методе
На ваш первый вопрос: stackoverflow.com/questions/41369296/… и stackoverflow.com/questions/41369296/… Второй вопрос: Нет, он вам не нужен, если у вас есть правильный Babel или какая-либо конфигурация транспилятора. Что касается третьего вопроса, я не понимаю. Если вы не храните свое состояние в контейнере (скажите здесь Родитель), то где вы планируете их хранить? В каждом дочернем компоненте? В большинстве случаев вы поднимаете свое состояние, удерживаете его в родительском элементе, а затем передаете его детям. Не думайте так много о рендеринге.
@devserkan Я знаю, что мое приложение все равно будет быстро развлечься, но просто для здравого смысла понимания, почему я даже использую React, разве не идея состояла бы в том, чтобы иметь состояние в каждом дочернем элементе и, в конечном итоге, передавать все эти состояния родителю, чтобы затем отобразить их в последнем компоненте (по крайней мере, для моей текущей цели). Таким образом, я не буду повторно визуализировать каждый компонент каждый раз, когда что-то изменится, и я чувствую, что на самом деле есть цель использования реакции.
@JohnRuddell @ SashaKos Мне нравится идея не использовать конструктор, но по какой-то странной причине мне не разрешено объявлять переменные в верхней части класса. Только функции и состояние. Возможно, поэтому мне нужен конструктор?
Вы можете привести несколько примеров? На самом деле не имеет значения куда ваши функции и переменные, а главное, что они делают и как вы их используете.
@YoungScooter, вы можете использовать переменные без конструктора в поле класса, просто не используйте var, let или const при их определении. Для государственной части, конечно, вы будете использовать состояние где тебе это нужно. Вы правы в этом, но, как вы сказали, чем больше станет ваш компонент, вам понадобится общий родитель, чтобы поднять ваше состояние. Я имею в виду «не беспокойтесь так сильно», просто используйте то состояние, в котором вам это нужно. Если вам это нужно для ребенка, используйте там, если вам нужно в родительском, используйте там.
Вот что меня смутило. Кажется, вы можете определять переменные, но без var, let и const. Для меня это странно. Что по умолчанию, когда вы делаете это в классе без классификатора?
@Aaron По сути, я переношу кучу состояний из дочерних компонентов в родительские, и мне нужно сохранить эти состояния в переменных. Идея состоит в том, чтобы иметь кучу маленьких раскрывающихся компонентов (дочерних элементов) для отправки своего состояния в таблицу (родительскую), родитель хотел бы сохранить эти переменные, и как только он соберет их от всех дочерних элементов, проанализируйте и отправьте поля в таблицу таблица как одна запись. Сохраните эти записи в массиве. Например, где бы я мог хранить этот массив данных. То, как я привык это делать, и то, что кажется самым простым, находится чуть выше класса как глобальная переменная, но я знаю, что это не очень хорошая практика.
Это отличный пример моей путаницы с областью видимости: class App extends React.Component { selectStation; selectedDcp; selectedSensor; state = { selectedMethod: null, startDate: moment(), endDate: moment(), show: false, }; handleDropdown = (selectedOption, id) => { console.info(selectedOption); if (id === 1) selectedStation = selectedOption.label; else if (id === 2) selectedDcp = selectedOption.label; else if (id === 3) selectedSensor = selectedOption.label; }
@YoungScooter, я не знаю, какой по умолчанию, но какой по умолчанию, если вы используете их в конструкторе? this.foo = "foo" становится foo = "foo". Это все, что касается предложения полей классов. Как видите, получение данных от ребенка и сохранение их в переменных - не лучшая практика. Возможно, вы снова сможете сделать это с помощью свойства state.
Я знаю, что это ужасно отформатировано, но в основном переменные в функции handleDropdown не создаются, хотя я просто пытался сделать это в начале, если вы видите selectStation; selectedDcp; selectedSensor;
@devserkan Я знаю, что все время говорю это, и каждый раз это звучит глупо, но я действительно пытаюсь не допустить, чтобы состояния были связаны с родителем. Или я действительно не вижу смысла даже в использовании React, если каждый компонент повторно рендерится каждый раз, когда изменяется небольшой компонент. Почему сохранение переменных класса - плохая практика? Мне не хватает этой части.
@devserkan правильно, вы используете это, а затем можете ссылаться на переменные класса. Кажется, это работает, за исключением того, что вы не можете отображать эти переменные в DOM, не передав их другому дочернему элементу и сделав его одним из их состояний. Кажется, работает для моих целей. Может хоть раз быть доволен.
Хорошо, я не спорю о состоянии так много, потому что все используют React или любую библиотеку по-разному. Для переменных полей класса конструктор запускается один раз при первом монтировании компонента. Тогда как вы планируете снова обновить эти переменные?
Не все дочерние элементы будут выполнять повторную визуализацию, только те, у которых изменились свойства / значения
Также много из того, о чем мы говорили, - это стиль / теория кода ... если вам нужна дополнительная помощь в этом, было бы лучше поделиться репозиторием codepen или github, где я могу просмотреть код и дать обратную связь
@devserkan Я бы подумал, что я мог бы создать и инициализировать их в конструкторе, а затем просто назначить им разные значения, когда мне нужно обновить / изменить их как обычно. Что-то не так?
@JohnRuddell ценю это. Позвольте мне обновить свой код, чтобы дети содержали свои собственные состояния, и я постараюсь опубликовать это на моем github, где вы могли бы его взглянуть и, надеюсь, дать несколько советов / комментариев. Спасибо.
Привет, @JohnRuddell, вот ссылка на код: github.com/willbee28/Wali-redo.git. Я чувствовал, что достиг хорошей точки остановки. Он полностью функциональный, с некоторыми мелкими придирчивыми ошибками. Все мои состояния содержатся в родительском компоненте, что приводит к повторной визуализации каждого дочернего элемента даже при малейшем изменении состояния (только одно поле состояния). Может быть, вы сможете выяснить / дать совет о том, как сохранить каждое состояние у детей, а также, если это способ (я считаю, что это так, поскольку это кажется очень неэффективным).
эй, чувак, я могу взглянуть через несколько часов. Я еще не смотрел, но из того, что вы описываете, вы должны посмотреть на redux. Я могу помочь починить систему и прочее, а также провести вас через это. Есть о чем поговорить, если вы собираетесь добавить что-то вроде redux
Позвольте нам продолжить обсуждение в чате.
верная вещь! отвечу :)
@YoungScooter, как выглядит ваш package.json?
@JohnRuddell { "name": "wali-redo", "version": "0.1.0", "private": true, "dependencies": { "bootstrap": "^3.3.7", "moment": "^2.22.2", "npm": "^6.3.0", "react": "^16.4.1", "react-bootstrap": "^0.32.1", "react-datepicker": "^1.6.0", "react-dom": "^16.4.1", "react-scripts": "1.1.4", "react-select": "^2.0.0", "react-table": "^6.8.6" }, "scripts": { "start": "react-scripts start", "build": "react-scripts build", "test": "react-scripts test --env=jsdom", "eject": "react-scripts eject" } }





конструкторы не нужны. Если вам нужно что-то сделать при создании экземпляра класса, тогда вы должны это сделать ... чтобы ответить на ваш первый вопрос, ответ таков: это зависит / сложно. Я бы определил все функции в самом классе, а не в методе рендеринга. Вы можете определить переменные в рендере, но опять же, это зависит от того, что они делают и что необходимо. Если это более статические жестко запрограммированные значения, то это, вероятно, должно быть свойство класса (которое вы можете назначить в конструкторе: P)