AMA с Хабром, #14: минус-реформа и закрытие TMFeed

Ваш аргумент уместен в контексте когда не знаешь исходные данные. По мне, исходные данные это страница, на которой надо показать 500-1000 комментариев и сделать это быстро. Я так понимаю, что на десктопной версии хабра текст всех svg зашит прямо в html и поэтому страница с комментариями открывается очень быстро (мы правда получаем немного больший html так как каждая иконка продублирована n-раз в inline-svg для каждого комментария). А что происходит на мобильной версии сайта? А там данные прилетают через api и нам остается только их натянуть на шаблон и показать, только делаем мы все это на клиенте с помощью JS. Условного говоря данные прилетают за 1/10 всего времени, 9/10 происходит рендер. Поэтому в контексте таких данных, мне кажется актуальней использовать шрифт. Ну на крайний случай можно использовать спрайты как это делает фейсбук. 500 svg иконок на странице да еще каждая через JS отрендерить — это тяжеловато.

AMA с Хабром, #14: минус-реформа и закрытие TMFeed

1 Захожу на m.habr.com через WIFI
2 Вкладка Лучшие / Месяц
3 Тыкаю по первому посту
4 Скролю в самый низ чтобы перейти в комментарии
5 Примерно 15 секунд вижу

такой экран:

6 Потом вижу

это

Причем если остановить сценарий то комментарии я читать смогу нормально. Подвисание имеет линейную зависимость от кол-ва комментариев. Тут явно есть проблемы в оптимизации JS и сложности олгаритмов O(n).

«Не учите меня жить»

1. Картинки всех аватаров необязательно грузить все сразу
2. Аватарки в svg авторов без аватарки лучше засунуть в шрифт иконок (ускорение будет колоссальным)
3. Блоки комментариев в DOM

тоже жрет ресурсов (хоть и совсем немного)

Проблемы основных паттернов создания data-driven apps на React.JS

Я где то выше писал:

3. Мне кажется, это изобретение очередного table — сурового и беспощадного со своей спецификацией.

а тут вы как раз кидаете пример и там прям так все и расписано. В случае с bootstrap 4 очень даже не плохо выглядит, Хотя статус беты немного отпугивает и то что нужно еще учить документацию по тому как bootstrap обернут в слоты.

Проблемы основных паттернов создания data-driven apps на React.JS

Автор публикации не смог предоставить каких либо аргументов в качестве доказательства удобства теории слотов. Я нашел его репозитарий на гитхабе там нет оценок кроме его собственной. Кроме того, после

моего примера

const element = (
  <h1 className="greeting">
    Привет, мир!
  </h1>
);
// или
const element = {
  type: 'h1',
  props: {
    className: 'greeting',
    children: 'Привет, мир!'
  }
};

— это ведь одно и тоже!

автор вообще не смог ничего ответить. Видимо, это связано с поверхностными знаниями в том как работает React и как код трансформируется в JSX.

Самая идея этих слотов противоречит первоначальной цели: избавление от ада оберток, потому что добавляет лишний слой вложенности.

Я использую Babel вместе с Webpack для компиляции кода, и там есть встроенные механизмы оптимизации которые уберут мои созданные переменные и подставят коды компонентов в нужные места.

Вы сами используете эти слоты?

Проблемы основных паттернов создания data-driven apps на React.JS

Красота JSX это по сути синтаксический сахар. А вы начинаете городить из этого свой велосипед.

const element = (
  <h1 className="greeting">
    Привет, мир!
  </h1>
);
// или
const element = {
  type: 'h1',
  props: {
    className: 'greeting',
    children: 'Привет, мир!'
  }
};

— это ведь одно и тоже!

Однако уровень вложенности в devtools все равно будет один, так как это те же пропсы, просто выраженные внутри пропса children, а не как отдельный пропс

в вашем случае будет один лишний уровень вложенности для LeftPane и для RightPane — проверьте, если не верите.

выносить даже небольшие кусочки JSX в отдельные JS-переменные

все правильно, так и нужно делать

Действительно, я имел в виду именно неудобный синтаксис

я использую Visual Studio Code с prettier по нажатию save файла. Этого вполне достаточно чтобы не путаться в скобочках

Проблемы основных паттернов создания data-driven apps на React.JS

wrapped-hell — «ад оберток» — это вот:


Если в SplitPane использовать left и right в виде props то будет один уровень вложенности. В вашем случае уровней будет два. И где тут решение проблемы «ад оберток»?

Проблемы основных паттернов создания data-driven apps на React.JS

Мне кажется, ваша основная проблема в том, что вам просто чисто эстетически не нравится передавать компоненты в виде props.

А этот код вызывают у вас как минимум раздражение

function App() {
  return (
    <SplitPane
      left={
        <Contacts />
      }
      right={
        <Chat />
      } />
  );
}

Но в случае с вашим же примерном со слотами

function App() {
  return (
    <SplitPane>
      <LeftPane>
        <Contacts />
      </LeftPane>
      <RightPane>
        <Chat />
      </RightPane>
    </SplitPane>
  );
}

1. А что если кто-то будет пере-использовать компонент SplitPane и поменяет местами LeftPane и RightPane? В случае float верстки это может быть критично.

2. А если в корень SplitPane засунуть другой компонент или div?

3. Мне кажется, это изобретение очередного table — сурового и беспощадного со своей спецификацией.

А если переписать так?

В моем приложении у меня как раз если список чатов и список контактов. И я использовал тот же подход что и вас «паттерн №5 – слоты». Только в моем случае SplitPane — это компонент обертка над css-table, а LeftPane и RightPane — обертка над css-td. Дочерних компонентов может быть или один или два и они даже могут быть изменены местами. В других случаях паттерн №5 мне кажется избыточен.

У старых электромобилей Tesla могут начаться проблемы с модулями памяти

Аргументируйте ваш ответ пожалуйста

Сервис-воркеры в клиенте Slack: об ускорении загрузки и оффлайн-режиме

Слек почти всегда открыт первой вкладкой в браузере. Сделал замер трафика: при холодном старте он скачивает почти 11 мегабайт. Старт с прогретым кешем уже всего лишь 100Кб — и это достойно похвалы.

Но как мне кажется сервис-воркеры не решают всех проблем. Это лишь временный костыль, а основные проблемы сидят намного глубже.

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

Вот к примеру страница статусов:



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

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

Конечно такой подход накладывает некоторые сложности при разработке. С другой стороны — значительно ускорит загрузку клиента, так как на первом экране клиент получит только то что он хочет увидеть.

Темная сторона Google Chrome

После вашего предыдущего поста-перевода я пересел вновь на Firefox.

Выходные на электромопеде с бензогенератором

С большим интересом буду ждать, очень интересно, спасибо!

Выходные на электромопеде с бензогенератором

А можно по подробнее о строении электробайка, внутренней начинке, так сказать что под капотом?
А то увидел только что емкость аккумуляторов 6 кВт*ч. Конечно я догадываюсь что там наверно 500-600 банок 18650. Если объем одной банки 18х18х65 (объем одной банки) х 600 (кол-во банок) = 12.6 дециметров2. Как вам удалось упаковать такой объем?

Mail.ru Cloud Solutions начала сотрудничать с дистрибьюторами ПО

Тоже расстраивает, ожидал увидеть числа.

Алкоголь и математик(а)

Полгода без алкоголя совсем. Еще до этого за год примерно 3 бутылки пива. Это были самые омерзительные 3 бутылки.

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

Зато! Утром так хорошо просыпаться, голова сразу думает! Из главных плюсов для себя отметил то, что как будто начал мыслить на скоростях в 150%. Как разогнанный проц до 5ГГц. Ну и память стала заметно лучше все запоминать и помнить. Очень ценный навык когда ты фуллстек.

Не жалею что бросил. Жалею что раньше этого не сделал.

Новшества JavaScript: итоги Google I/O 2019. Часть 2

Супер! Каждый раз с большим интересом читаю вашу подборку.
У меня вот только вопрос, почему safari нигде нет? Неужели ничего из написанного там сейчас не поддерживается?

Рождение одного проекта или как написать свою CMS

Demo 1 — я так понял там всего две страницы рабочии
Demo 2 — выдает: Hello World! This is text defined in widget meta information.

Рождение одного проекта или как написать свою CMS

А как залогинется в системе?

я что-то нажала и все сломалось

Что на самом деле случилось с исчезнувшим малайзийским Боингом (часть 3/3)

А у пилотов тоже маски вываливаются в случае разгерметизации?

Entity Framework 6 with Full-Text Search via LINQ

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

Entity Framework 6 with Full-Text Search via LINQ

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