Windows пока еще и на 4К не научилась с шрифтами справляться при масштабировании, а с 8К вообще не известно когда разрулят. Меня уже достало на моем 4К мониторе смотреть в их кривые шрифты, а если не масштабировать, то во многих приложениях при 4К совсем текст не прочитать при моем 28" мониторе.
Так не нужно было кричать на каждом углу, что они такие поборники морали, сейчас не пришлось бы сикать в лужу. Заявили бы тогда, что текущая политика Китая не отвечает нашей ТЕКУЩЕЙ точке зрения на ситуацию. И всё, никто бы сейчас и рта не разинул против них. Но нет же, они пяткой себя колотили в грудь и выкрикивали НИКОГДА! Никогда в их понимании пара-тройка лет? В вашем тоже?
При чем тут размер вашего экрана в реальных единицах к размеру вьюпорта в пикселях? Вот туту видимо похожих разраболов и наняла, которые им также втирали и такую х… ь сделали на сайте.
Как соотносится размер вашего экрана смарта с fullhd и выдаваемым вам контентом, который влезает по ширине в fullhd с тем, что десктоп с шириной 400px получает версию fullhd по ширине, которая не адаптируется и не влезает в эти 400px?
Хотя разраболы, которые сделали им это уг, создали им моб. версию и эта моб. версия спокойно влезла бы в этот десктоп на 400px — но нет, они ведь разраболы, и ширина вьюпорта не решает для них.
А клиенты — зачем они туту, главное показать какие мы крутые разраболы, а то что каждый кто получит на свернутом браузере на десктопе такой сайт, сразу его закроет и перейдет к следующему в поиске — это дело десятое.
Смешно, ога.
Я захожу с вьюпортом с шириной 400px, а мне выдать страницу значит с минимальной шириной элемента формы 1200px — нет, не показатель, конечно, жесть, вот откуда вы такие беретесь то.
Он как был говно, так и остался им — дизайн лого не сделал сайт лучше и отзывчивее (да еще без адаптива, о чем писал выше тут).
На счет постоянных пользователей — это далеко не факт. Если нет альтернативы, пользователь сидит и заполняет тучу неудобных экранов и полей, а тут ему дали то же самое, но гораздо удобнее и продуманнее, чтобы ему не приходилось пальцами молотить по мыше (или экрану) сотни лишних раз — он это сразу почувствует, вот просто эмпирически и сразу перестанет быть постоянным пользователем — гарантирую вам это.
P.S>
А сам дизайн лого нового, конечно, глупо оспаривать, Лебедев хоть и м… редкий, но его ребята работу знают на пять с плюсом. Лого хорошее, не важно на сколько оно завышено по цене, но оно в разы лучше всего, что было до этого у туту, но повторюсь — ЛОГО в данный момент не решает на туту, решает смена интерфейса в адаптив и продуманный шаблон поведения клиента на каждой из важных страниц (от форм вплоть до рекламных банеров в нужном месте и нужных видов).
Адаптив (по моему мнению) это первое, что нужно делать на сайте. Вместо того, чтобы обращаться к всяким Лебедевым, нужно сначала сделать возможность клиентам работать на сайте комфортно, а уже затем наводить понты.
А мобильная версия тут при чем? Если вы по ширине вьюпорта не можете понять, что нужно отдать моб. версию — смысл с этой моб. версии тогда?
Да там вообще верстки нет по ходу — у меня браузер всегда в полосу свернут (чуть шире мобильной полосы) так туту никакой реакции — ничего из сайта не вмещается в браузере, все уходит за экран. Пользоваться сайтом нельзя в принципе (и думаю никто не станет такой ерундой пользоваться из вменяемых пользователей).
Да тут дело даже не в иллюстрациях, а в понимании самого процесса замыкания в JS. Многие просто не понимают, что из себя представляет само замыкание в JS. В остальных языках — там всё это совсем по другому, и ясно и понятно. А в JS это баг изначально, и его не стали исправлять, а так и оставили, типа фишка языка. И вот теперь, кто-то додумывается использовать этот баг.
Суть ошибки замыкания в JS, что в нем нет типизированного вызова и обращения к свойствам объекта и к просто переменным. Сам интерпретатор решает к чему именно вы обращаетесь.
Вот вы указали базовый пример из справочника, и тут именно наглядно видно это. В момент, когда вы создали глобальный объект var myFunc = makeFunc… отработала внутренняя функция displayName создав замыкание и глобальный объект myFunc получил свойство name (в обычном языке myFunc->name).
Всё, функции makeFunc и displayName отработали, и все их внутренние переменные должны быть очищены, это везде так (и в JS это тоже так).
Но, в js, (так, как все функции являются объектами — гвоздь им в голову сразу и по шляпку) когда вы снова, после окончания работы функций пытаетесь обратиться к переменной name, интерпретатор, не имея типизации обращения, видит, что такое свойство есть у ныне существующего глобального объекта myFunc, а значит, вы, скорее-всего, к нему обращаетесь — он вам и возвращает это свойство этого объекта, и складывается впечатление, что якобы существует сама переменная name в памяти, после окончания работы функций.
Вот именно это и является проблемой — можно так дозамыкаться, что ПК пользователя просто перестанет отвечать на запросы. А также черт его знает в каком месте у вас нахлестнутся имена свойств объектов после замыкания и имена глобальных переменных, что приведет просто к разрыву башки при отладке такого кода. Вот поэтому, я жестко караю любого, за любую попытку этого х… кода в js, кто сознательно пытается использовать этот баг в js.
И именно поэтому, каждый раз когда новая команда разработчиков (и не важно, номральная-ли команда, или команда чудо-разрабО) приходят к клиенту, чтобы расширить (или исправить) код, который был написан до этого такими вот чудо-разрабами, нет никакого шанса разобрать этот дивный код. Поэтому, всегда все начинают писать всё с нуля. Клиент, которому попадаются такие чудо-разрабы, постоянно попадает на деньги и на время, и из-за этого у него складывается негативное впечатление о работе отрасли программирования в целом. И всё это из-за таких вот чудо-программеров, как b00taNik, которые считают себя программистами.
Вот мой код и код таких как я, сможет прийти и продолжить, или изменить, любая новая команда у клиента (и не важно нормальная ли команда, или команда чудо-разрабов). Им потребуется минимальное время, чтобы понять структуру кода и начать его исправлять, или дополнять. Никаких неявных петель и ловушек вроде таких вот чудо-замыканий, они не получат в моем коде, я даже никогда не делаю дубли в именовании явно-объявляемых переменных внутри функций, не говоря уже о том, чтобы произошел нахлест в глобальной области видимости.
Ну че, поздравляю вашего работадателя с наймом программиста, учившигося в википедии (мое сочувствие ему) :)
На курсы — запишитесь при любом университете технической направленности (а то я как закончил Универ радиотехнический по направлению автоматизация и управление, так и программирую после этого и учусь не в википедии, а по документации к языкам и аппаратным комплексам).
И да, не по викепилдии, а по документации языка и разработчиков (мозила):
Замыкание — это комбинация функции и лексического окружения, в котором эта функция была определена.
А теперь вопрос супер-пупер программисту википедийному, eH001 — определена где? Внутри функции какой то? ИЛи на глобальном уровне вне окружения функций?
Жесть, и вот такое чудо-разрабо, программистом работает, жесть просто — где работаете? Надо вашему нанимателю линк скинуть на ваши комменты здесь, чтобы он понял кто у него работает.
На счет таймеров — еще раз повторю, учите матчасть, или на курсы идите (я вас бесплатно образовываю, написав вам что делает ваш fetch в в вашем коде).
На счет не работает — откуда мне знать, что вы там вызываете своими объектами.
Запишите обработчик для проверки так, чтобы узнать в консоли работает или нет: function eH001(){
if (this.status == 200){console.log('OK!')}else{console.log('NO!');}
}
>@b00taNik Кроме того, что он не работает так еще и замыкания использует,
Вы тоже не пишите больше, а идите учиться на курсы начальные — также ниже джуниора левел, который в принципе не знает что такое замыкания. (вам тоже бесплатный урок — назначение события, либо передача имени функции аргументом [без скобок], это не замыкание. Явное объявление функции, либо вызов в анонимном варианте [со скобками] внутри другой функции — вот что является замыканием в JS и что позволяет сохранять состояния переменных. В моем же коде, нет никаких замыканий, и в обработчике, this будет всем, на что в любой из функций повесят этот обработчик, и, как вы не извращайтесь, но он никогда не сохранит состояние предыдущего вызова если его вызвали повторно. Учите матчасть, поднимитесь до джуниора хотя бы. И не смешите народ и не позорьтесь — не пишите чушь больше здесь.
Да что ты будешь делать. Вот что вы читаете? Какой цикл вы где видите? Вы спецификацию xmlhttprequest читали вообще?
Весь fetch этого чудо-автора ниже джуниора, это регистрация промиса, резервирование состояний, объявление функций response и reject, запуск таймера опроса промиса для получения состояния исполнения, и, только затем, исполнение ТОГО ЖЕ КОДА ОТ xmlhttprequest:
function eH001(){
if (this.status == 200)(x => x.json());
(x => console.log(x.hello));
}
var XH001 = new XMLHttpRequest();
XH001.onload = eH001;
XH001.open('GET', 'https://www.mocky.io/v2/5185415ba171ea3a00704eed');
XH001.send();
То есть, такой вот чудо-разраб, который начитался таких же чудо-разрабов придумавших fetch, чтобы не писать код обработки XMLHTTPRequest, взял и на ровном месте в 3 раза увеличил нагрузку на ПК юзера, просто так, чтобы не писать пару лишних строк.
Ну, я могу понять, любишь ты короткие записи, напиши просто функцию обертку тогда, чтобы её вызывать вместо кода самого XMLHTTPRequest, и обзови там её myfetch(respose, reject) и вызывай — даже это будет в разищи быстрее и лучше, чем вызывать этот промис тормознутый и проблеммный.
Но нет, этот чудо-программер, будет бить себя пяткой в грудь, убивать машину юзеру, но не снизойдет до изучения чего-либо, а просто будет читать таких же супер-пупер профи.
Не выставляйте себя клоуном — и не пишите больше сюда. Вы просто новичок и ниже джуниора.
fetch всего лишь обертка для XMLHTTPRequest, чтобы такие неумехи, как вы писали меньше букв, не понимая технологии запроса данных. Если вы не понимаете, как написать XMLHTTPRequest запрос с if else (и при необходимости, заюзать catch), как в вашем fetch-е — просто идите на курсы базовые по программированию что-ли.
В прошлом? В ПРОШЛОМ? ааа, жесть! Вы вообще хотя бы слегка представляете себе, как работает стек вызова всего вашего «будущего»? Какие системные функции затрагиваются при вызове ваших технологий? Какие проверки и со стороны каких процессов идут во фронтэнде? Всё это ваше «будущее», это устаревшая технология бэкэнда (80-ые по-моему годы, ну может девяностые – 5-я, или 6-я студия короче от майкрософта). Именно тогда бэкэнд языки были еще такими ущербными и там также приходилось применять обертки событий (EventLoop как тут кто-то в комментах писал, думая, что это круто — товарищ, это не круто, это смерть твоему проекту в продакте, если ты нагрузишь стек событиями и будешь ждать их окончания, не контролируя саму среду в которой выполняется твой код [браузер в данном случае]).
Теперь же бэкэнд вырос и избавился от этой шняги и такие вот горе-профи (аааа жесть просто) теперь пытаются впихнуть это старье во фронт энд, и всё по той же причине, чтобы также как и тогда в бэкэнде, обойти ограничения синхронности языка.
Но вот беда, работа кода в бэкэнде и работа его во фронтэнде, подчиняются абсолютно разным правилам и проходят очень-очень разные этапы проверок и допусков. И понятное дело, что обмен данными между мнимо-асинхронными функциями, во фронтэнде, просто теряет свой смысл из-за его слишком большой задержки (проверка ядром системы, проверка браузером, проверка анти-вирусом и прочими сторонними наблюдателями в системе).
Не пытайтесь писать на фронтэнде то, что нельзя на нем писать, притащив в него устаревшие технологии из бэкэнда! Хотите работу приложения как в бэкэнде, да млина, — пишите на бэкэнде, а фронтэнд подгружайте в виде интерфейса только, а не для работы и вычислений (не умеете так? слишком сложно для вас? — учитесь, или заказывайте у тех, кто может, но не пытайтесь городить шнягу убогую на том, на чем её не следует городить).
Тоже самое тут про virtual dom кто-то писал в комментах, ну и у самого автора поста это как раз-таки вызвало бурю негатива — и да, я полностью его поддерживаю в этом. Бла-бла-бла Senior… — не знаешь вирутал? не, не сениор. А вот собеседующий сам в курсе, что даже не junior, а первый месяц изучающий любой язык джуниор, уже знает и всегда использует только виртуал дом? 10-20 лет назад, любой, кто начинал попытку использования в своем бэкэнде web интерфейса (подгрузив объект webbrowser, или создав из своей программы экземпляры штатного веббраузера системы) тут же, при первом опыте внедрения большого потока данных в реальный дом, сталкивается с тем, что без виртуал, его код не будет работать. Ибо, подвесив свой ПК таким обращением в реальный дом, он начинает анализировать, что же произошло и находит причину, что работа с прямым дом, контролируемым всеми и вся, так нагружает и тормозит пк — что работа с ним просто не реальна.
И он тут же изобретает свой виртуал дом и обрабатывает его штатными регэкспами в памяти, выгружая в файлы готовые куски кода, если их слишком много для работы из памяти напрямую, а затем уже использует эти куски в своем веб интерфейсе. О чудо, спустя 20 лет, кто-то изобрел то же самое и назвал это virtual dom — и это да, это важно, это только для senior-ов технология, только они в курсе, как это и для чего :( аааа, жесть просто, не хватает уже эмоций на таких вот чудо-профи — куда катится мир программирования? Что, никто больше не хочет думать? Все читают каких-то ущербных чудо-разрабов, чтобы самим стать такими же ущербными и писать всякую чушь к месту и нет? Кто-то читает вообще спецификации самих языков? Спецификации ОС и аппаратной части ПК? Чтобы понимать, как работает тот, или иной метод в реальности?
Ладно, хватит лирики, тут на хабре я читал только от пары человек статьи, которые объясняли, как работает на низком уровне та, или иная функция языка, или препроцессора (в зависимости от того, что освещал автор). Это были переводы статей конечно, но сам факт, что человек правильно перевел такие статьи, дает мне право считать, что он также понимает, как работает то, что он переводит. Все остальные тут, смотрю, даже близко не представляют, как работает их чудо-супер-пупер технология замыканий, промисов и прочая чушь, в реальности и какие порождает процессы на низком уровне.
Все, кто тут отписался, считая себя суепр-профи знатоком, давайте эксперимент — скидывайте код, где вы считаете уместным замыкание, промис и т.д. Я переделываю его в свой код без всей этой чуши, и мы вставляем его в тело реальной страницы, нагруженной эффектами движения, графикой и прочим. Запускаем циклично тест этой (этих функций) и пишем видео с экрана работы этой страницы во время выполнения наших кодов, активно взаимодействуя с элементами страницы (скрлим, наводим мышь на элементы, выделяем текст, кликаем правой кнопкой мыши — в общем делаем все то, что делает пользователь на странице, просто не открывая новых вкладок).
По окончании работы теста, сохраняем данные использования памяти, CPU, GPU, время работы кодов (ну и выкладываем видео на общее обозрение, как ведет себя страница в браузере пока работает ваш и мой код — оба типа у каждого на ПК, чтобы было видно, как работает разный код на одном и том же ПК).
Вот тогда, мы и будем уже более детально обсуждать чудо-супер-пупер технологии на реальном примере, а не на сферическом коне в вакууме.
Не ёрничайте, всем понятно что речь идет о замыканиях внутри старшей функции для попытки сделать приватными переменные, или сохранить значения переменных (хотя мне сложно понять для чего через ж… замыкания это пытаются делать).
Если в любом моем проекте, кто-то, хотя бы подумает использовать замыкание — сразу пойдет искать новую работу.
На счет промисов — тут есть конечно нюансы, ввиду синхронности js, но мое отношение к промисам также негативное (работу кончено не пойдет искать, но прослушает двухчасовую беседу о том, как разбивать задачи на минимальные составляющие для обеспечения стабильности и прозрачности работы кода).
Но саму возможность использования промисов, в каких-то непонятных, внеземных проектах, я конечно не отрицаю. Как по мне, промисы в js придумал какой-то редкий м....., который ранее работал в глубоком бэкенде, на c++, с функциями асинхронного вызова и обработки данных без потоков, через медиаторы, в самих кодах классов.
Сидел он значит, изучал фронтенд (новое для себя дело) и встал в ступор — а почему нельзя в js через те же медиаторы и обертки событий, как было в классах на c++, обойти синхронность языка? Давай-ка я напишу это, чтобы и здесь реализовать мнимо-неблокируемый интерфейс, и назову всё это дело промисом!
А нужно-ли это во фронте?, или это создаст для работы кода еще больше проблем? — эт. дело десятое, главное мы из JS теперь сделаем крутой язык, приближающийся к бэку!
Это конечно. Но, именно из психологической практики реального мира и вытекает спорный момент, который я описал выше.
А особенно, из анимации на самом примере в статье: сам хаотичный поиск пути объектами и движение их по свободным полям, может вызвать когнитивный диссонанс у пользователя, а не быстрая смена всех элементов, хоть они и пересеклись бы (ну желательно чтобы главный элемент проехал НАД всеми остальными, но все остальные — абсолютно без разницы, как там смещались бы, относительно друг-друга).
В принципе, всё верно и аксиомично, единственно, спорный постулат:
>>Если пути движущихся объектов пересекаются друг с другом, они не могут проходить друг через друга.
Это далеко не факт. Уточнение в следующем пункте — что объект должен подняться, а не пройти под другими, уже лучше, но сам пункт о не пересечении, как бы сомнителен и может, наоборот, оказаться менее удачным решением.
Ну, второй пример, который вы нашли (и указали ссылку в начале своего текста) как бэ является де-факто решением для хранения всех файлов, с небольшим дополнением связей из конкретно вашей БД.
700 единиц хранения на каждую папку (примите как аксиому от человека, который на практике тестировал всё это), то есть в каждой папке или 700 других папок, или 700 файлов, если это конечная глубина. 4 уровня вниз — 343 миллиона файлов в одной старшей папке.
Все имена файлов только цифрой, которая является ключом в БД. Если записи о файлах хранятся в разных таблицах — разные папки для каждой таблицы. Поиск пути, где сохранен файл, по цифре ключа из бд — самая быстрая операция, которую вы сможете придумать с файлом в таких количествах.
Я в реальных сайтах использую эту нумерацию не только для хранения файлов изображений, но и для файлов кэша всех страниц сайта на диске.
Лень делать скрины, но приведу вам стату: по запросу в гугле site: мой домен — ответ примерно такой: нашлось примерно 243 миллиона страниц.
В консоли гугла, средняя скорость загрузки страниц — 242 мc. Хостинг шаред (общий тысячи пользователей на одной машине) 300 рублей в месяц, плюс 50Гб места докупил, чтобы файлы влезали, нагрузки нет особой на хостинг от моего сайта этого.
А так громко кричали о правах человека, а коснулось дело бабла — опаньки, и права уже не нужны никому в гуглах.
Как соотносится размер вашего экрана смарта с fullhd и выдаваемым вам контентом, который влезает по ширине в fullhd с тем, что десктоп с шириной 400px получает версию fullhd по ширине, которая не адаптируется и не влезает в эти 400px?
Хотя разраболы, которые сделали им это уг, создали им моб. версию и эта моб. версия спокойно влезла бы в этот десктоп на 400px — но нет, они ведь разраболы, и ширина вьюпорта не решает для них.
А клиенты — зачем они туту, главное показать какие мы крутые разраболы, а то что каждый кто получит на свернутом браузере на десктопе такой сайт, сразу его закроет и перейдет к следующему в поиске — это дело десятое.
Я захожу с вьюпортом с шириной 400px, а мне выдать страницу значит с минимальной шириной элемента формы 1200px — нет, не показатель, конечно, жесть, вот откуда вы такие беретесь то.
На счет постоянных пользователей — это далеко не факт. Если нет альтернативы, пользователь сидит и заполняет тучу неудобных экранов и полей, а тут ему дали то же самое, но гораздо удобнее и продуманнее, чтобы ему не приходилось пальцами молотить по мыше (или экрану) сотни лишних раз — он это сразу почувствует, вот просто эмпирически и сразу перестанет быть постоянным пользователем — гарантирую вам это.
P.S>
А сам дизайн лого нового, конечно, глупо оспаривать, Лебедев хоть и м… редкий, но его ребята работу знают на пять с плюсом. Лого хорошее, не важно на сколько оно завышено по цене, но оно в разы лучше всего, что было до этого у туту, но повторюсь — ЛОГО в данный момент не решает на туту, решает смена интерфейса в адаптив и продуманный шаблон поведения клиента на каждой из важных страниц (от форм вплоть до рекламных банеров в нужном месте и нужных видов).
А мобильная версия тут при чем? Если вы по ширине вьюпорта не можете понять, что нужно отдать моб. версию — смысл с этой моб. версии тогда?
Суть ошибки замыкания в JS, что в нем нет типизированного вызова и обращения к свойствам объекта и к просто переменным. Сам интерпретатор решает к чему именно вы обращаетесь.
Вот вы указали базовый пример из справочника, и тут именно наглядно видно это. В момент, когда вы создали глобальный объект var myFunc = makeFunc… отработала внутренняя функция displayName создав замыкание и глобальный объект myFunc получил свойство name (в обычном языке myFunc->name).
Всё, функции makeFunc и displayName отработали, и все их внутренние переменные должны быть очищены, это везде так (и в JS это тоже так).
Но, в js, (так, как все функции являются объектами — гвоздь им в голову сразу и по шляпку) когда вы снова, после окончания работы функций пытаетесь обратиться к переменной name, интерпретатор, не имея типизации обращения, видит, что такое свойство есть у ныне существующего глобального объекта myFunc, а значит, вы, скорее-всего, к нему обращаетесь — он вам и возвращает это свойство этого объекта, и складывается впечатление, что якобы существует сама переменная name в памяти, после окончания работы функций.
Вот именно это и является проблемой — можно так дозамыкаться, что ПК пользователя просто перестанет отвечать на запросы. А также черт его знает в каком месте у вас нахлестнутся имена свойств объектов после замыкания и имена глобальных переменных, что приведет просто к разрыву башки при отладке такого кода. Вот поэтому, я жестко караю любого, за любую попытку этого х… кода в js, кто сознательно пытается использовать этот баг в js.
И именно поэтому, каждый раз когда новая команда разработчиков (и не важно, номральная-ли команда, или команда чудо-разрабО) приходят к клиенту, чтобы расширить (или исправить) код, который был написан до этого такими вот чудо-разрабами, нет никакого шанса разобрать этот дивный код. Поэтому, всегда все начинают писать всё с нуля. Клиент, которому попадаются такие чудо-разрабы, постоянно попадает на деньги и на время, и из-за этого у него складывается негативное впечатление о работе отрасли программирования в целом. И всё это из-за таких вот чудо-программеров, как b00taNik, которые считают себя программистами.
Вот мой код и код таких как я, сможет прийти и продолжить, или изменить, любая новая команда у клиента (и не важно нормальная ли команда, или команда чудо-разрабов). Им потребуется минимальное время, чтобы понять структуру кода и начать его исправлять, или дополнять. Никаких неявных петель и ловушек вроде таких вот чудо-замыканий, они не получат в моем коде, я даже никогда не делаю дубли в именовании явно-объявляемых переменных внутри функций, не говоря уже о том, чтобы произошел нахлест в глобальной области видимости.
На курсы — запишитесь при любом университете технической направленности (а то я как закончил Универ радиотехнический по направлению автоматизация и управление, так и программирую после этого и учусь не в википедии, а по документации к языкам и аппаратным комплексам).
И да, не по викепилдии, а по документации языка и разработчиков (мозила):
Замыкание — это комбинация функции и лексического окружения, в котором эта функция была определена.
А теперь вопрос супер-пупер программисту википедийному, eH001 — определена где? Внутри функции какой то? ИЛи на глобальном уровне вне окружения функций?
Жесть, и вот такое чудо-разрабо, программистом работает, жесть просто — где работаете? Надо вашему нанимателю линк скинуть на ваши комменты здесь, чтобы он понял кто у него работает.
На счет не работает — откуда мне знать, что вы там вызываете своими объектами.
Запишите обработчик для проверки так, чтобы узнать в консоли работает или нет:
function eH001(){if (this.status == 200){console.log('OK!')}else{console.log('NO!');}
}
>@b00taNik Кроме того, что он не работает так еще и замыкания использует,
Вы тоже не пишите больше, а идите учиться на курсы начальные — также ниже джуниора левел, который в принципе не знает что такое замыкания. (вам тоже бесплатный урок — назначение события, либо передача имени функции аргументом [без скобок], это не замыкание. Явное объявление функции, либо вызов в анонимном варианте [со скобками] внутри другой функции — вот что является замыканием в JS и что позволяет сохранять состояния переменных. В моем же коде, нет никаких замыканий, и в обработчике, this будет всем, на что в любой из функций повесят этот обработчик, и, как вы не извращайтесь, но он никогда не сохранит состояние предыдущего вызова если его вызвали повторно. Учите матчасть, поднимитесь до джуниора хотя бы. И не смешите народ и не позорьтесь — не пишите чушь больше здесь.
Весь fetch этого чудо-автора ниже джуниора, это регистрация промиса, резервирование состояний, объявление функций response и reject, запуск таймера опроса промиса для получения состояния исполнения, и, только затем, исполнение ТОГО ЖЕ КОДА ОТ xmlhttprequest:
То есть, такой вот чудо-разраб, который начитался таких же чудо-разрабов придумавших fetch, чтобы не писать код обработки XMLHTTPRequest, взял и на ровном месте в 3 раза увеличил нагрузку на ПК юзера, просто так, чтобы не писать пару лишних строк.
Ну, я могу понять, любишь ты короткие записи, напиши просто функцию обертку тогда, чтобы её вызывать вместо кода самого XMLHTTPRequest, и обзови там её myfetch(respose, reject) и вызывай — даже это будет в разищи быстрее и лучше, чем вызывать этот промис тормознутый и проблеммный.
Но нет, этот чудо-программер, будет бить себя пяткой в грудь, убивать машину юзеру, но не снизойдет до изучения чего-либо, а просто будет читать таких же супер-пупер профи.
fetch всего лишь обертка для XMLHTTPRequest, чтобы такие неумехи, как вы писали меньше букв, не понимая технологии запроса данных. Если вы не понимаете, как написать XMLHTTPRequest запрос с if else (и при необходимости, заюзать catch), как в вашем fetch-е — просто идите на курсы базовые по программированию что-ли.
Теперь же бэкэнд вырос и избавился от этой шняги и такие вот горе-профи (аааа жесть просто) теперь пытаются впихнуть это старье во фронт энд, и всё по той же причине, чтобы также как и тогда в бэкэнде, обойти ограничения синхронности языка.
Но вот беда, работа кода в бэкэнде и работа его во фронтэнде, подчиняются абсолютно разным правилам и проходят очень-очень разные этапы проверок и допусков. И понятное дело, что обмен данными между мнимо-асинхронными функциями, во фронтэнде, просто теряет свой смысл из-за его слишком большой задержки (проверка ядром системы, проверка браузером, проверка анти-вирусом и прочими сторонними наблюдателями в системе).
Не пытайтесь писать на фронтэнде то, что нельзя на нем писать, притащив в него устаревшие технологии из бэкэнда! Хотите работу приложения как в бэкэнде, да млина, — пишите на бэкэнде, а фронтэнд подгружайте в виде интерфейса только, а не для работы и вычислений (не умеете так? слишком сложно для вас? — учитесь, или заказывайте у тех, кто может, но не пытайтесь городить шнягу убогую на том, на чем её не следует городить).
Тоже самое тут про virtual dom кто-то писал в комментах, ну и у самого автора поста это как раз-таки вызвало бурю негатива — и да, я полностью его поддерживаю в этом. Бла-бла-бла Senior… — не знаешь вирутал? не, не сениор. А вот собеседующий сам в курсе, что даже не junior, а первый месяц изучающий любой язык джуниор, уже знает и всегда использует только виртуал дом? 10-20 лет назад, любой, кто начинал попытку использования в своем бэкэнде web интерфейса (подгрузив объект webbrowser, или создав из своей программы экземпляры штатного веббраузера системы) тут же, при первом опыте внедрения большого потока данных в реальный дом, сталкивается с тем, что без виртуал, его код не будет работать. Ибо, подвесив свой ПК таким обращением в реальный дом, он начинает анализировать, что же произошло и находит причину, что работа с прямым дом, контролируемым всеми и вся, так нагружает и тормозит пк — что работа с ним просто не реальна.
И он тут же изобретает свой виртуал дом и обрабатывает его штатными регэкспами в памяти, выгружая в файлы готовые куски кода, если их слишком много для работы из памяти напрямую, а затем уже использует эти куски в своем веб интерфейсе. О чудо, спустя 20 лет, кто-то изобрел то же самое и назвал это virtual dom — и это да, это важно, это только для senior-ов технология, только они в курсе, как это и для чего :( аааа, жесть просто, не хватает уже эмоций на таких вот чудо-профи — куда катится мир программирования? Что, никто больше не хочет думать? Все читают каких-то ущербных чудо-разрабов, чтобы самим стать такими же ущербными и писать всякую чушь к месту и нет? Кто-то читает вообще спецификации самих языков? Спецификации ОС и аппаратной части ПК? Чтобы понимать, как работает тот, или иной метод в реальности?
Ладно, хватит лирики, тут на хабре я читал только от пары человек статьи, которые объясняли, как работает на низком уровне та, или иная функция языка, или препроцессора (в зависимости от того, что освещал автор). Это были переводы статей конечно, но сам факт, что человек правильно перевел такие статьи, дает мне право считать, что он также понимает, как работает то, что он переводит. Все остальные тут, смотрю, даже близко не представляют, как работает их чудо-супер-пупер технология замыканий, промисов и прочая чушь, в реальности и какие порождает процессы на низком уровне.
Все, кто тут отписался, считая себя суепр-профи знатоком, давайте эксперимент — скидывайте код, где вы считаете уместным замыкание, промис и т.д. Я переделываю его в свой код без всей этой чуши, и мы вставляем его в тело реальной страницы, нагруженной эффектами движения, графикой и прочим. Запускаем циклично тест этой (этих функций) и пишем видео с экрана работы этой страницы во время выполнения наших кодов, активно взаимодействуя с элементами страницы (скрлим, наводим мышь на элементы, выделяем текст, кликаем правой кнопкой мыши — в общем делаем все то, что делает пользователь на странице, просто не открывая новых вкладок).
По окончании работы теста, сохраняем данные использования памяти, CPU, GPU, время работы кодов (ну и выкладываем видео на общее обозрение, как ведет себя страница в браузере пока работает ваш и мой код — оба типа у каждого на ПК, чтобы было видно, как работает разный код на одном и том же ПК).
Вот тогда, мы и будем уже более детально обсуждать чудо-супер-пупер технологии на реальном примере, а не на сферическом коне в вакууме.
На счет промисов — тут есть конечно нюансы, ввиду синхронности js, но мое отношение к промисам также негативное (работу кончено не пойдет искать, но прослушает двухчасовую беседу о том, как разбивать задачи на минимальные составляющие для обеспечения стабильности и прозрачности работы кода).
Но саму возможность использования промисов, в каких-то непонятных, внеземных проектах, я конечно не отрицаю. Как по мне, промисы в js придумал какой-то редкий м....., который ранее работал в глубоком бэкенде, на c++, с функциями асинхронного вызова и обработки данных без потоков, через медиаторы, в самих кодах классов.
Сидел он значит, изучал фронтенд (новое для себя дело) и встал в ступор — а почему нельзя в js через те же медиаторы и обертки событий, как было в классах на c++, обойти синхронность языка? Давай-ка я напишу это, чтобы и здесь реализовать мнимо-неблокируемый интерфейс, и назову всё это дело промисом!
А нужно-ли это во фронте?, или это создаст для работы кода еще больше проблем? — эт. дело десятое, главное мы из JS теперь сделаем крутой язык, приближающийся к бэку!
А особенно, из анимации на самом примере в статье: сам хаотичный поиск пути объектами и движение их по свободным полям, может вызвать когнитивный диссонанс у пользователя, а не быстрая смена всех элементов, хоть они и пересеклись бы (ну желательно чтобы главный элемент проехал НАД всеми остальными, но все остальные — абсолютно без разницы, как там смещались бы, относительно друг-друга).
>>Если пути движущихся объектов пересекаются друг с другом, они не могут проходить друг через друга.
Это далеко не факт. Уточнение в следующем пункте — что объект должен подняться, а не пройти под другими, уже лучше, но сам пункт о не пересечении, как бы сомнителен и может, наоборот, оказаться менее удачным решением.
700 единиц хранения на каждую папку (примите как аксиому от человека, который на практике тестировал всё это), то есть в каждой папке или 700 других папок, или 700 файлов, если это конечная глубина. 4 уровня вниз — 343 миллиона файлов в одной старшей папке.
Все имена файлов только цифрой, которая является ключом в БД. Если записи о файлах хранятся в разных таблицах — разные папки для каждой таблицы. Поиск пути, где сохранен файл, по цифре ключа из бд — самая быстрая операция, которую вы сможете придумать с файлом в таких количествах.
Я в реальных сайтах использую эту нумерацию не только для хранения файлов изображений, но и для файлов кэша всех страниц сайта на диске.
Лень делать скрины, но приведу вам стату: по запросу в гугле site: мой домен — ответ примерно такой: нашлось примерно 243 миллиона страниц.
В консоли гугла, средняя скорость загрузки страниц — 242 мc. Хостинг шаред (общий тысячи пользователей на одной машине) 300 рублей в месяц, плюс 50Гб места докупил, чтобы файлы влезали, нагрузки нет особой на хостинг от моего сайта этого.