Pull to refresh
2
0

Пользователь

Send message
Про currentColor стоит добавить, то один из лучших кейсов использования этой переменной — стилизация SVG:
.svg-icon-class {
  fill: currentColor;
}

и псевдо-элементов, которые должны быть одного цвета текстом.
Может много в игры играете? У меня все намеки на какие-либо проблемы закончились с покупкой PS4. Мышь использую только для веб-серфинга и работы, дублирую трекпадом. Девайсы: Magic Mouse 2 и Magic Trackpad 2. Пока ничего удобней для этих задач в руках не держал. Сенсорная панель Magic Mouse в разы удобней механического колесика. MadCatz RAT 9 после покупки и недельного использования Magic Mouse отправился со всей своей эргономикой на помойку. На максимальной скорости(можно выставить через терминал) путь от края до края по горизонтали всего около 2 см, на скорости меньше. Все системные жесты, чтобы лишний раз не сгибать пальцы, делаю левой рукой на трекпаде. Движения кистью в принципе исключены, работает локоть. Тут важна еще правильная посадка — уровень стола относительно туловища. Занятия спортом. Ну и для игр девайсы не подходят.
Вопрос такой, зачем хуки когда есть MobX?

А какое отношение MobX имеет, например, к Context API, Refs API и жизненному циклу? Я не понимаю, почему вы противопоставляете MobX Hooks API, когда даже официальный адаптер его использует, команда MobX активно использует хуки, а сам Вестстрат читает по ним доклады на конференциях?

Ну решите задачу с помощью одного лишь Mobx:
const Foo = ({ handler }) => {
  const ref = useOnClickOutside(handler);

  return <div ref={ref}>Just click outside</div>;
};


это слегка лучше setState,

Хуки это не только useState. Последний, к слову, очень удобен во множестве кейсов.

а хуки это так, hello world для чистого реакта без всего остального

Nonsense

но как ни крути с ними кода больше,

Напишите короче:
const Foo = () => {
  const { isActive, setActive } = useState(false);

  const toggle = () => {
    setActive(s => !s);
  };

  return <button onClick={toggle}>Toggle Active</button>;
};

Код выше при необходимости переиспользовния сокращается до:
const Foo = () => {
  const [state, handler] = useToggle();

  return <button onClick={handler}>Toggle Active</button>;
};


то снежный код наростает и читаемость снижается сильнее чем просто чистая манипуляция с переменными(MobX подход)

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

И да, первая релизная версия «древнего» Redux, появилась с MobX примерно в одно и то же время.
Вы сами не находите свой комментарий деструктивным? Какие-либо аргументы подтверждающие бесполезность хуков будут?

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

По поводу MobX, он давно имеет официальное легковесное решение основанное на хуках.
Репозиторий: react-mobx-light
Оф. сайт: mobx-react.js.org
Решение с хуками будет лучше тем, что:
1. Меньше кода. В случае с JS в данном примере это примерно в два раза меньше кода на реализацию useWindowWidth. Это без TS.

2. Проще использование. Вам придется, при использовании нескольких декораторов, либо следить за передаваемыми в компонент свойствами, либо использовать дополнительные параметры. А в больших командах это соглашения, контроль и прочее.

3. Когнитивная нагрузка ниже даже при использовании.
const Example: FC = () => {
  const windowWidth = useWindowWidth();

  return (
    ...
  );
}


@withWindowWidth
class Example extends React.Compоnent<WithWindowWidthProp> {
  render() {
    const { windowWidth } = this.props;

    return (
      ...
    );
  };
}

Чем больше компонент и больше хуков/декораторов, тем сильней разница.

4. Отсутствие лишних оберток, т.н. Wrapper-hell. Стоит хотя бы открыть React Developer Tools чтобы наглядно увидеть, что дает это преимущество.

5. Типизация HOC отдельный головняк.

Безусловно, переиспользовать код было можно, но теперь это гораздо очевидней и удобней. Меньше кода, быстрее разработка, быстрей анализ.
Ок, не будем далеко ходить и возьмем простой пример с конференции:
function useWindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);
  
  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener('resize', handleResize);
    return () => {
      window.removeEventListener('resize', handleResize);
    };
  }, []);
  
  return width;
}


import React from 'react';
import { useWindowWidth } from './utils/customHooks';

const Example = () => {
  const width = useWindowWidth();
  
  return (
    ...
  );
};


Покажите изящную альтернативу с классовыми компонентами. И это, на самом деле, довольно простой пример.

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

Что касается класса точности, то выше ABEC 7 на бордах точность не нужна.

Я хз зачем автору списка такая дорогая фурнитура, но при круизинге не такие уж сильные нагрузки.
У меня дежурная доска для езды по городу Penny Board за 120 долларов. Что с ней только не было, и прыжки на огромной скорости с бордюров, и улетания скейта из-под ног в стены, бордюры, ограды. За несколько лет активного катания менял только подшипники. Подвеска в поряде.

В случае с Evelope, электроскейт устройство технически более сложное и не факт, что оно проживет хотя бы три сезона активной езды. Поэтому инвестировать в него 154 000, я бы не рекомендовал. Ну разве только если совсем деньги некуда девать.
Китайцы сейчас делают относительно хорошие доски, не Evelope конечно, но в скорости и дальности они не уступают. Для покатушек можно взять тот же WoWGo 3, а на сэкономленные 116 000 можно и отремонтировать если, что-то сломается.
Разница, которую ты получаешь при выборе Evelope не стоит 116 000.
Себестоимость запчастей для вас и для компании заказывающей комплектующие в промышленных масштабах это две разные цифры.
Я и не пишу что цена завышена в разы, по мне это около 40-50% неадекватной наценки, если брать цену в США. Но при их стоимости это все равно много.

Понятное дело, что Evolve качественней китайского борда, но не на разницу в цене.

Насчет «собянинской» плитки ничего не скажу, в Москве пока не был, а на скейте предпочитаю кататься по ровным дорогам или плитке без фаски.

Популярные марки бордов, в том числе китайских, можете посмотреть тут:
compare-skateboards.com
На известных китайских бордах стоят батареи от Samsung и других известных производителей. А фурнитура не самая дешевая на рынке, как вы пишите.

Если брать цены по ссылке в статье, то разница с хорошей китайской доской около 80 000 — 100 000 рублей. Я для себя не вижу смысла переплачивать такую сумму. Использованием дорогой фурнитуры ее вряд ли можно оправдать. Тут большая часть переплаты это скорей более дорогое производство, более дорогую, но не лишенную недостатков технологию(ременной привод), большие вложения в маркетинг, ну и наценка местных ретейлеров, в которую так же входит маркетинговые расходы на местном рынке.
Озвученные вами 50-65к, думаю, приемлемая для такого борда цена, но чтобы ее получить надо перенести производство в Китай, сократить расходы на маркетинг и убрать посредников.
Борды, конечно, хорошие, но цены неадекватные.
Китайцы сейчас делают качественные электроскейты, которые и менее шумные, и стоят в разы дешевле.
Я просто переехал в небольшой красивый городок на берегу Балтийского моря. Каждый день после работы пешие прогулки на чистом свежем воздухе(море, сосновый лес, неровный ландшафт). Спортзал 3 раза в неделю по настроению. Велик. Скейт. Общественный транспорт только межгород. Хватает с лихвой, чтобы быть здоровей и активней большинства сверстников.
Дома стул Ikea Markus, подставка для ног, боковой свет, мониторы на нормальной высокой подставке и на расстоянии вытянутой руки, механическая клавиатура и нормальный вид из окна.
Google crawler никогда не выполняет клиентский JavaScript во время first wave of indexing. Это делается только после освобождения ресурсов на операцию во время second wave. До этого страница просто ставится в очередь, а время на освобождения может занять часы, а может недели. Для многих проектов это неприемлемо.
Доклад по теме с Google I/O 2018

Так же существует такой распространенный кейс, как шаринг контента в приложениях и социальных сетях. SSR в данном случае нужен для рендера разметки Open Graph.

Статью стоит переименовать в «Как я решал конкретную задачу с помощью React и MobX, и зачем-то написал в процессе пару велосипедов».

Помимо велосипедов, о которых уже написали в комментариях, не ясно, чем автору не угодила типизация. По мне, так это must have и стандарт для промышленной фронтенд разработки в 2019 году.
Храните данные только в redux(все-все, даже «внутренние»), если он подключен к вашему react-проекту в качестве основного хранилища, не используйте хранилищ которые будут конкурировать с ним.

Пожалуй, самый плохой совет, который только можно дать начинающему разработчику. Еще не было ни одного кейса за мою практику работы с React и Redux, где разделение store & component state вызывало бы какие-либо проблемы. Возможно, проблема существует лишь в вашей голове, а отсутствие code review в вашей команде вносит в это свою лепту.

Настоятельно не рекомендую следовать совету автора. Почитайте лучше, что пишет сам автор Redux по этому поводу.
Да. Отсутствие селекторов в исходном коде во многом этому способствует.
Складывается впечатление. что статью писал такой же начинающий.

Автор статьи, перевод которой мы публикуем, считает, что, к несчастью, в большинстве из существующих руководств по React не уделяется должного внимания ценным практическим приёмам разработки.

В этой статье их тоже нет. Лучше уж официальный туториал почитать.

Автор делится своими соображениями по поводу функциональных компонентов, но ни слова не написал о преимуществах компонентов классов.

Статья из разряда вредных. Я бы не рекомендовал новичкам опираться на советы автора по поводу функциональных компонентов. По поводу остального, лучше почитать официальный туториал и документацию. Там можно найти множество лучших практик. А за примерами реальных приложений, уже искать тематические статьи и репозитории на github.
Так это про свойства и атрибуты элементов, но никак не про имена.
Вопрос: «имена DOM элементов в React пишутся:». Ответ «lowercase» не подходит. Может, вы все-таки имели ввиду имена React компонентов? Имена DOM элементов в React пишутся в lowercase(div, span, textarea, p etc).
const getButtonStyles = ({ type, theme }) => {
  switch (type) {
    case 'primary':
      return css`
        // primary styles
      `;
     case 'brand':
      return css`
        
      `;
     default:
       return css`
          // default styles
       `;
  }
}

const Button = styled.button`
  // common styles
  ${getButtonStyles}
  ${media.mobile`
    // mobile styles
  `}
`;

Information

Rating
Does not participate
Location
Калининград (Кенигсберг), Калининградская обл., Россия
Registered
Activity