Pull to refresh
5
0.1
Send message

Вы прям специально зарегались на Хабре через 30 мин после публикации, чтобы написать этот коммент?

Все познается в сравнении.
Уже много лет покупаю технику на Яндекс Маркете. Без страха беру по минимальной цене.
Гугл по запросу "iphone xr 128gb" выдает галерею товаров, среди которых не мало предложений за 30-38 тыс. руб. Ведут они на сайты, торгующие подделками, выдавая за оригинал.
Поэтому не могу сказать, что Яндекс думает только о прибыли в ущерб счастью пользователей.

Обращайте внимание тех, с кем вы работаете, на то, как важно писать код, который легко поддерживать, на то, как важны хорошие комментарии

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

Избегайте совещаний

Имхо, если проект еще не ушел в тяжелое легаси, лучше разрюхать react new context api и react hooks, а не городить очередной костыль для redux.
А еще рекомендую использовать typescript.

В общем, из того, что все данные изменились не следует, что изменилось все виртуальное дерево.
KasperGreen, прошу прощения, проглядел. vintage не прав — по настоящим DOM-узлам Реакт, конечно, бегать не будет.

Но и вы не правы — перерисовывать все Реакт тоже не будет, иначе это приведет к побочным эффектам, о которых я писал.

Реакт просто сравнит старое и новое виртуальное дерево и применит изменения к DOM-дереву.
vintage прав. Если бы это было не так, вы бы наблюдали побочные эффекты, такие как: потеря фокуса, положения курсора ввода, сброс выделения контента, положения прокрутки внутри элементов и т.п.
Поясню свой пример. Вы хотите, чтобы X использовал либо A, либо B. А я предлагаю инверсию зависимостей: A и B конфигурируют X. По сути получаете тот же результат: подключаете скрипт X и либо A, либо B.
Это решается с помощью CommonsChunkPlugin. Вот пример.
1. Суммарный пожатый фрондент весит 3.2 МБ. Релизы происходят по-разному: бывает раз в неделю, бывает раз в день.
2. Regular 3G 750 Кб/с грузит всю статику за 22 сек. Загрузка сопровождается прогресс-баром.
3. Зачем перегружать весь фронтенд, когда нужно обновить только часть? Только потому что TARS не может иначе?
Я говорю о браузере конечного пользователя.
И главный вопрос: при обновлении одного шрифта браузеру придется обновить всю статику?
Мне не нравится идея изменять названия папок и файлов. На то есть причины:
  • нельзя простым способом задеплоить ASP.NET проект, потому что невозможно добавить в проект файлы собранного фронтенда (пути к этим файлам меняются). Также получаем сложности с роутингом.
  • если меняются названия файлов, то отладчик в браузере будет закрывать старые версии этих файлов, будут теряться брейкпоинты, маппинг на файловую систему, позиция курсора.

Куда лучше добавлять хеш в query string.
По поводу кеширования шрифтов: а зачем хеш для них нужен?

Иконочные шрифты периодически обновляются, например, materialdesignicons или font-awesome, которые устаналиваются через bower или npm. Иногда в них меняются коды иконок. И если cache-busting применяется только к стилям, то клиент вместо "галочки" видит "крестик", вместо "котика" — "собачку" и т.п.
К тому же, кроме шрифтов, вы не применяете cache-busting к картинкам background-image.
Также в TARS неполностью реализован cache-busting: файлы шрифтов в стилях остаются без хеша.

В TARS мне не нравится:

  • отсутствие модульности (я говорю commonjs)
  • отсутствие тестирования
  • громоздкий

Ранее использовал gulp-starter от Vigetlabs, когда он еще на browserify был (теперь на webpack). Потом перешел на wepack + минимум gulp.

Как ни крутите, но гапловскими задачками вы вряд ли соберете фронтенд качественнее, чем webpack'ом. Также хочу предостеречь от browserify. С одной стороны, освоить его проще, но с другой — он ограниченный, бажный и потихоньку затухает.
Надо, наверное, смотреть в сторону кооперативных потоков, (Stackless Pyhton, например). Есть ли в питоне что-то похожее на GNU Pth для C?

Information

Rating
3,645-th
Registered
Activity