Pull to refresh
-4
0
Владислав Поляков @polRk

Главный эксперт

Send message

Сейчас важность разработки Deno или security релизы Nodejs должны стать приоритетом, а не новые фичи ecmas

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

Теперь браузеры не разрешают переиспользовать ресурсы. Для каждого сайта - своя копия.

В целом - статья полный булшит

Вам стоит лучше ознакомиться со статьей и видео https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html, там подробно описано для чего, зачем, и как следует их применять.

Только когда зайдет вопрос о связях между моделями в огромном проекте (да и не только), все начинают плеваться от Mobx.
Есть лучше, enpass
Только это не слайдер, а tabbar. Слайдер должен уметь перелистываться, отвечать на свайпы
55% в канале НЕХТА Live — Это и есть подтверждение моих слов.

Плюс, мы не знаем возраст подписавшихся. Думаю больше всего там молодежи, которой легко манипулировать и немного взрослых и детей (до 18 лет). И вот, 55% уже существенно уменьшаются.
Только вы забываете, что не все из Беларуси. И из 2х миллионов наберется чуть больше половины.
O(n^2) Вот, что препятствует
Оказалось, что нужно делать все наоборот.
	if balanceFactor == 2 {
		if n.Left.balanceFactor() < 0 {
			n.Left = n.Left.rotateLeft()
		}

		return n.rotateRight()
	}

	if balanceFactor == -2 {
		if n.Right.balanceFactor() > 0 {
			n.Right = n.Right.rotateRight()
		}

		return n.rotateLeft()
	}


Пробую ваш и код и понимаю — он не работает. Не могу забалансить 0-1-2-3-4-5-6-7-8-9-10…
Посмотрев понял, что он не может сделать rotateRight, ибо p->left == 0.
Я уже ответил
Никак, все, что на frontend не безопасно. Не существует механизмов как-то безопасно хранить ключи и идентификацию пользователя. Тем более скрыть это. С localStorage так же как и с кошельком: оставите на видном месте — будет соблазн его спереть, а кто-то да и сопрет. Но это не защитит вас от грабителя, который целенаправленно идет вас грабить.
Но это не будет прямым доступом, о чем я написал выше
Я нашел только про chrome.store и про LocalStorage. Можете указать, где именно сказано про indexDB?
Разницы нет. Так как браузерные расширения не имеют прямого доступа к IndexDB, (доступ и передачу через onMessage я не считаю за прямой ), я посчитал это как за преимущество

Нет никакой опасности, что localStorage может кто угодно прочитать. Если очень боитесь об этой ситуации, попробуйте использовать базу данных в браузере IndexDB. А обновления токена поместить в сервис воркер. Ах и да, используйте 5-10 минутные токены или посмотрите как эту проблему решил firebase в модуле auth. JWT создан так, чтоб хранитб в нем общедоступную информацию, которую может прочитать кто угодно. Если вы храните там закрытую информацию, то это проблема в использовании. Почитав комментарии понял, что есть много заблуждений и непониманий как использовать jwt правильно. Да и все, что вы передаете на frontend общедоступно, и подразумевает ваше согласие на то, что любой может прочитать и получить эту информацию

JWT токены не стоит НИКОГДА отзывать. Они не задумывались для отзыва. Это антипатерн и проблемы с пониманием таких простых вещей как 10минутные jwt

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity

Specialization

Frontend Developer, Fullstack Developer
Lead
From 850,000 ₽
JavaScript
TypeScript
React
Node.js
Kubernetes
Docker