Стандартный способ реагирования на импортные заявления - PullRequest
Новая
       15

Стандартный способ реагирования на импортные заявления

1 голос
/ 14 апреля 2020

Мне было интересно, есть ли стандартный способ написать операторы импорта в реакции? Например, у меня есть это: 

import React, { useState, FormEvent } from 'react';
import Avatar from '@material-ui/core/Avatar';
import {Grid, Checkbox, TextField, FormControlLabel, CssBaseline} from '@material-ui/core';
import LockOutlinedIcon from '@material-ui/icons/LockOutlined';
import { LOGIN } from '../../graphql/mutations/login';
import { schema } from '../../helpers/validations/login';
import { Redirect } from 'react-router-dom';
import { useMutation } from '@apollo/react-hooks';
import StatusMessage from '../../helpers/statusMessages/loginMessage';
import Copyright from '../../components/copyright/copyright';
import CustomButton from '../../components/button/button';
import { ExecutionResult } from 'graphql';
import { Wrapper, StyledLink, Form, StyledTypography, StyledBox, StyledContainer} from './styles';
import { store } from '../../store';
import { useDispatch } from 'react-redux';
import SignInResponse from '../../graphql/responses/login';
import { useFormik } from 'formik';

Существуют ли какие-либо правила о том, должен ли я импортировать все из '@material-ui/core'; отдельно или вместе? Имеет ли это значение, кроме сокращения количества строк?

Есть ли какое-либо правило о том, следует ли мне импортировать другие локальные файлы / функции после того, как собственные библиотеки / содержимое реагируют? Любые другие правила / предложения?

Ответы [ 4 ]

1 голос
/ 14 апреля 2020

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

import { Avatar } from '@material-ui/core';

Еще одно, что я хотел бы сделать, это отделить мой локальный импорт от импорта пакетов, это делает код более читабельным: 

import React, { useState, FormEvent } from 'react';
import LockOutlinedIcon from '@material-ui/icons/LockOutlined';
import { ExecutionResult } from 'graphql';
import { Avatar, Grid, Checkbox, TextField, FormControlLabel, CssBaseline } from '@material-ui/core';
import { Redirect } from 'react-router-dom';
import { useMutation } from '@apollo/react-hooks';
import { useDispatch } from 'react-redux';
import { useFormik } from 'formik';

import { LOGIN } from '../../graphql/mutations/login';
import { schema } from '../../helpers/validations/login';
import { store } from '../../store';
import { Wrapper, StyledLink, Form, StyledTypography, StyledBox, StyledContainer } from './styles';
import StatusMessage from '../../helpers/statusMessages/loginMessage';
import Copyright from '../../components/copyright/copyright';
import CustomButton from '../../components/button/button';
import SignInResponse from '../../graphql/responses/login';
1 голос
/ 14 апреля 2020

Существует известный стандарт, большинство из которых являются мнениями, а не обязательными. Я бы порекомендовал вам взглянуть на eslint-plugin-import , так как он содержит обширный список стандартов / мнений относительно импорта:

  • Убедитесь, что все импорты появляются раньше другие операторы ([first])
  • Убедитесь, что все экспорты отображаются после других операторов ([exports-last])
  • Сообщить о повторном импорте одного и того же модуля в нескольких местах ([no-duplicates ])
  • Запретить импорт пространства имен (он же «подстановочный знак» *) ([no-namespace])
  • Обеспечить согласованное использование расширения файла в пути импорта ([extensions])
  • Принять соглашение в порядке импорта модуля ([order])
  • Принять символ новой строки после операторов импорта ([newline-after-import])
  • Предпочитать экспорт по умолчанию, если модуль экспортирует одно имя ([prefer-default-export])
  • Ограничение максимального количества зависимостей, которые может иметь модуль ([max-dependencies])
  • Запрет импорта без назначения ([no-unassigned-import] )
  • Запретить именованные экспорты по умолчанию ([no-named-default])
  • Запретить экспорты по умолчанию ([no-default-export])
  • Запретить идентификатор именованных экспортов ([no-named-export])
  • Запрещать анонимные значения в качестве экспорта по умолчанию ([no-anonymous-default-export])
  • Предпочитать именованные экспорты группировать в одном объявлении экспорта ([* group-exports])
  • Обеспечить ведущий комментарий с помощью webpackChunkName для динамического c импорта ([dynamic-import-chunkname])

Относительно заказа , что рекомендуется :

  1. узел "встроенных" модулей
  2. "внешние" модули
  3. "внутренние" модули
  4. модули из «родительского» каталога
  5. «родственные» модули из того же каталога или из одноуровневого каталога
  6. «индекс» текущего каталога
0 голосов
/ 14 апреля 2020

Стандартного способа нет, только личные предпочтения.

Лично я предпочитаю группировать импорт из общего источника, как вы это делали в '@material-ui/core';. Вы также можете сделать это с компонентами, помощниками и аналогичными локальными модулями. Также я предпочитаю импортировать сначала сторонние модули, а затем локальные модули.

Все дело в том, чтобы найти что-то «логичное» и простое для сканирования.

0 голосов
/ 14 апреля 2020

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

Кроме этого, я бы сказал, что импортируйте только то, что нужно: 

import Avatar from '@material-ui/core/Avatar';

лучше, чем 

import * as MaterialUI from '@material-ui/core';
...