Pull to refresh
33
Karma
0
Rating

Художник

5 типичных ошибок при создании React компонентов (с хуками) в 2020 году

Скорее депсы :-) Под зависимостями я имел вот что: useCallback(функция, [… зависимости])

5 типичных ошибок при создании React компонентов (с хуками) в 2020 году

В этом и смысл useCallback что при ререндере он вернет ту же самую функцию (referential equality), что и до (если зависимости не изменились)

Новое в Git 3: замыкания

Часто бывает когда коммит ломает обратную совместимость в минорной ветке, ну и тут либо git revert на несколько коммитов, либо git reset.

Введение в пользовательские CSS-свойства

Преимущество перед sass в том, что переменные

— следуют структуре dom:

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

пример на sass
a {
	color: blue;
}

.content {
	background: white;
	color: black;
}

/* далее фактически идет дифф оригинального цсс */
html[data-theme="night"]{
	a {
		color: red;
	}

	.content {
		background: black;
		color: white;
	}
}


пример с custom properties
html {
	--background: white;
	--color: black;
	--link-color: blue;
}

html[data-theme="night"] {
	--background: black;
	--color: white;
	--link-color: red;
}

/* далее идет общий цсс */
a {
	color: var(--link-color);
}

.content {
	background: var(--background);
	color: var(--color);
}



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

— динамические:

пример с js
html {
	--content-ratio: 70%;
}

.content{
	width: var(--content-ratio);
}

.sidebar{
	width: calc(100% - var(--content-ratio));
}

contentRangeInput.addEventListener("change", (e) => {
	document.documentElement.style.setProperty("--content-ratio", `${contentRangeInput.value}%`);
})



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

Ещё один dsl на Kotlin или как я печатал PDF из react

Я бы отправлял на бэк (микросервис на node со ждущим puppeteer) только ту часть страницы, которую составляет теоретический отчет. Прямо брал бы document.querySelector(".report").outerHTML и отправлял бы POST'om на сервер. А на сервере уже вставлял данный отчет в какой-то шаблон, с настроенными стилями и тд. В принципе стили можно на любом этапе присоединять.

Как добавить стили: github.com/GoogleChrome/puppeteer/blob/master/docs/api.md#pageaddstyletagoptions

Опять же пример
const puppeteer = require("puppeteer");
const path = require("path");
const base = __dirname;

(async () => {
	const browser = await puppeteer.launch({});
	const page = await browser.newPage();
	await page.goto("file://" + path.resolve(base, "index.html"));
	const height = await page.evaluate(
		() => document.documentElement.clientHeight
	);
	await page.addStyleTag({
		content: `
			button {
				display: none;
			}
		`
	});
	await page.pdf({
		path: path.resolve(base, "./output.pdf"),
		margin: {
			top: "2cm",
			bottom: "2cm",
			left: "1.5cm",
			right: "2cm",
		},
		height: `${height}px`,
	});

	await browser.close();
})().catch(e => {
	console.error(e);
});

Ещё один dsl на Kotlin или как я печатал PDF из react

Из всех вариантов получить страницу в пдф, самым адекватным по тому что получается, по гибкости настроек мне показалось взять puppeteer. Из-за того что он тянет полный хром с собой (подводный камень), пдф получаются как если бы прямо нажать на печать страницы в хроме. wkhtmltopdf, например, делает из страницы какое-то месиво с кривым выделением. Также есть возможность настроить как угодно страницу, подсунуть любой скрипт и стиль.

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

пример на node.js
const puppeteer = require("puppeteer");
const path = require("path");
const base = __dirname;

(async () => {
	const browser = await puppeteer.launch({});
	const page = await browser.newPage();
	await page.goto("file://" + path.resolve(base, "index.html"));
	const height = await page.evaluate(
		() => document.documentElement.clientHeight
	);
	await page.pdf({
		path: path.resolve(base, "./output.pdf"),
		margin: {
			top: "2cm",
			bottom: "2cm",
			left: "1.5cm",
			right: "2cm",
		},
		height: `${height}px`,
	});

	await browser.close();
})().catch(e => {
	console.error(e);
});

Firefox устанавливает на ваши устройства расширения для сбора данных без вашего ведома… опять

Вообще Mozilla Foundation это как раз non-profit организация.

Почему компилятор превратил мой цикл с условием в бесконечный?

Это какой-то миф про unsafe. В книге черным по белому написано что можно делать в unsafe, это 4 вещи:


  • Разыменовывать сырой указатель
  • Вызывать unsafe функцию или метод
  • Обращаться к или модифицировать статическую переменную
  • Реализовывать unsafe trait

Всё. Борроу чеккер и все остальные проверки там никуда не уходят.

Живой покойник RSS

Ну я вот про то, что усовершенствованный рсс, что это? Думать об улучшении рсс, это как хотеть тег <new-york-times> в хтмл, чтобы что? Или говорить, что у json не хватает возможностей по ретаргетингу и аналитике.

Насчет рсс-агрегаторов правда. Вижу, что у feedly какая-никакая аналитика есть, но кажется это недостаточно для рекламодателей. Нужен какой-то прокачанный инструмент, как тот же гугл.аналитикс. Также интересно, почему у feedly нет возможности брендинга отдельных фидов и коллабов с отдельными медиа провайдерами. Но опять же, рсс — это стандарт транспорта, рсс-агрегаторы — совсем отдельная песня. И все проблемы с монетизацией и популяризацией — это проблемы агрегаторов.

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

Живой покойник RSS

Тоже пришел из РСС.

Автор путает стандарт рсс, и все его претензии скорее в огород рсс ридеров. Стандарт дает возможность категоризации новостей, а вот ридеры эту фичу упускают. Соглашусь с ru1z, что рсс мертв для всяких shitty медиа холдингов, потому делает затруднительным вешать на уши лапшу посетителю всякими попапами, баннерами, автоплей видео, трекерами и прочими engagement стратегиями. Также автор не говорит: какая есть альтернатива? Какую возможность категоризации дает, например, лента фейсбука, или канал на телеграме? Чем они хоть в чем-то лучше с точки зрения читателя?

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

Вышел Webpack 4 Legato

Ну там вот в коментах примерно на 90% максимум. Неужели у кого-то было пять минут, а стало шесть секунд? Причем, в среднем, время у всех уменьшилось в два раза. У меня есть подозрение, что маркетологи опять живут на два процента. Например, было 100 сек, стало 52. 52 принимаем за 100%. Тогда 100 ~= 192%. Оппа! На 92% быстрее!

Вышел Webpack 4 Legato

Встречал уже тысячу перепечаток этой статьи и везде есть формулировка «до 98% быстрее» и вот не могу понять, что это значит? Раньше собирался 100 сек., а стал 98? 100 -> 2? 100 -> 198? Я бы принял первый вариант, но что-то как-то слишком быстро.

Коротко об HTML 5.2

Интересно, выкинут ли когда-нибудь самый известный тег <a> и сделают простой и понятный аттрибут href применимый ко всем элементам, типа <div href="./">smth</div>
Так иногда напрягает неоднозначность того где должен находиться тег <a>, то есть надо ли вкладывать <div> в <a>, наоборот, и как надо стилизовать сам тег. Сама по себе ссылка, это именно что аттрибут, такой же, как, например, title или alt.

Развенчиваем мифы об английском произношении

Ох, не надо сеять ересь.
Почему индусы, китайцы, ямайцы,…, итальянцы, французы все считают нормой говорить со своим акцентом, и даже гордятся им, и одни мы, как слепые приверженцы карго-культа джинс и жвачки упарываемся по акценту?
Многие вместо того, чтобы учить язык для своих повседневных нужд, начинают заморачиваться над акцентом чтобы было «как в кино», и в итоге забрасывают язык совсем, потому что просто стесняются говорить, и вместо таблицы времен учат складывать язык для «the». Акцент сам придет со временем, или не придет… но значит и так все хорошо.
Вот, например, профессор из Беркли говорит, ну как?

Зачем нужен БЭМ

Для меня "ave" моментом помню стало, когда мне объяснили, что не обязательно соблюдать иерархию ноды. Это вообще, как я понял, один из самых путающих моментов для новичков.
Раньше я думал, что БЭМ это:


<div class="note">
    <div class="note__sidebar">
        <div class="note__sidebar__title">
            <img class="note__sidebar__title__icon"/>
        </div>
    </div>
</div>

И думал что это какая-то фигня, а потом я понял, что надо так:


<div class="note">
    <div class="note__sidebar">
        <div class="note__title">
            <img class="note__icon"/>
        </div>
    </div>
</div>

И я прозрел

Кто, кроме битка: ещё девять криптовалют, на которые можно обратить внимание

И будет ситуация почему от бартера со временем отказались :-)
Приходишь на рынок купить баранокоинов на свои коровакоины, и нужный продавец принимает только ослокоины, соответственно надо поменять баранокоины, но меняла принимает только гусекоины. Постепенно вырисовывается цепь: коровакоины -> свинокоины ->… -> гусекоины -> ослокоины -> баранокоины

Пишем симпатичные Node.js-API с использованием async/await и базы данных Firebase

Не надо так демонизировать промисы, поверх которых async/await работает. Ваш пример с пирамидой ужаса можно записать так:

const example = require('example-library');

example.firstAsyncRequest()
.then( fistResponse => example.secondAsyncRequest(fistResponse) )
.then( secondResponse => example.thirdAsyncRequest(secondResponse) )
.then( thirdAsyncResponse => // никакого безумия!!!!11 )
//а теперь можно и глобальный catch на все три операции поставить
.catch( err => handleError(err) );


Пирамида ужаса это скорее про коллбеки.
Это я к тому, что раз async/await уже в браузерах, то это не повод забыть про промисы, а наоборот, повод лучше в них разобраться ибо они никуда не уйдут.

Нейросети диагностируют проблемы с сердцем более точно, чем врачи

А пусть эти нейросети сначала отработают смену 36ч и потом еще на неотложке, вот тогда и посмотрим!

JavaScript: многоликие функции

Первый листинг с ошибками, должно быть так
function* poll(url){
  let p = Promise.resolve();
  while(true){
    p = p.then(()=> fetch(url).then(call => call.json())
    yield p;
    p = p.then(() => delay(500));
  }
}

JavaScript: многоликие функции

В асинк генераторах просто удобнее и предсказуемее писать асинк код, так же как и в асинк функциях.
Например, вместо
async function* poll(url){
  let p = Promise.resolve();
  while(true){
    p = p.then(()=> fetch(url).then(call => call.json())
    yield p;
    p.then(() => delay(500));
  }
}

можно
async function* poll(url){
  while(true){
    const call = await fetch(url);
    yield await call.json();
    await delay(500);
  }
}

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity