JSX: как разделять логику и отрисовку в разметке, сгенерированной методом map

Или другими словами: разделяйте логику и отрисовку.

Прошу прощения, выскажу сугубо свое мнение. Это как-то слишком коротко и просто для статьи. И как заметили выше - если обобщить, то это просто разделение логики и верстки, что должно быть аксиомой и не является открытием. Более того, эта функция с проходом по массиву, подсчётами, псевдо проходами по массиву внутри прохода (to lowercase, includes) будет исполнятся на каждый rerender, хотя в этой трате ресурсов нет необходимости, ведь вы сказали, что данные просто пришли с бэка. Значит после того как они пришли с бэка нужно просто один раз пройтись и сформировать нужную структуру и отдать в этот компонент как пропс, более того убрав абсолютно ненужное тут усложнение в виде карирования. И если это все вынести в отдельный хук или файл например с названием utils/visualLogic, то код станет чище, понятнее для других разработчиков и более производительный.

Не могу понять, почему строки с ФИО остаются в нижнем регистре. Я понимаю, что условный пользователь может ввести все как зря, но почему потом имя не приводится к первой заглавной? Что делать с корнер-кейсами типа семитских или грузинских отчеств? Не имеет ли смысла запихнуть какую-то проверну не на этапе рендера, а на этапе ввода, и затем уже хранить правильные ФИО в базе, а тут не приводить их к нижнему регистру.

Во втором примере можно поправить опечатку retrun => return

В случае более-менее большого проекта имеет смысл запомнить обработанные данные, чтобы не перегенерировать их при ре-рендеринге, а вывод элементов списка убрать в отдельный компонент.

  const processedUsers = useMemo(() => preprocessUserData(users), [users]);

  return (
    <ul className="list">
      {processedUsers.map((user) => (
        <UserListItem key={user.id} user={user} />
      ))}
    </ul>
  );

А почему вы не использовали паттерн RenderProps ?
C его помощью можно гибко резделять логику и отображение. И отдельно тестировать доменную и тестировать логику будет намного проще.

type User = {
  name: string;
  // другие пропсы
};
// Чистая функция, можно протестировать
function composeUser<T extends User>(
  user: T,
): { fullName: string; date: string; statusColor: string } {
    const fullName = `
    ${user.name.name}
    ${user.name.patronomic ? user.name.patronomic : ''}
    ${user.name.surname}
  `.toLowerCase();
    const date = user.regestrationDate ? moment(user.regestrationDate) : null;
    const statusColor = ["В сети", "Не в сети"].includes(user.status.description)
      ? STATUS_COLORS[user.status.value]
      : "neutral";

  return { fullName, date, statusColor };
}

const Users: FC<{ data: User[]; renderFn: (user: User) => void }> = ({
  data,
  renderFn,
}) => {
  return <>{data.map(renderFn)}</>;
};

const App: FC = () => {
  /// откуда то получаем users

  return (
      <ul className="list">
        <Users
          data={[{ name: "username1" }, { name: "username2" }]}
          renderFn={(c) => {
            const { fullName, date } = composeUser(c);
            return (
              <>
                <li>{fullName}</li>
                <li>{date}</li>
              </>
            );
          }}
        />
    </ul>
  )
}

proxyUserVars

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

Всё то же самое, только чуть по-другому (+фрагмент, забытый незаслуженно):

const getUserVars = (user) => ({
  fullName: `
    {user.name.name} 
    {user.name.patronomic ? user.name.patronomic : ''} 
    {user.name.surname}
  `.toLowerCase(),
  
  date: user.regestrationDate 
    ? moment(user.regestrationDate)
    : null,
  
  statusColor: ['В сети', 'Не в сети'].includes(
    user.status.description,
  )
    ? STATUS_COLORS[user.status.value]
    : 'neutral',
});

return (
  <ul className="list">
    {users.map((user) => {
      const {fullName, date, statusColor} = getUserVars(user);
  
      return (
        <Fragment key={user.id}>
          <li>{fullName}</li>
          <li>{date}</li>
          <li className={statusColor}>{user.status.description}</li>
        </Fragment>
      );
    ))}
  </ul>
);

Вообще, поддержу мысль @edtech, что правильнее делать отдельный UserListItem . А если список может меняться, то React.memo для ЛистАйтема будет совсем не лишним.

{users.map(user => <User user={user}/>)}

В самом компоненте User будет разметка одного айтема, а логику вынесем в хук useUser.

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

Выносим список в <UsersList />, по-необходимости мемим преобразования внутри и успешно рисуем вью. Как было выше замечено плохая практика вызывать в ретурне на каждый рендер довольно сложную функцию. Декомпозиция вроде и была сделана, но при этом код по-прежнему афектит перформанс

// list.tsx
export const List = ({ className, children }): JSX.Element => (
  <ul className={ className }>
    { children }
  </ul>
);

// list-item.tsx
export const ListItem = ({ user }): JSX.Element => (
  <li className={ className }>
    { children }
  </li>
);

// fullname.tsx
export const FullName = ({ surname, name, patronymic }): JSX.Element => {
  const fullName = `
    {name} 
    {patronymic ?? ''} 
    {surname}
  `.toLowerCase();
  
  return (
    <span>
      { fullName }
    </span>
  );
};

// date.tsx
export const Date = ({ date }): JSX.Element | null => {
  if (!date) {
    return null;
  }
  
  return (
    <span>
      { moment(date) }
    </span>
  );
};

// status.tsx
import styles from './status.modules';

enum ColorByStatus = {
  'В сети': styles.statusOnline, 
  'Не в сети': styles.statusOffline,
};

export const Status = ({ description }): JSX.Element | null => (
  <span className={ ColorByStatus[description] ?? styles.statusDefault }>
    { description }
  </span>
);

// user-list.tsx
export const UserList = (users): JSX.Elemet => {
  return (
    <List className="user-list">
      {
        users.map(({ surname, name, patronymic, regestrationDate, status }) => (
          <FullName
            surname={ surname }
            name={ name }
            patronymic={ patronymic }
          />
          <Date date={ regestrationDate } />
          <Status description={ status.description } />
        )) 
      }
    </List>
  );  
};

Разве не best practices вынести элемент списка отдельным компонентом, в который передавать юзера и внутри него делать всю логику?

Почему в .map нет React.Fragment key=

Прошу прощения, я правильно понял, что в последнем листинге кода - ошибка, перепутаны местами аргументы вложенного коллбэка? вместо user => callback => нужно callback => user =>

Разве при таком вызове функции внутри map аргументы не поменяются местами?

users.map(proxyUserVars(callback))

Тоесть колбек зайдет при первом вызове функции, а элемент массива при втором. Тогда уж можно явно послать элемент вперед

users.map(user => proxyUserVars(user)(callback))

Ну или поменять порядок аргументов в прокси функции

А подготовить данные в ДТО не судьба ? Либо вызвать функцию на полученный респонс, либо уже в стейте, куда вы это складываете. Для чего эти преобразования тащить в UI?