Помощники Класса должны использоваться в разработке нового кода?

Почему вы отображаете все в таблице?

Если я правильно понял, вы хотите отображать только имена, а при нажатии вы хотите показать детали.

Вы можете просто отобразить все имена в виде кнопок:

_renderButtons = items =>
    data
      .slice(
        this.state.activePage * this.state.itemsCountPerPage,
        (this.state.activePage + 1) * this.state.itemsCountPerPage
      )
      .map(item => (
        <>
        <button onClick={this.handleClick}>
          {item.first_name}
        </button>
        {this._renderDetails()}
        </>
      ));

render() {
    var { items, isLoading } = this.state;
    if (!isLoading) {
      return <div> loadding....</div>;
    } else {
      return (
        <div>
          {this._renderButtons(items)}
        </div>
      );
    }
  }
}

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

_renderDetails = () => {
    // check if you need to render
    return(
      <table>
      <tbody>
      <tr>
        <td>{item.first_name}</td>
        <td>{item.last_name}</td>
        <td>{item.company_name}</td>
        <td>{item.city}</td>
        <td>{item.state}</td>
        <td>{item.zip}</td>
        <td>{item.email}</td>
        <td>{item.web}</td>
        <td>{item.age}</td>
      </tr>
      </tbody>
      </table>
    );
}

Надеюсь, это поможет.

Вы можете стилизовать кнопки и таблицы, чтобы они выглядели так, как вам нужно.

10
задан Community 23 May 2017 в 11:54
поделиться

10 ответов

Зависит, что Вы подразумеваете "под новым кодом".

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

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

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

15
ответ дан 3 December 2019 в 13:47
поделиться

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

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

Это - мое мнение любой путь...

8
ответ дан 3 December 2019 в 13:47
поделиться

Microsoft базирующийся LINQ в большой степени вокруг их Дополнительных Методов. В том свете необходимо использовать Помощников Класса в новом коде, если это улучшает код. Посмотрите то, Что хорошее использование для помощников класса? для некоторого хорошего использования.

6
ответ дан 3 December 2019 в 13:47
поделиться

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

3
ответ дан 3 December 2019 в 13:47
поделиться

Извините, не может не быть Captain Obvious на мгновение: Если сами внутренние люди Delphi заявляют, что "они не должны быть просмотрены как средство проектирования, которое будет использоваться при разработке нового кода", затем по определению они не должны использоваться. Они там для расширения VCL в их собственных целях только. Кто еще собирается привести Вам лучшую причину, чем люди, которые записали это?

2
ответ дан 3 December 2019 в 13:47
поделиться

Они походят на дополнительные методы C#. Я сказал бы, что, в то время как дополнительные методы как они полезны, когда у Вас нет способности изменить класс, который необходимо расширить с помощью функциональности, они - плохой способ разработать собственный код. При разработке собственного кода Вы хотели бы, чтобы вся функциональность была расположена в том же файле кода как можно больше, а не распространена через различные классы. Я сказал бы, используют их для того, что они были предназначены для - в основном как декораторы для добавления новой функциональности к закрытым классам - и не используют их в разработке собственного кода.

1
ответ дан 3 December 2019 в 13:47
поделиться

Возможно, хороший подход, который можно использовать, (поскольку я использую его):

  1. Всегда давайте предпочтение наследованию по помощникам класса, используйте их только, когда наследование не будет опцией.
  2. Дайте предпочтение помощникам Класса по пустым глобальным методам.
  3. Если Вы испытываете необходимость в extendend функциональности в больше, чем Единица, попробуйте что-то еще (как обертки класса).

Методы.Net Extensions слишком похожи и, где создано и поддерживается по точно той же причине: Сделайте Расширение базовых классов (а не обновление, который в Delphi. Сеть не была опцией, чтобы попытаться сделать собственный код Delphi довольно "совместимым" с кодом .NET - по моему скромному мнению, это было слишком амбициозно),

Так или иначе помощники Класса Delphi являются все еще настоящим инструментом в некоторых ситуациях.

2
ответ дан 3 December 2019 в 13:47
поделиться

Я соглашаюсь с Vegar в этом: помощники класса как аварийный инструмент. Когда Вы знаете, что они - единственный способ добиться цели в обеспеченное время. Позже, если там время к нему, удалите их.

Я одно время забыло вещь параметризации, и если бы помощники класса не существовали в Delphi 2006, он стоил бы ОГРОМНОЙ ПАРТИИ ВРЕМЕНИ..... С помощниками класса потребовалось 6 часов, чтобы заставить бедра работать правильно. НО, это была чрезвычайная ситуация - помощники класса являются неясной функцией языка, и это создает трудности новым разработчикам следовать за потоком программы.

2
ответ дан 3 December 2019 в 13:47
поделиться

Я использую их все больше как конструкцию дизайна.

Ситуации, в которых я использую их:

  • В клиент-серверной установке я расширяю совместно использованные базовые классы с помощью помощников класса для обеспечения сервера - или функциональность только для клиента.
  • Дополнять классы VCL/RTL (и другой сторонний код) с удобными функциями инструментов.
  • Для работы вокруг различий, когда классы не совместно используют то же дерево наследования (использование помощников позволяет иметь, имеют универсальные свойства Count и Items, например).

На самом деле я желаю, чтобы Delphi принял бы несколько помощников для того же базового класса - я даже зарегистрировал запрос на это, если я помню правильно.

1
ответ дан 3 December 2019 в 13:47
поделиться

Я нашел эту статью очень интересной. Это имеет дело с C++, но основные идеи независимы от языка. Основная суть - то, что глобальные стандартные программы иногда предпочтительны для методов даже в среде ООП. От этой точки наблюдения существует меньше потребности в помощниках класса.

1
ответ дан 3 December 2019 в 13:47
поделиться
Другие вопросы по тегам:

Похожие вопросы: