Реагировать Сравнение функций компонентов - PullRequest
Новая
       5

Реагировать Сравнение функций компонентов

0 голосов
/ 11 сентября 2018

У меня есть форма, которая стала действительно интенсивной. Примерно 20 входных данных, которые включают в себя несколько сборщиков дат, API-адреса местоположений Google, значения правил и т. Д. Поскольку очень немногие из этих входных данных могут обновляться напрямую, без какого-либо преобразования. Я успешно преобразовал компонент из компонента с состоянием, который слишком много делал в методах жизненного цикла (теперь с помощью formik для управления значениями), но я пытаюсь определить, какой лучший способ определить необходимые вспомогательные функции (например, updatedDateWithTime, formatAddress) с точки зрения производительности и стиля, и может думать только о нескольких вариантах.

Вариант один: функциональные выражения внутри функционального компонента: 

const MyHugeForm = () => {
  const helper1 = () => { console.log("thing1") }
  const helper2 = () => {console.log("thing2") }

  return() {...}
}

Опция 2: как «глобальные переменные», определенные в файле, вне функции: 

helper1() => console.log("thing1");
helper2() => console.log("thing2");

const MyHugeForm = () => {
  return() {...}
}

Вариант 3: в качестве встроенных функций стрелок, используемых внутри дочерних компонентов (то есть разбить каждый вход на собственный компонент и передать подпорки вниз) 

const MyHugeForm = (props) => {
  return() {
    <div> 
      <DateInput startDate={props.startDate} />
      <LocationInput location={props.googleLocation} />
    </div>
  }
}

const DateInput = (props) => {
  <DatePicker onChange={() => console.log("thing1")} />
}

const LocationInput = (props) => {
  <input onChange={() => console.log("thing2")} />
}

Кажется неправильным определять примерно 20 из этих вспомогательных функций за пределами (но в том же файле, что и) функционального компонента, но определение их как выражений функций внутри компонента выглядит хуже, а из двух вариантов хуже для производительности. Разбиение частей на дочерние компоненты выглядит как правильный шаблон с точки зрения уменьшения сложности 600-строчного функционального компонента, но если дочерние элементы просто определяют одинаковые функции, встроенные в их рендеринге, разве это не то же самое?

1 Ответ

0 голосов
/ 11 сентября 2018

Мое предложение было бы создать вспомогательный класс с некоторыми статическими методами, где вы можете передать входные html-события в качестве параметров: 

export default class MyHugeFormHelper {
    static onChangeHandler(e) {
        // do stuff here
    }

    static onInputHandler(e) {}

    static onSubmit(e, callback) {
        // you could pass a callback function from the logic of your component
    }
}

Затем в вашем компоненте вызовите этот метод класса следующим образом: 

import MyHugeFormHelper from './MyHugeFormHelper';

 const DateInput = (props) => {
     <DatePicker onChange={MyHugeFormHelper.onChangeHandler} />
 }
...