Здравствуйте. А можете пояснить историю возникновения статьи? Да, понимаю, что вы хотели попасть на хабр. Интересно, почему? И почему была выбрана именно эта тема?
Ну и такой отвлеченный вопрос. Пропсы - это аргументы функции компонента. Скорее всего вы какую другую идею хотели пояснить?
когда в React я прокидываю пропсы и использую их в компоненте — это замыкание.
А что вы подразумеваете под эвристическим алгоритмом? Знаменитую фразу, что полное сравнение деревьев при реконсилиации занимает O(n^3), а мы сделали так, что работает за O(n) ? Или общие оптимизационные техники, которые применяются в кодовой базе реакта?
Если вы про первое, то в общих чертах их эвристика достаточна прямолинейна. Это сравнение сначала по key. Если они не совпадают, дальнейшие проверки \ сравнения не производятся, а полностью пересоздается файбер. Потом идет сравнение по type. Потом сравнение props через shallowEqual... Благодаря чему объем сравнений сокращается в разы.
Если про второе, то там много хитрых наворотов. Это серьезная работа на уровне ссылочных структур данных (деревья файберов, списки обновлений). Это и применение битовых масок для выражения различных идей (фазы рендеринга, приоритета обновления, результата построения WIP файбер дерева и тд). Это и правильный подбор структур данных под необходимые им нужды, как например min heap для сортировки списка задач. И подбор оптимальных средств API host среды, где выполняется react, типа PostMessage или isInputPending. Копать не перекопать.
Здравствуйте.. Полююбопытствую. А какую книгу по хаскелю вы читали, и за какое время? Просто сам читаю\ем книгу "хаскель с первых принципов" - и судя по той сорости с которой идем, её прохождение займет год (уже осилили 35%).
Интересен ваш опыт, практики, советы по чтению подоюных книг, где впервые встречаешься с новой парадигмой.
Подтверждаю. Получается, что в наши дни любопытство можно отнести уже к роскоши. Когда у человека есть свободное время на то, чтобы не просто пользоваться чем-то, а изучить, как это внутри устроено, для себя, в свое удовольствие.
Что забавно, такие люди ценятся работодателем больше. Они более эрудированы, быстрее и качественнее принимают решения. Однако попросить на работе тоже свободное время на свое любопытство, условно говоря час в день:
«Мы тебе платим не за твое развитие и обучение...»
«Таких как ты — миллион за забором...»
«Чего ты стал много хотелок и вопросов задавать...»
«И да, ты, именно ты, джун фронта, если ночью хочешь что-то поизучать, поизучай плиз graphQl. Надо чтобы завтра он уже стоял в проекте и работал...»
«Нет, ты не понял. Надо чтобы завтра он был встроен в проект и работал. Разбираться в нем не надо...»
В современном мире, перегруженном информацией и задачами, любопытство не поощряется. Не на то время тратишь, холоп. Да, вот прям такое ощущение.
Может не совсем в тему, но следующая фраза меня заинтересовала. Приходилось
бороться с этой ситуацией
Когда же я сказал, что исходных кодов там нет, ответ студента был в стиле «ну раз вы так говорите, то я всё исправлю».
Защитный блок. Даже не знаю в какой плоскости это выразить. Не хочет или не может студент с вами общаться искренне. Считаю это одним из существенных препятствий при передаче знаний от вас к нему, затормаживающих саморазвитие студента.
Он будет слушать вас, лабораторки делать… Потому что так надо, таковы правила учебного заведения. А проявлять собственную инициативу в виде дополнительного исследования — неа. Ему невыгодно. Или вскроется, что у него недостаточныe знания (его заругают или оценку низкую поставят). Или он вообще не хочет этим заниматься, но признаваться в этом — стыдно, особенно вам. Возможно, он хотел бы проделать что-то подобное, но времени не хватает. Но вам об этом, соответственно, не скажет. Причин может быть много, и у каждого они будут свои.
И вот если пофантазировать, то в идеале, прежде чем начать изучать какие-то серьезные вещи, было бы хорошо установить психологический комфорт преподавателя и студента. Чтобы преподаватель и ученик стояли на одном ментальном что ли уровне. Тогда можно будет найти первопричины такого поведения учащихся.
Продолжаем фантазии…
Представьте, что у вас была бы возможность на самой первой лекции сказать примерно следующее. Так ребята, программирование — это очень занятная штука: можно реализовывать свои идеи, экспериментировать, ошибаться, веселиться. Да, надо будет учиться. Но это интересный процесс, и если надо, я вам помогу.
Понимаю, что вы новички. Но не будет оценок, каждый может изучать материал в своем темпе, буду помогать всем независимо от вашего уровня. А если это вам
совсем неинтересно — ничего страшного. Попробуете пару лекций \ лабораторок, определитесь, что вам это не интересно, и никаких к вам вопросов — свободны. А чтобы подтвердить свои слова — зачетки на стол. Всем ставлю зачет, чтобы это не было какой-то помехой при погружении в эту занимательную сферу.
Кажется, что после месяца на занятия придут… В нашей группе пришло 2 человека. Зато у этих 2 человек как раз было то, что мы слегка потеряли в этой статье. Настоящее любопытство. А остальных студентов можно потом просто спросить, чего же им не хватило. Думаю, половина из них вам это спокойно могла бы рассказать с чистой душой.
Т.е. Promise автоматом делает ЛЮБОЙ код асинхронным? Или без асинхронного вызова типа setTimeout() всё равно никакой асинхронности не будет?!
1) Извините, что буду отвечать не совсем прямо на ваш вопрос. Но начнем немного с другого. Promise — сквозь призму ваших слов выглядит как функция, которая взяла — что-то сделала магическое — и завершилась, отдав какой то результат. Все, как в классике: есть функция — значит она должна что-то получить на вход и что-то отдать на выход.
Вот тут необходимо немного изменить восприятие того, что такое промис. Промисы — это не сколько прямое получение результата чего-то, сколько запуск некоторой логики во времени. То есть, связавшись с промисом, вы получаете цепочку взаимосвязанных действий, следующих друг за другом, которая в какой-то момент времени закончится с каким-то результатом.
И ваш вопрос не следует воспринимать буквально напрямик: «делает ли промис мой код асинхронным...?» Скорее надо задавать вопрос так. А вот мой код, который я напишу там-то (в executor-e) или тут-то (в коллбеке then() ) или еще где-то (например, в Promise.resolve()) — как он будет выполняться в уже имеющейся системе действий, которые скрыты от ваших глаз под капотом движка JS?
Если код будет выполняться построчно здесь и сейчас — значит код выполняется синхронно. Если же мы откладываем его на какой-то промежуток времени на будущее — значит асинхронно.
2) И тут возникает хороший вопрос. А что же это за система действий, которая выполняется во времени, и которая скрыта от наших глаз? Зная эту систему, и как наш код в неё встраивается, мы легко ответим на множество сейчас неочевидных вопросов. Прямо как система хуков =)
Данная «система действий» довольно хорошо описано в EcmaScript спецификации. Лично вот сам жду, когда же выйдет статья, которая просто и тупо опишет все те шаги, которые описаны в спецификации, только на «понятном русском языке». А то все только описывают теории вокруг да около. Пока ждал, сам прочитал и разобрался. Даже думал серию статей сюда написать…
Немного отвлекся. Ну так вот, возвращаясь к промисам, отвечаю наконец-то прямо на ваш вопрос. Код внутри executor фукнции new Promise( (res, rej)=>{/* тело executor функции */} ) будет выполняться всегда здесь и сейчас, как только интерпретатор дошел до команды new Promise() — то есть всегда синхронно.
И не важно, напишете вы внутри setTimeout или fetch или что-еще — сама executor функция выполнится до финиша, после чего вам вернется на руки промис-объект. Этот промис объект
будет всегда, вот только его состояние определяется тем, был ли синхронно вызван коллбек-res-параметр executor функции внутри executor фукнции, или вызов коллбек-res-параметра отложили когда-то на потом через setTimeout тот же.
Успели синхронно вызвать коллбек-res-параметр — получите промис в состоянии fulfilled после выполнения new Promise(). Перенесли на будущее вызов — получившийся промис будет в состоянии pending.
И если вы думаете, что на этом подковерная цепочка действий внутренней логики промисов завершилась — то это заблуждение. Там потом такие «повороты сюжета» идут — просто… then одним словом.
Если в этой статье для вас не слишком явно описаны первоначальные нюансы использовния промисов — попробуйте эту статью. habr.com/ru/post/478938 — что называется минутка саморекламы. Там ответ на ваш вопрос описан более подробно в подзаголовке «Алгоритм создания promise объекта по спецификации ECMAScript».
Фундаментальные знания о программировании сложно найти, тяжело понять и невозможно забыть,
Вы прямо выразили мою боль. На тебя смотрят как на «не от мира сего», когда пытаешься людям сказать, что лучше вложиться временем в основы, чем в модные фреймворки.
— «Нет. Это не принесет здесь и сейчас денег. Это не нужно не рынке.»
— «Так вы же потом это все еще 10 раз наверстаете. У вас по крайней мере будет точка опоры, от которой вы сможете оттолкнуться при изучении тех же новомодных фич. Вы сможете созидать не бессмыслицу, а обоснованные и грамотные решения!»
И снова взгляд непонимания… И снова остаюсь в одиночестве, разгрызая очередной гранит спецификации \ паттерна \ алгоритма…
Ладно, не все так грустно. Некоторых людей уже сумел перетянуть на свою сторону. Теперь 2 пары, нет 3, 4, 5 пар глаз жадно поглощают информацию, осознавая что и зачем они учат. Увидели границы, выработали план, стремимся к мечте… стать настоящими программистами, а не кодерами.
1. Когда тренировал «напарников», вопрос абстракции стоял особенно остро, так как именно эта тема связывает мышление человека с кодом и моделированием реального мира. «Напарники» воспринимали программирование, как какой-то умный код для вычисления последовательности действий. Но предложение «запрограммируй мне любовь или математику или кошку или яблоко...» просто ставило их в тупик.
2. Решилось довольно просто. На протяжении месяца играли в игру подобную этой. {«колеса: 2, руль: true, name:'Аист'»} — угадайте что это. Потом 2 недели заставлял составлять цепочки вверх и вниз подобные этой на любую тематику "… шалаш — здание — техническое сооружение — материальность — бытие — вселенная… "
3. После этого «напарники» спокойно уже на автомате могли любую вещь из мира замоделировать и превратить в код. ООП подтянулось незаметно и без боли.
4. Теперь они других гоняют по терминам «абстракция», «сущность», «модель», «объект» «прототип» и т.д.
Здравствуйте. А можете пояснить историю возникновения статьи? Да, понимаю, что вы хотели попасть на хабр. Интересно, почему? И почему была выбрана именно эта тема?
Ну и такой отвлеченный вопрос. Пропсы - это аргументы функции компонента. Скорее всего вы какую другую идею хотели пояснить?
А что вы подразумеваете под эвристическим алгоритмом? Знаменитую фразу, что полное сравнение деревьев при реконсилиации занимает O(n^3), а мы сделали так, что работает за O(n) ? Или общие оптимизационные техники, которые применяются в кодовой базе реакта?
Если вы про первое, то в общих чертах их эвристика достаточна прямолинейна. Это сравнение сначала по
key. Если они не совпадают, дальнейшие проверки \ сравнения не производятся, а полностью пересоздается файбер. Потом идет сравнение поtype. Потом сравнениеpropsчерез shallowEqual... Благодаря чему объем сравнений сокращается в разы.Если про второе, то там много хитрых наворотов. Это серьезная работа на уровне ссылочных структур данных (деревья файберов, списки обновлений). Это и применение битовых масок для выражения различных идей (фазы рендеринга, приоритета обновления, результата построения WIP файбер дерева и тд). Это и правильный подбор структур данных под необходимые им нужды, как например min heap для сортировки списка задач. И подбор оптимальных средств API host среды, где выполняется react, типа PostMessage или isInputPending. Копать не перекопать.
Здравствуйте.. Полююбопытствую. А какую книгу по хаскелю вы читали, и за какое время? Просто сам читаю\ем книгу "хаскель с первых принципов" - и судя по той сорости с которой идем, её прохождение займет год (уже осилили 35%).
Интересен ваш опыт, практики, советы по чтению подоюных книг, где впервые встречаешься с новой парадигмой.
Что забавно, такие люди ценятся работодателем больше. Они более эрудированы, быстрее и качественнее принимают решения. Однако попросить на работе тоже свободное время на свое любопытство, условно говоря час в день:
В современном мире, перегруженном информацией и задачами, любопытство не поощряется. Не на то время тратишь, холоп. Да, вот прям такое ощущение.
бороться с этой ситуацией
Защитный блок. Даже не знаю в какой плоскости это выразить. Не хочет или не может студент с вами общаться искренне. Считаю это одним из существенных препятствий при передаче знаний от вас к нему, затормаживающих саморазвитие студента.
Он будет слушать вас, лабораторки делать… Потому что так надо, таковы правила учебного заведения. А проявлять собственную инициативу в виде дополнительного исследования — неа. Ему невыгодно. Или вскроется, что у него недостаточныe знания (его заругают или оценку низкую поставят). Или он вообще не хочет этим заниматься, но признаваться в этом — стыдно, особенно вам. Возможно, он хотел бы проделать что-то подобное, но времени не хватает. Но вам об этом, соответственно, не скажет. Причин может быть много, и у каждого они будут свои.
И вот если пофантазировать, то в идеале, прежде чем начать изучать какие-то серьезные вещи, было бы хорошо установить психологический комфорт преподавателя и студента. Чтобы преподаватель и ученик стояли на одном ментальном что ли уровне. Тогда можно будет найти первопричины такого поведения учащихся.
Продолжаем фантазии…
Представьте, что у вас была бы возможность на самой первой лекции сказать примерно следующее. Так ребята, программирование — это очень занятная штука: можно реализовывать свои идеи, экспериментировать, ошибаться, веселиться. Да, надо будет учиться. Но это интересный процесс, и если надо, я вам помогу.
Понимаю, что вы новички. Но не будет оценок, каждый может изучать материал в своем темпе, буду помогать всем независимо от вашего уровня. А если это вам
совсем неинтересно — ничего страшного. Попробуете пару лекций \ лабораторок, определитесь, что вам это не интересно, и никаких к вам вопросов — свободны. А чтобы подтвердить свои слова — зачетки на стол. Всем ставлю зачет, чтобы это не было какой-то помехой при погружении в эту занимательную сферу.
Кажется, что после месяца на занятия придут… В нашей группе пришло 2 человека. Зато у этих 2 человек как раз было то, что мы слегка потеряли в этой статье. Настоящее любопытство. А остальных студентов можно потом просто спросить, чего же им не хватило. Думаю, половина из них вам это спокойно могла бы рассказать с чистой душой.
1) Извините, что буду отвечать не совсем прямо на ваш вопрос. Но начнем немного с другого. Promise — сквозь призму ваших слов выглядит как функция, которая взяла — что-то сделала магическое — и завершилась, отдав какой то результат. Все, как в классике: есть функция — значит она должна что-то получить на вход и что-то отдать на выход.
Вот тут необходимо немного изменить восприятие того, что такое промис. Промисы — это не сколько прямое получение результата чего-то, сколько запуск некоторой логики во времени. То есть, связавшись с промисом, вы получаете цепочку взаимосвязанных действий, следующих друг за другом, которая в какой-то момент времени закончится с каким-то результатом.
И ваш вопрос не следует воспринимать буквально напрямик: «делает ли промис мой код асинхронным...?» Скорее надо задавать вопрос так. А вот мой код, который я напишу там-то (в executor-e) или тут-то (в коллбеке then() ) или еще где-то (например, в Promise.resolve()) — как он будет выполняться в уже имеющейся системе действий, которые скрыты от ваших глаз под капотом движка JS?
Если код будет выполняться построчно здесь и сейчас — значит код выполняется синхронно. Если же мы откладываем его на какой-то промежуток времени на будущее — значит асинхронно.
2) И тут возникает хороший вопрос. А что же это за система действий, которая выполняется во времени, и которая скрыта от наших глаз? Зная эту систему, и как наш код в неё встраивается, мы легко ответим на множество сейчас неочевидных вопросов. Прямо как система хуков =)
Данная «система действий» довольно хорошо описано в EcmaScript спецификации. Лично вот сам жду, когда же выйдет статья, которая просто и тупо опишет все те шаги, которые описаны в спецификации, только на «понятном русском языке». А то все только описывают теории вокруг да около. Пока ждал, сам прочитал и разобрался. Даже думал серию статей сюда написать…
Немного отвлекся. Ну так вот, возвращаясь к промисам, отвечаю наконец-то прямо на ваш вопрос. Код внутри executor фукнции new Promise( (res, rej)=>{/* тело executor функции */} ) будет выполняться всегда здесь и сейчас, как только интерпретатор дошел до команды new Promise() — то есть всегда синхронно.
И не важно, напишете вы внутри setTimeout или fetch или что-еще — сама executor функция выполнится до финиша, после чего вам вернется на руки промис-объект. Этот промис объект
будет всегда, вот только его состояние определяется тем, был ли синхронно вызван коллбек-res-параметр executor функции внутри executor фукнции, или вызов коллбек-res-параметра отложили когда-то на потом через setTimeout тот же.
Успели синхронно вызвать коллбек-res-параметр — получите промис в состоянии fulfilled после выполнения new Promise(). Перенесли на будущее вызов — получившийся промис будет в состоянии pending.
И если вы думаете, что на этом подковерная цепочка действий внутренней логики промисов завершилась — то это заблуждение. Там потом такие «повороты сюжета» идут — просто… then одним словом.
Если в этой статье для вас не слишком явно описаны первоначальные нюансы использовния промисов — попробуйте эту статью. habr.com/ru/post/478938 — что называется минутка саморекламы. Там ответ на ваш вопрос описан более подробно в подзаголовке «Алгоритм создания promise объекта по спецификации ECMAScript».
Вы прямо выразили мою боль. На тебя смотрят как на «не от мира сего», когда пытаешься людям сказать, что лучше вложиться временем в основы, чем в модные фреймворки.
— «Нет. Это не принесет здесь и сейчас денег. Это не нужно не рынке.»
— «Так вы же потом это все еще 10 раз наверстаете. У вас по крайней мере будет точка опоры, от которой вы сможете оттолкнуться при изучении тех же новомодных фич. Вы сможете созидать не бессмыслицу, а обоснованные и грамотные решения!»
И снова взгляд непонимания… И снова остаюсь в одиночестве, разгрызая очередной гранит спецификации \ паттерна \ алгоритма…
Ладно, не все так грустно. Некоторых людей уже сумел перетянуть на свою сторону. Теперь 2 пары, нет 3, 4, 5 пар глаз жадно поглощают информацию, осознавая что и зачем они учат. Увидели границы, выработали план, стремимся к мечте… стать настоящими программистами, а не кодерами.
1. Когда тренировал «напарников», вопрос абстракции стоял особенно остро, так как именно эта тема связывает мышление человека с кодом и моделированием реального мира. «Напарники» воспринимали программирование, как какой-то умный код для вычисления последовательности действий. Но предложение «запрограммируй мне любовь или математику или кошку или яблоко...» просто ставило их в тупик.
2. Решилось довольно просто. На протяжении месяца играли в игру подобную этой. {«колеса: 2, руль: true, name:'Аист'»} — угадайте что это. Потом 2 недели заставлял составлять цепочки вверх и вниз подобные этой на любую тематику "… шалаш — здание — техническое сооружение — материальность — бытие — вселенная… "
3. После этого «напарники» спокойно уже на автомате могли любую вещь из мира замоделировать и превратить в код. ООП подтянулось незаметно и без боли.
4. Теперь они других гоняют по терминам «абстракция», «сущность», «модель», «объект» «прототип» и т.д.