Pull to refresh
1
0
Send message

В статье есть даже ссылки на переписку в том самом чатике. Автора спутали с небезызвестным участником хабра и кикнули за "неправильные вопросы"

Ваш пример чутка нерабочий, необходимо расширить до 4 строк кода

Вывод некорректный по итогу. А эксперимент годный. Я как раз недавно пытался по новой погрузиться в эту тему(удалось не до конца, пока на паузе).

Стоит заметить, что сразу можно откинуть источники инфы, которые пользуются определением "ссылочный/примитивный". Видимо это тянется с ES 5 https://262.ecma-international.org/5.1/#sec-4.3.2

В новой спеке используются понятия " Values without identity/ Values with identity " и то ...
https://tc39.es/ecma262/multipage/notational-conventions.html#sec-identity

Внимание, ниже мой вывод, который может быть вообще некорректный и требует валидации.

Как я понял каждое значение имеет некие характеристики, которым можно описывать само значение(в том числе ссылка на значение в памяти). И если с так называемыми примитивами эти характеристики легко получить, то с объектами - нет.

Если я ошибся, то поправьте, но только с ссылками на офф доку, потому что тема оч интересная

хром 122.0.6261.112.
захожу по https://mol.hyoo.ru/
прожимаю "энциклопедия"
по центру появляется контент с кнопками с выпадающим меню.
начинаю раскрывать пункты меню и подпункты - моргает экран.

в реакте такое обычно, когда 1 suspense на всю прилагу(условно)

Да, есть такие моменты, но. Я когда начинал js учить, писал код, который ломался при малейших неверных движений. Потом попал на проекты с ts. И уже долгие годы пишу на нем. Сейчас заметил, что ts под капотом дисциплинировал меня писать код с кучей проверок. Я пет проект на js чистом пишу и снова присутствуют все эти проверки. По моему это хорошо, что меня дисциплинировал ts, а не вечно падающий прод из-за моего плохого кода )

видимо зря я относился к этому "на забитом". Целая наука оказывается

сейчас никак не отделяю

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

Клоню к тому, что если вы топите за то, чтобы отделять. То надо отделять каким-либо видимым(бросающимся в глаза) образом. Ведь визуально я сразу замечу условно "черту", что сразу вызовет вопросы. А вот если нет, ну вы поняли. На ревью только всплывет, что я намешал вам импортов

2-ой абзац согласен полностью.

Очень помогает при рефакторинге, когда надо перетащить в другую папку компонент, у которого штук 10 импортов, и нужно перебить все относительные пути.

Вроде уже все IDE помогает делать это автоматически

Это надо, чтобы визуально отличать импорт внешних и внутренних зависимостей

Как вы проводите черту между двумя этими типами? Пустой строкой?

Не раскрыто про порядок импортов. Почему плохо забить на этот порядок и почему важно соблюдать?

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

Отмечу, что не менее приятно читать ваш диалог

Еще раз. Ваше вообщение:

А что, кто-то предлагал так и писать? 8-O

Моя цитата из прочитанной вами статьи:

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

и мой ответ в самом первом комментарии:

Так может пусть и дальше этим занимаются транспиляторы? а мы будем использовать уже всем знакомый async/await? ...

Но да ладно, чет я и так слишком "душнила" в этом треде... Сорян, мир вам

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

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

А вы читали статью ?

вы все правильно думали и внимательно прочитали.

Было интересно, но:

Именно это делают транспиляторы вроде Babel при преобразовании async/await в более старые версии JS, где этой функциональности ещё не было. Если вы взглянете на транспилированный код, то сможете провести множество параллелей с нашей реализацией.

Так может пусть и дальше этим занимаются транспиляторы? а мы будем использовать уже всем знакомый async/await? А то в вебе и так зоопарк подходов и разных технологий...

Больше такого контента бы. Мозгу надо привыкнуть к синтаксису. Идеи автора фреймворка нравятся, но синтаксис... надо время

Да, выше уже прочитал, хабр модерирует комменты с задержкой в двое суток.

Используйте AbortController только тогда, когда действительно нужно отменять асинхронные операции. В некоторых случаях альтернативные подходы могут быть более подходящими (например, игнорирование результата, если он неактуален).

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

1

Information

Rating
Does not participate
Registered
Activity