Больше пары строк кода в посте или на скриншоте ведут в ад.
Для программирования на HTML https://codesandbox.io
Для Node.js с консолькой https://repl.it/languages/nodejs
Если рассчитываешь получить дельный ответ, сформулируй правильно вопрос: «что я хочу получить, что я для этого делаю, что я вместо этого получаю». Если/когда самостоятельно найдёшь решение — поделись в треде, мы за тебя переживаем.
Документация - https://developer.mozilla.org
Руководство для вката - https://github.com/acilsd/wrk-fet#javascript
бамп
Профессионалам нужны профессиональные инструменты, которые ускоряют процесс работы. Это все равно что сказать - водителю нажна только баранка и педаль газа, пердоль и пердоль 24 на семь. Но сев в вольво 2020 года и затем вернувшись в жигули водитель будет вблевать от того, насколько уебищен второй вариант, как мало в нем функционала
Ну так вскод дерьмо как блокнот с плагинами, эта ниша уже давно прочно занята божественным ST. А если тебе нужна IDE под что-то, кроме жопоскрипта, то это почти наверняка будет какой-то жидбрейнс продукт, да и то, вебсторм/пхпсторм под джаваскрипт лучше, чем вскод, просто вскод из коробки настроен удобнее.
как получить tagName класса HTML-элемента, не создавая экземпляр класса?
Например, getTagName(window.HTMLTableCellElement) должно возвращать 'TD' (ну или 'td', не важно). При этом элемент не должен создаваться. Как написать такую функцию getTagName?
Пробовал window.HTMLTableCellElement.prototype.tagName — кидает TypeError: Illegal invocation
>Код Fleet в основном пишется на Kotlin, соответственно, он выполняется на JVM.
> Зачем такие извращения? Какая цель?
Вот надо мне, например, создать экземпляр класса. Что это за класс, я не знаю заранее, он берётся динамически. Если я напишу new someClass(), а потом окажется, что someClass === window.HTMLTableCellElement, то будет TypeError: Illegal constructor, ведь надо это делать с помощью document.createElement('td');
поэтому нужна функция для создания экземпляров (в том числе HTML-классов) без этой ошибки:
function createClassInstance(Class) {
if (Object.getPrototypeOf(Class) !== window.HTMLElement) {
return new Class();
} else {
return document.createElement(getTagName(Class))
}
}
Ну вот и как это getTagName можно реализовать?
> Зачем ты в принципе пытаешься смешать создание обычных классов и создание html-элементов, наркоман?
Чтобы можно было нормально расширять классы HTML-элементов для добавления нужной функциональности и потом их использовать наравне с HTML-элементами (и то, и другое создавать через вышеупомянутую функцию createClassInstance).
Кстати, для расширения класса HTML-элемента тоже пригодится функция getTagName(HTMLClass). Сейчас я не нашёл нужный файл с кодом, но помню, там была примерно такая функция:
function extendHTMLClass(HTMLClass, tagName) {
return class extends HTMLClass {
constructor() {
return document.createElement(tagName);
}
}
}
и от результата этой функции уже можно нормально наследовать (а то ведь напрямую от HTML-класса наследовать нельзя, будет ошибка при создании экземпляра).
Так вот, имея функцию getTagName(HTMLClass), можно намного удобнее реализовать функцию extendHTMLClass, которая вместо двух аргументов (HTMLClass, tagName) будет принимать только один (HTMLClass), а внутри уже делать const tagName = getTagName(HTMLClass); так не будет возможности того, что tagName не соответствует переданному классу, что поможет избежать ошибок.
Это лютейший говнокод, наследование это и так антипаттерн ООП в 99% случаев, а ты еще и динамическое наследование накостылил. И это все еще не ответ на вопрос "нахуя тебе это нужно", на него надо отвечать с точки зрения бизнес-логики: "чтобы нарисовать вот такую штуку и вот такую", а не "ну вот у меня тут уровнем повыше еще костыль и я его хочу обслужить", потому что тут опять возникает вопрос, а нахуя тебе теперь лютый костыль, который ты обслуживаешь костылями поменьше, в которых уже сам запутался >>2261021>>2261054
>Чтобы можно было нормально расширять классы HTML-элементов для добавления нужной функциональности и потом их использовать наравне с HTML-элементами (и то, и другое создавать через вышеупомянутую функцию createClassInstance).
Алё, тебе шаблоны прямо в среду завезли, расширяй и наследуй сколько хочешь почти без костылей.
https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_templates_and_slots
>а то ведь напрямую от HTML-класса наследовать нельзя, будет ошибка при создании экземпляра
Так потому что это не классы, а интерфейсы.
> И это все еще не ответ на вопрос "нахуя тебе это нужно", на него надо отвечать с точки зрения бизнес-логики: "чтобы нарисовать вот такую штуку и вот такую"
Так ведь много для чего нужно. Чтоб новый функционал добавлять элементам. В основном для динамических таблиц (UI для заполнения таблиц учёта выпущенных машин, автоматическая проверка и генерация отчётов о соответствии контрольных точек нормам и т. д.), да и вообще для любого поведения элемента.
Думаю, это всё можно было бы на том же Реакте сделать намного проще, но сторонние библиотеки нет возможности использовать из-за норм информационной безопасности на предприятии (оно хоть и не режимное, но выпускает продукцию для авиационной промышленности, поэтому всё довольно засекречено, и выход в инет у нас заблокирован, свои носители цифровой информации тоже подключать запрещено).
>несмотря на то, что код обмазан тестами и типами
Если обмазан тестами а нахуя еще фейкер нужен, если не для тестов?, то ничего сломать не могло, там до любого деплоя/билда бы вылезла эта проблема, если тесты реально используются и что-то проверяют, а не для галочки. Типы да, но это не секрет, что типы нихуя не делают и не могут делать для проверки реальной работоспособности программы.
А поч на фронте нельзя нахуярить без него?
или вот хорошая штучка http://mockjs.com/examples.html https://github.com/nuysoft/Mock
Придумывать ты можешь где угодно, хоть на очке, хоть на листке бумаги, вопрос в том, каким образом поведение соотносится с type signature? Правильный ответ - никак, потому что из "эта функция принимает строку и возвращает строку" ты никогда не выведешь "а, ну это наверное локализация там реализована".
Потому что код приходится постоянно рефакторить из-за субъективных причин. Например меняются требования в ТЗ. Хорошо когда ты знаешь кто использует интерфей который ты хочешь обновить. Отладка тоже облегчается (но не сильно), меньше гадать по ключам в стеке вызова что это за объект ты смотришь
Термин "рефакторинг" означает изменение внутренней структуры кода без изменения внешнего интерфейса, так что тебя ебать не должно, кто там что использует снаружи. И при рефакторинге тебе нужно знать одну вещь - что поведение зарефакторенного кода не поменялось. А так как мы уже выяснили, что типы поведение не определяют, то и при рефакторинге они не помощники, любой рефакторинг требует прежде всего тестов. А если ты перелопачиваешь поведение всего кода в проекте, то во-первых это уже не рефакторинг, а обычная имплементация фич, а во-вторых тебя так же должно интересовать в первую очередь поведение этого кода, а не то, что там манятип правильный передался.
> Рефакторинг это как раз улучшение структуры кода
Гугли определение, но я тебе могу его сказать и так: Рефакторинг - это улучшение внутренней структуры кода, без изменения поведения этого кода
>и его соответствия задаче
Никакие изменения поведения к рефакторингу не относятся, это обычная доработка/багфикс, что угодно, но не рефакторинг. В процессе рефакторинга ты можешь обнаружить какой-то баг в коде, потому что код стал лучше и читаемее, и тут же поправить этот баг, но это побочный эффект, а не цель рефакторинга.
>Люди периодически рефакторят код чтобы приспособить его к задачам
"Приспособить к задачам" и "реализовать задачу" - это две абсолютно разные вещи. Ты путаешь процесс с целью. Разумеется, конечная цель рефакторинга - это чтобы код можно было лучше читать, удобнее менять, и так далее. Но сам процесс рефакторинга изменений в функционале не подразумевает, они идут уже следующим этапом.
Ну я и говорю приспособить к задаче. Чтобы можно было хотелки заказчика выразить в к оде без потери им расширяемости, не просто хатэтэпе метод дернуть. Вот у тебя есть к примеру класс Messanger c с методом sendMessage(message: string). Приходит кабан и говорит: "Раньше мы отправляли только текстовые сообщения через сервис наших партнеров, теперь появилась возможность отправлять картинки и файлы. Сычов реализуй". Заменить метод sendMessage(message: string) на sendMessage<T extends MessageContainer>(message: T) это рефакторинг или разработка?
Но я же не решаю задачу таким способом. Я просто меняю интерфейсы. Я все поменял код не сломался, все тесты я обновил чтобы они параметрический код тестировали. Но я не могу придти к кабану и сказать задача выполнена картинки отправляются. Отправляются по прежнему только строки. Но код стал больше соответствовать текущим задачам.
>Я просто меняю интерфейсы
И какой смысл в этом изменении? Ты точно так же отправляешь строку, но теперь оборачиваешь ее в лишний бесполезный объект. Нахуя? Данное изменения не имеет никакого смысла в отрыве от задачи по отправке картинок и вносить его отдельно так же смысла нет, сразу уж добавляй картинки туда. Рефакторингом это было бы, если бы sendMessage функция была простыней из сотни строк, а ты бы ее внутри разбил на функции поменьше, чтобы код читался и понимался лучше. Такое изменение имеет смысл в отрыве от любой другой задачи и его можно внести когда угодно, это и есть рефакторинг.
Вообще как к этому относятся? Есть ли тут патлатые, которые норм устроились?
Так это еще хуже, во-первых ты заложил туда базу для классического говнокода: когда подобная функция делает разные вещи в зависимости от флага/типа переменной, то это означает, что на самом деле у тебя должно быть две отдельные функции, во-вторых ты даже не написал ни строчки кода, просто зачем-то заранее начал ублажать конпелятор предварительными ласками.
>Почему ты решил что она делает это сама а не делигирует?
Так а нахуя ей что-то делегировать? Если у тебя есть клиенты, которые отправляют только текстовые сообщения, а теперь появились те, которые хотят отправлять картинки, то пусть первые остаются как были, а для вторых делай функцию sendImage.
>Рефакторинг же и направлен на то чтобы абстракцию увеличить.
Абсолютно нет, рефакторинг направлен на изменения кода, но изменения могут быть любыми, в том числе и уменьшение числа абстракций. И так-то любая абстракция сама по себе делает код менее читабельным, потому что вместо прямолинейного кода тебе теперь нужно держать в голове и знать о какой-то еще структуре. Поэтому вводить их нужно только когда это увеличение сложности нивелируется другими факторами, например когда абстракция удачно изолирует связанный блок логики. Сами по себе абстракции ради абстракций код ухудшают, а не улучшают.
У тебя получается что клиенты которые отправляют сообщения зависят от интерфейса sendImage. Это нарушение I из SOLID.
Тут приходит кабан и говорит: "У нас что много клиентов стало, надо отправку сообщений в очередь ставить. Сычев делай" Ты пишешь планировщик очереди: Изображение, Изображение, Текст, Изображение, Текст. Тебе нужно выделить интерфейс
interface MessageSender {
sendMessage(message: string): void;
sendImage(image: ImageContainer): void;
}
и приделать его планировщику чтобы клиенты отправлять сообщения через планировщик а не через Messanger непосредственно. Какому шайтану нужно чтобы планировщик делал два метода, когда они обусловлены только инкапсуляцией данных сообщений. При таком подходе у тебя количество методов будет расти как снежный ком при слоистой архитектуре.
sendMessage
sendImage
sendMessageWithPadding
sendImageWithPadding
sendMessageWithNoResponse
sendImageWithNoResponse
sendMessageWithPadding
sendImageWithPadding
sendMessageWithPaddingAndNoResponse
sendImageWithPaddingAndNoResponse
>У тебя получается что клиенты которые отправляют сообщения зависят от интерфейса sendImage
Что несешь? Тот, кто пользуется функцией sendImage - зависит от ее интерфейса, тот, кто не пользуется - не зависит. Как и с любой другой функцией.
> Это нарушение I из SOLID
Нарушение как раз у тебя, потому что это ты хочешь слепить монструозную функцию, принимающую несколько типов аргументов и делающую разные вещи в зависимости от этих типов(general-purpose interface), вместо того, чтобы иметь отдельные функции для отдельных вещей(client-specific interface). Видимо все в голове уже перепуталось, только акроним запомнил.
>Тут приходит кабан и говорит
Код пишется под существующие реальные требования, а не под выдуманное тобой на пустом месте "а если".
И я ж тебя спросил откуда ты взял монструозную функцию? Messanger делегирует свою работу. Он просто абстракция отправки особщений в архитектуре. Сейчас ты будешь нужность абстракций отрицать и действительно напишешь десяток функций потому что одни клиенты исторически отправляли только сообщения, потом появились клиенты которые отправляют еще и изображения, потом напишешь метод для клиентов нового протокола с падингом, потом метод для асинхронных клиентов которые не ждут ответа.
sendMessage('hui') и sendMessage({url: '...', w: 123, h: 123}) - это две разные функции и два разных интерфейса. Но если клиент использует одну из них, то он автоматически привязывается ко второй, хотя вторая ему нахуй не нужна и знать он о ней не хочет. Именно так нарушение принципа разделения интерфейсов и выглядит, и именно это ты хочешь сделать.
Где это видно? MessageSender это базовый тип. TextClient не зависит от ImageContainer
https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgJIFs4HMIGED24co0yA3gFDLXICuUANgFzIDOYUoWA3FTQBYsQtdACNovGsgDuQkeKi8AvhQpgAngAcUAWQitW2PITDEQpALxpMOAkRJRkAHzYcuvCqEixEu-YZwAZQgQABNSSilWENC9AyMAHgAVZAgAD0gw1mQ4gON7cygAPgAKdH8jFiSAShYAN3xgUOVVBAY4A2Qk9LBcBmAQsHI+agRCdihaBDB8KBLNWlF+hDYY6BZco2Cw6GryZBUR5Cg1ub2mBqbhqSkwfmBWADponahnmM2cBImuUoAiAASEAYDHwf2qRxUhzaHWyGCMfQG4GuNDGIAmUxmcwWS2AKxe4SgGwqQVOezIB1UUhOrxK50uoRRN2Qdwe71e7NiJIgCXhthMZmgpUizJugmQABYABwABgANEdRTIWAA2GXyxWi+jMZAAcgAxLrNdQlBCpFCgA
Я тебе описал практическую проблему у тебя с игнорированием абстракций. Проблема не в том что у клиента много методов которыми он не пользуется, а что методы содержат информацию об содержании сообщения, потом появится суффикс для чего-то другого. Вместо того чтобы создать интерфейс инкапсулирующий отправку сообщений. Я начал на ноде ровно как ты писать, на одних функциях и модулях. Кроме лапши ничего не вышло.
>Вместо того чтобы создать интерфейс инкапсулирующий отправку сообщений
sendMessage({...}) и sendMessage("...") - это разные функции с точки зрения пользователя этого кода, делают они разные вещи и принимают разные аргументы, то есть имеют абсолютно разные интерфейсы. Тот факт, что они засунуты в одну и ты внутри переключаешься между телом одной функции и телом другой по типу входящего аргумента, не дает тебе "инкапсулирующий интерфейс", а только вводящий в заблуждение говнокод.
>это разные функции с точки зрения пользователя этого кода, делают они разные вещи
Нет, не разные. Они обе делают одно и тоже - отправляют сообщение. И сообщения имеют право быть разного типа. Городить для каждого типа с десяток функций не нужно.
Посмотри на интерфейс MessageChannel из спецификации WebAPI. Там одна единственная функция postMessage - оперирует разными типами. В том числе логически - она может как производить структурное копирование сообщения, так и передавать владение объектом.
>Нет, не разные. Они обе делают одно и тоже - отправляют сообщение. И сообщения имеют право быть разного типа.
У этой функции есть два способа использования - один способ для тех, кто хочет отправлять картинки, а второй для тех, кто хочет отправлять текст. И если я как пользователь данного кода захочу отправить текстовое сообщение через твою sendMessage, то я автоматически привязываюсь ко всему интерфейсу данной функции, в том числе и к интерфейсу отправки сообщений картинками, хотя тот интерфейс мне нахуй не всрался, я им не пользуюсь, и не хочу о нем знать. Это та самая архитектурная проблема, которую описывает принцип разделения интерфейсов. И важна она потому, что в дальнейшем ты хуй разберешь, откуда у тебя идут текстовые сообщения, а откуда с картинками, потому что они оба засунуты в одну и ту же функцию, хотя представляют разную логику.
>Городить для каждого типа с десяток функций не нужно.
Не городи, но если ты делаешь две разные вещи, которые нужны разным пользователям, то разница между этими способами использования должна быть четко обозначена границей и единственный способ это сделать - это использовать разные функции/методы. Либо так:
sendMessage("..."); sendImage({...})
Либо так:
sendMessage(Message.text("")); sendMessage(Message.image({...}))
Второй способ очевидно сложнее и вводит больше абстракций в код, плюс требует переработки всего существующего кода, поэтому если нет веской на то причины, то по умолчанию должен использоваться более простой, т.е первый. Но твой вариант ни в каком случае не используется, это на 100% классическая архитектурная ошибка.
Как угодно - в первом примере у тебя скорее всего под капотом есть какая-то общая функция отправки, куда ты передаешь уже сформированное сообщение(а если нет, то добавить пять секунд), в нее и суй свой диспетчер, если тебе по умолчанию нужно все сообщения начать отправлять асинхронно. Во втором примере очевидно как. Но если для некоторых клиентов нужно оставить отправку синхронной, то тут только переписывать весь код на второй вариант и вводить что-то вроде sendMessageAsync(Message), это как раз и был бы пример причины, ради которой усложнение архитектуры того стоит.
>Ты предлагаешь сделать две очереди? Одну для sendMessage а другую для sendImage?
>в первом примере у тебя скорее всего под капотом есть какая-то общая функция отправки, куда ты передаешь уже сформированное сообщение(а если нет, то добавить пять секунд), в нее и суй свой диспетчер, если тебе по умолчанию нужно все сообщения начать отправлять асинхронно
Нахуй ты отвечаешь, если читать не умеешь?
>Да что ты такое несешь-то. Как ты к нему привязываешься, если ты его не используешь?
Берешь блять и привязываешься. Если ты используешь функцию, то ты завязан на весь ее интерфейс, в том числе тот, который не используется. В интерпретируемом языке это не так очевидно, и там это просто code smell, который говорит, что одна функция делает две разные вещи. Но вы же тут тупоскриптеры должны знать, что ISP формулировался в первую очередь для проблемы рекомпиляции: когда модуль A зависит от модуля B, то он должен рекомпилироваться при изменениях в модуле B, даже если эти изменения модуль A не ебут никаким боком. Хотя не удивлюсь, если это для вас новость.
Есть реактивная либа на 500 строк, ее можно распечатать и принести или на память забить если ты совсем отбитый. То что ты сейчас нагородишь приведёт только к неподдерживаемому пиздецу в дальнейшем.
https://github.com/jegan321/nuro/blob/master/dist/nuro.umd.js
Давно у тебя ясновидящие клиенты появились, которые знают, что там функция внутри делает и зачем, а не работают исключительно с ее интерфейсом, который явно говорит "если ты мне дашь вот эту хуйню, то я сделаю одно, а если дашь другую хуйню, то я сделаю что-то другое"?
У тебя есть два типа клиентов, один отправляет сообщения: sendMessage("hui"), а второй картинки: sendImage({...}). Различия между ними только в типе аргумента, но вся логика засунута в одну и ту же функцию и переключается по if-else. То есть оба типа клиентов привязаны к обоим типам формирования сообщения, даже к тому, который им не нужен. Я не знаю, как тебе объяснить еще, ты слишком тупой или троллишь.
Зато ты умный настолько, что не различаешь интерфейсы и реализацию.
Сычев, я у видел что у наших конкурентов отправляется изображение вместе с подписью, а у нас отправляется только одно изображение. А еще сообщения в том числе текстовые, могут отправятся с датой отсроченной доставки (например чтобы поздравить с праздником).
Еще смотри ты засунул очередь внутрь sendMessage в низкоуровневую отправку, хотя sendMessage могла бы быть консумером очереди. Потому что ты не смог в функциональном стиле извлечь интерфейс из sendMessage и передать в клиента диспетчер сообщений с таким же интерфейсом
>На Nest еще меньше вакансий. Да и хайп по нему уже прошел.
>Да и хайп по нему уже прошел.
Конец 2019: 200к установок
Конец 2020: ~600К установок
Конец 2021: 1200к установок
То есть 6ти кратный рост фреймворка за 2 года (с начала ковида) тебя не смущает? По мне так, хайп по нему будет в 2022-2024 и дефицит разработчиков ох какой большой.
А по общей популярности он находится в топе
>Если там нетривиальная логика, что прям нужно в отдельную функцию выносить
Логика там очень простая, я просто люблю разбивать код на отдельные функции, чтобы он легче читался, и не знаю плохо это или нет, потому что с одной стороны у тебя много функций, с другой код очень прост в понимании
>и не знаю плохо это или нет
Это хорошо. Прием называется - декомпозиция - основа динамического программирования (https://en.wikipedia.org/wiki/Dynamic_programming)
>с одной стороны у тебя много функций
Ты просто не экспортируй наружу все те функции, которые не предназначены для применения пользователем. У тебя может быть хоть сотня локальных функций модуля, а на экспорт у тебя идет одна единственная (в идеале).
Те вещи, что находятся внутри одного и того же модуля, должны быть максимально связаны друг с другом логикой работы - это называется прочность (или связность - cohesion) - чем она выше, тем качественнее код (если у тебя из модуля экспортируются функции\классы которые никак между собой не связаны логически и не взаимодействуют, то вероятно это должны быть разные модули).
Модули между собой должны быть связаны как можно меньше - в идеале быть независимыми целиком и образовывать конечную систему различными иными путями слабого связывания ( например, инъекцией зависимостей). Мера зависимости модулей друг от друга называется - зацепленностью (или связанностью - coupling) - чем она меньше, тем качественнее код.
Помимо локальной прочности\зависимости на уровне юнитов, еть еще общесистемная (компонентная) - вещи из разных слое архитектуры так же не должны быть зависимы (зацеплены) друг от друга (именно поэтому нельзя из компонентов интерфейса ходить в апишку, например, а из сервиса логирования напрямую писать в базу данных). В то же время компоненты должны быть как можно прочнее взаимодействовать между собой на уровне тех же слоев (например, кнопка в формочке, имеющая определенное логическое значение, должна испускать наверх события не просто клика, а конкретного действия, которое она производит, а компоненты которые отлавливают события должны слушать не низкоуровневые события вида наведения мыши - а события бизнес-логики - отправление заказа\раскрытие меню\etc).
>стоит ли выносить за пределы компонента функции, которые используются в самом компоненте? Т.е. они не будут создаваться каждый раз при ререндере занов
Как выше анон уже ответил, если чистая, то писать внутри компонента не имеет смысла. Как правило, нужно обращать внимание на семантику методов компонента и оставлять внутри него только те, которые каким-то образом завязаны на его состояние. Остальные выносить, нет смысла каждый раз при рендеринге создавать их заново. Если такая функция не передаётся в дочерние компоненты, то на скорость работы место объявления функции влиять особо не будет. Если передаётся, то над оптимизацией уже нужно работать, т.к. дочерний компонент каждый раз будет принимать такую функцию за новую (это новый объект с новой ссылкой на него).
Я еще отдельно прочту весь текст, спасибо, сейчас трудно осилить.
>>2261739
Да вот пизда начинается в тот момент, когда у тебя функции передаются в компоненты ниже, и тебе сотню раз приходится городить useCallback по цепочке зависимостей, и тут встаёт вопрос, не сожрет ли вся эта мемоизация больше ресурсов, чем ререндер одной кнопки. Потому что useCallback внутри себя делает много работы, и предотвращает только ререндер, но дополнительную работу все равно делает каждый раз
Потому что бэк на ноде - постоянные костыли. На фронте это ещё терпимо, так как ошибки на нём максимум вьюху уронят. Проебать же БД, потому что V8 что-то там проинтерпретировал не так, как ты думаешь он должен был проинтерпретировать, можеть вылететь в жирную копеечку.
Как ты прод проебёшь из-за либы, которая даже в прод зависимости не входит? Да и прямого отношения это к ноде как языку программирования не имеет. Такие трюки можно выполнять в любом опенсурсном пакетном менеджере. Ну а то что у энтерпрайза проды ложатся из-за пакетов, проблемы энтерпрайза, так как в отлаженном CI/CD это максимум бы упало на уровне тестов, не добравшись до прода.
Нахуя ты лезешь в разговор, если не понимаешь, о чем речь? Перечитай, потом вернешься.
>>2261655>>2261661
Шизоид, ты же понимаешь, что твои шизоидные "а если кабан заставит переписывать так, а не сяк" можно плодить без конца и аргументом они не являются? Либо ты обсуждаешь задачу так, как ты ее изначально сформулировал, либо идешь нахуй, потому что это уже твое пятое "а если надо будет сделать так, а не сяк", которые ты пытаешься использовать в качестве аргумента против нормальной имплементации, но обсираешься каждый раз.
Если какая-то функция передаётся очень глубоко в дочерние компоненты, то это повод задуматься над архитектурой и цепочкой вложенностей. Для чего служит эта функция? Почему нужно обязательно передавать так глубоко вниз? Завязана ли она на состоянии компонента? Если завязана, то возможно эту часть состояния стоит хранить где-то извне - в context или сторе Redux (ну или в чем-то подобном)? Вот так я обычно себя спрашиваю. Сам пропсы/функции стараюсь больше 1-2 уровней не прокидывать, и на самом деле обычно хватает 1 уровня, если правильно построить вложенность компонентов.
Работы с DOM - дорогая операция, поэтому операции под капотом use Callback едва ли сравнятся с ним в сложности (время исполнения отличается на порядки).
>или превентивно указываешь точную версию
Лолблять, это должно быть по умолчанию в любом менеджере пакетов, он не может начать по желанию левой пятки обновлять версии зависимостей на обычной установке, как это делает npm, это ебаный нонсенс. Тот факт, что сломанная новая версия либы положила кучу проектов, сигнализирует о таком пиздеце, раздолбайстве и неопытности в языке даже на уровне базовых тулз, что смешно, как кто-то может выступать за серьезный бэк на нодоговне.
Тайпскрипт на бэке - как раз мегакостыль. Вот тебе стандартная бэкопроцедурка: прочитать содержание папки в проекте. Сделай её на тайпскрипте.
>>2261894
>Лолблять, это должно быть по умолчанию в любом менеджере пакетов, он не может начать по желанию левой пятки обновлять версии зависимостей на обычной установке, как это делает npm, это ебаный нонсенс.
Тебе ничто не запрещает npm ci заместо npm install использовать.
>Тот факт, что сломанная новая версия либы положила кучу проектов, сигнализирует о таком пиздеце, раздолбайстве и неопытности в языке даже на уровне базовых тулз, что смешно, как кто-то может выступать за серьезный бэк на нодоговне.
Причём здесь нода?
Дурачок, ты же в курсе, что npm i обновляет package-lock?
>>2261906
>Причём здесь нода?
Ну если ты собрался на ноде писать с нулем зависимостей, то вперед, а иначе тебе придется фетчить 100 васянских пакетов, меняющихся и устаревающих каждый год, потому что инфраструктуры и нормальных фреймворков тут нет.
>Вот тебе стандартная бэкопроцедурка: прочитать содержание папки в проекте. Сделай её на тайпскрипте.
>стандартная процедура
>прочитать содержание папки
Ебать у вас там гавнокод, пиздец просто. Файлы из системы читать вообще нихуя не безопасно, вы поехавшие или ты угараешь?
Если ты как подавляющее большинство жопоскриптеров не трогал и не нюхал другой нормальный язык, то ты вообще не ебешь, как менеджер зависимостей должен работать, и что обновление локфайла при каждой установке - это нихуя не норма. Это раз. Два - npm ci это нихуя не установка зависимостей, это переустановка, то есть все node_modules удаляются и фетчатся/ставятся заново. Можешь представить, сколько это может занять времени в проекте больше туду листа. Пользоваться им, чтобы сраный npm не лез в локфайл - это ебейший костыль от безысходности и говняности.
>Ну если ты собрался на ноде писать с нулем зависимостей, то вперед, а иначе тебе придется фетчить 100 васянских пакетов, меняющихся и устаревающих каждый год, потому что инфраструктуры и нормальных фреймворков тут нет.
Где они есть?
>>2261930
>Файлы из системы читать вообще нихуя не безопасно, вы поехавшие или ты угараешь?
Где же твой супер-правильный сервер софтваре хранит кэш?
>Да. Ну и?
Ты отбитый жопоскриптер, если не видишь проблем с непреднамеренным обновлением всех зависимостей в проекте на каждый пук.
>Питон трогал. Голанг трогал. И шо теперь? Там такие же pip freeze и go.mod
Если бы реально трогал и имел одну извилину, то знал бы, что там есть работающие локфайлы, которые не меняются просто так.
отклеилось
https://listjs.com/
>Нахуя ты лезешь в разговор, если не понимаешь, о чем речь? Перечитай, потом вернешься.
Ты просто осознал свою неправоту.
Использование определенного интерфейса широкоспециализированной функции не делает тебя зависимым от всех ее интерфейсов. А ты тупой долбоёб всего навсего. Вот и всё. Соси.
Ты дебил, влезший посреди разговора, который не понял, о чем речь. Мы говорили об ISP и там "зависимость от интерфейса" прежде всего означает "зависимость на уровне компиляции", а не то, как ты это интерпретировал по выхваченному одному слову "зависимость". Съеби.
Мой мозг, выращеный Питоном, говорит что нужен какой-то парсер, но я знаю, что у жабоскрипта с HTML-ем особые отношения
Как подобное реализовать?
>(фронтовики и фуллстак только растёт).
Потому что никакого чистого бэкенда на ноде просто нет. Если нода, то только фуллстак. Я не представляю себе нодовика, который не знает какой-нибудь Реакт, не сможет покрасить кнопку или сделать SSR. Тем более что это все (ну мб кроме покраски кнопки) чаще всего и входит в круг обязанностей нодовика.
HTML это то, что браузер получает в запросе, его можно посмотреть через ПКМ -> "View Page Source". DOM - распарсенный HTML, то что ты видишь в девтулзах. Ты говорил про динамику, так что скорее всего тебе начинать с основ: https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model
А как делать аддоны это гугли повендорно.
Если так, то мне как вкатуну нужно сначала без graphql научиться ебаться в рукопашную с rest api?
Сам дрочу реакт и нативный js
Или лучше сразу во фронт энд девелоперы?
Что вообще надо для успеха? Сайты запущеные свои? И сколько? Резюме, смазливое ебало и так есть.
Есть условие, от которого зависит, какой из двух компонентов отрендерится.
Нужно передать объект из одного компонента в другой. Как это сделать?
Я делаю useState в родительском компоненте и передаю стейт и функцию пропсами в оба дочерних компонента, на что Реакт пишет:
Warning: Cannot update a component (`Parent`) while rendering a different component (`Child1`). To locate the bad setState() call inside `Child1`, follow the stack trace as described in https://reactjs.org/link/setstate-in-render
Начал читать статью, а там классовые компоненты... сейчас не осилю, но завтра почитаю.
Помогите, плиз.
>либо ценник совсем ахуевший ставят
Охуевший это сколько? Вы берете человека с расчетом на то, что он у вас поработает подольше или вам все равно когда он свалит и вознесется до фронта? Я если честно не представляю себе человека, который хочет остановить развитие своей карьеры на одной верстке. Ему либо нужно платить как фронту или близко, чтоб он туда не совался, либо просто ждать когда он свалит.
Тут в первую очередь идёт соотвествии ценника скиллу и соответсвенно сложности решаемых задач. По поводу роста до полноценного фронта, ну так только рады будем, если в стенах конторы вырастет полноценный спец. И деньгами такого соответсвенно не обделим, благо формат проектного сотрудничества позволяет.
А что ты уже сейчас знаешь? Если нихуя, то есть шанс соснуть бибу. Не потому что ты какой-то не такой и какой-то нехороший, а просто потому что не успеешь.
Я смотрел интенсив гло академии с лысым наставником. Там его какой-то пацан спросил можно ли успеть изучить вордпресс до лето. А тогда март на дворе стоял. И Лысый сказал, что ставит очко, что пацан не успеет с марта до лета.
И действительно, тот же вордпресс легкий в изучении, каждая тема по отдельности несложная, но учить надо много и выходит, что с марта до лета можно ставить очко, что нельзя успеть изучить.
Заебало смотреть на 10 тысяч хеловордов и туду листов в разных интерпритациях
С жс у меня знания максимум почитать, но очень уж злоебучий сайт для скрапинга попался.
https://developer.mozilla.org/en-US/docs/Learn/Front-end_web_developer
[...document.body.textContent.matchAll(/Time to complete: [0-9|\.|–]+ hour/g)].reduce((prev,curr)=>{return prev+parseFloat(curr[0].match(/[0-9|\.]+–/)[0].slice(0,-1))},0)
833 часа минимум, братан.
css, препроцессоры, flexbox, grid ну и набить руку на респонсивах, в т.ч. базовое понимание должно быть какой элемент куда поставить на мобилке, если нет под неё дизайна например.
>>2262472
Тупо сейм. Летом взяли одного такого, джуном фронтендером, чтобы занимался версткой, а потом бы плавно начал писать js. Он закончил какие-то вкатунские курсы + полгода отработал в какой-то госпараше. Забавно, что он уже на собесе называл себя мидлом и говорил что хочет сразу писать на ангуляре. При этом он даже с гитом работать не умел. Дале ему верстать простую страницу для админки, там работы ну на два дня максимум, он провозился больше недели и я ахуел, сколько он там говна нагенерировал. Банальную клиент сайд валидацию полей, которая есть в html он сделал через js, дохуя всяких либ натащил, попытался в архитектуру и засрал сторонние компоненты. Полный пиздец. При этом был упрямый, говоришь ему что это неправильно, а он "вот у нас на курсах...". У него была маня-фантазия что после испыталки ега сразу мидлом сделают и будут платить 150. В итоге в последний день испыталки его просто уволили, лол.
Речь о том, чтобы не заёбывать дизайнера каждым пикселем экрана, а попробовать решить самому, а потом показать дизайнеру/команде как вышло. Понятно что если сложный интерфейс и большим количеством элементов, это задача дизайнера продумать, как всё должно выглядеть на маленьких экранах. Другая крайность, когда вкатун-верстальщик пилит какую-нить таблицу с формочкой пиксель в пиксель только под разрешение экрана из макета, а на то что всё ломается на экранах чуть меньше отвечает "этого не было в дизайне, создавайте отдельную задачу на респонсив!".
И ещё одна кстати проблема джунов-вкатунов, что они не тестируют свой код, даже на соответствие основным требованиям. Делал такому ревью, усомнился, развернул у себя - нихуя не работает. Спрашиваю его, ты мол локально проверял, у тебя всё работает? А он "нет, а для чего нам тестировщики?". Сам при этом заёбывал всех миллиардами вопросов, 90% которых мог бы решить сам потратив 5-10 минут.
Короче, речь больше про самостоятельность, а не про то чтобы делать чью то работу.
> "этого не было в дизайне, создавайте отдельную задачу на респонсив!".
В чем он не прав? По уму должны быть макеты под основные разрешения. Десткоп, планшет и мобила. Между ними уже можно самостоятельно сделать респонсив. Но вот самому это придумывать - неблагодарное занятие. Потом придет дизайнер, скажет все хуйня и будешь переделывать.
вообще я бы сказал сколько уже вкатываюсь, но об этом лучше помолчать
В ts я декларирую функцию
function foo(bar: MyObject = {}) {}
Потом вызываю её
foo(null)
foo(undefined)
В случае с undefined произойдёт замена на дефолтное значение, а с null нет
ТС это конечно кал, но в данном случае ты дебил, который не знает основ жса. Дефолтные значения выставляются только при undefined аргументе или когда аргумент при вызове функции не выставлен(что с точки зрения жса одно и то же, потому что костыли). null - это полноценное значение, которое ты сам передал и очевидно его на дефолтное менять нельзя, и это так работает в абсолютно любом другом языке.
Есть хэдер таблицы с position: sticky и z-index: 2
Есть выпадающий список с меню с position: absolute и z-index: 11
Ячейка хэдера перекрывает меню, когда оно раскрывается.
Как это пофиксить?
Там тоже зоопарк из разных стейт менеджеров? Пригодятся ли навыки работы с Редаксом? Пилите прохладные.
Ну так это же совсем фигня, если использовать pug для более короткого синтаксиса. Там куча плагинов вскода для этого, а весь функционал передачи аргументов и возможность условий выглядят бесполезно, потому что все равно для того что бы перерисовать станицу, ее надо перезагружать. Или я что то не понимаю?
И дальше условия, если планшет, то как сейчас написано, если телефон, то вместо ширины трех полосок надо учитывать ширину одной.
Я пытался сделать это как if(func1 && func2), но он не пашет. Я не пытаюсь скинуть на кого-то свою работу, но дедлайн до ночи, нужно сдать проект, а я сижу и пытаюсь хоть что-то наковырять
1 - как выглядит оно сейчас
2 - что у меня сейчас (огрызок)
Создал на codesandbox проект, создал там папку с картинками, загрузил картинку в эту папку. Хочу эту картинку закинуть в стили как background-image, а не выходит нихуя. Адрес ссылки прописал правильно, картинки со сторонних url показывает как надо, а из папки проекта - хуй. В чем может быть косяк, или так и задумано?
> мне не хватает знаний языка и синтаксиса
> дедлайн до ночи, нужно сдать проект
А-ТЯ-ТЯ, центр занятости., принимай пополнение!
>1 - как выглядит оно сейчас, 2 - что у меня сейчас (огрызок)
Зачем трогаешь return? Ну сделай какой нибудь else if(isTablet.matches) который меняет значение itemWidth.
>Какую версию учить, если уже знаю React?
Никакую.
Твой вопрос звучит как "Какой язык для бэка мне учить если знаю php?"
>когда в вакансиях пишут Vue, то имеется в виду вторая или третья версия
Имеется в виду vue. В большинстве проектов вторая, редко встречается третья. Редко, т.к. она нихуя не поддерживает, надеемся, пока что. В любом случае отличий не так много чтобы было сложно работать на третьей зная вторую.
Признак неосиляторства.
У меня наоборот. В самом-самом начале некоторые вещи казались тупыми потому что не хватало извилин один раз открыть спеку и прочитать что как и зачем.
А слышать про различия в языках в связке с недовольством жс это и вовсе скудоумие 80-го лвла. Чел, ты тупой, если тебе не нравится жс - ебашь веб-ассембли на фронте или модули на бэке. Буквально любой язык можешь встроить без особого геммороя, вот только нахуя если жс банально удобный?
могу начать
Заодно посоветуйте пездатый курс для уже не джуна с какими-нибудь продвинутыми рякт концепциями
Так в шапке есть, слеподырый
https://github.com/acilsd/wrk-fet#javascript
Нашел вот этот гайд (https://forum.losper.net/topic/90-aktivatory-jetbrains-agent-dlja-ide-ot-jetbrains/#comment-238), он должен сработать, не похерю ли я все такими действиями? просто ссыкотно, если что-то сделать неправильно и я лишусь вебшторма, то это будет пиздец
obj.addEventListener("mousemove",event=>{
console.log(event.target.clientY);
})
почему он выбрасывает ундефайнед?
https://frontendmasters.com/ - лучшие курсы по фронтенду во всем интернете
https://javascript.ninja/
https://ru.hexlet.io/
Можно еще Тимура Шемсединова смотреть, у него все бесплатно выкладывается на ютубе.
Я не Илья Климов
как отфильтровать массив от цифр больше текущего индекса?
например [5,4,7,9,2,4,4,5,6]
берем первый элемент, фильтруем все шо больше 5, остается 4,2,4,4
второй 4 = 2
третий 7 = 5,4,2,4,4,5,6
и т.д.
потом делаем обработчик события на движение,с методами сclientXY и херачим значения в позицию элемета?
Соррян. Уровень в разработке - нулевой. Только по мелочи верстал для себя всякие формочки и странички. JS на самом базовом уровне, чтобы кнопочку покрасить или элемент удалить. В практикуме думал над этим курсом https://practicum.yandex.ru/web/
> https://frontendmasters.com/ - лучшие курсы по фронтенду во всем интернете
Классные, но это все ещё "чувак объясняет код"
Мне бы хотелось курсов с упором на практику.
От себя могу порекомендовать epicreact от Kent C Dodds
он в несколько меньшей степени страдает от этого
Ничего "отдельно" создавать не нужно, у тебя уже должен быть модуль создан с функциями, отвечающими за работу с хранилищем. Если туториал на трубе не совсем дебилом был сделан, то там уже всё ассинхронно написано, а значит тебе только понадобится условно вызывать или нодовские методы для манипуляции файловой системой или запросики в облако отправлять. Скорее всего придётся писать дополнительный модуль для работы с АПИ облака, функции которого и будут дёргаться модулем хранилища.
Тут два пути, https://developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API или если нужно таскать элемент внутри другого, то простой аттач евента mousemove после mousedown и удаление после mouseup.
почему не работает?
Хорошо это или плохо вообще?
Там команда менеджеров и SMM-щиков, а для разработки и поддержки сайта один фронтендер. Кто собеседовать будет? Как будут уровень оценивать?
1. Почему фрэймворки уровня vue или react идут с набором npm пакетов с уязвимостями из коробки, которые не фиксятся через npm audit fix?
2. Если даже что-то и фиксится, то, обычно, рушится весь проект
3. Если править ручками, то как понять какой тип уязвимости и в каком месте примерно (строка файла?). Если npm умный дофига и их находит, почему он об этом молчит?
4. Если править пакеты и их уязвимости ручками, то как быть с обновлениями пакетов? Ведь новый код обновленного пакета затрет старые исправления
5. Почему все проекты, которые я "щупал", сделанные на реакте и прочим вью, тянут с собой и jquery какой нибудь?
6. Не кажется ли Вам, что вся эта структура с кучей вложенностью компонентов, свойствами и "опусканием их вниз по компонентам" или "поднятию на верх" сильно усложняет жизнь программисту и замедляет разработку? Ну вот на jquery берешь селектор и пишешь строчку кода, например, отобразить там что-то. В реактовью надо делать компонент и передавать туда свойства, чтобы отобразить там что-то. Сильно больше писанины же.
нужно нести код. а вообще мб ты пытаешься изменить стейт родительского компонента из дочернего компонента? для таких манипуляций нужно писать функцию в род. компоненте, изменять в ней стейт и передавать её через пропсы в дочерний, в дочернем просто вызывать её с нужными аргументами
https://stackoverflow.com/questions/35537229/how-can-i-update-the-parents-state-in-react
если я в точку попал, то я шерлок
Я забил на ту проблему, поскольку после загрузки на Github Pages эта ошибка не отображалась. Но понимаю, что надо разобраться, поэтому набросал пикрелейтед того, как это выглядит, чтобы текстом долго не объяснять. Сам код лень по кускам скриншотить.
P. S. Расстраивает, что почти все примеры и объяснения делаются на классовых компонентах, я не особо шарю в них.
Есть хук, который получает данные с сервера по апи.
В родительском компоненте вызывается хук и туда передается параметр page из state у родителя. Этот state прокинут пропсом в Pagination, откуда возвращается число.
Проблема в том, что при клике на необходимую страницу сначала происходит запрос на сервер и подгрузка нового списка с фильмами, а только потом происходит ререндер компонента Pagination. При этом state у родителя сразу мгновенно обновляется при клике на необходимый номер странички.
Кратко: тыкаю на 3 страницу в Pagination, горит индикатор 1 страницы на Pagination, крутится лоадер, список загружается и с 1 страницы индикатор сразу же перескакивает на 3 страницу.
Как я хотел бы: после клика сначала происходит рендер Pagination и индикатор сразу перескакивает на выбранную страницу, а потом происходит подгрузка фильмов.
Как такого можно добиться?
Никак, если ты хочешь делать такое, то тебе реакт не подходит, потому что его модель рендеринга подобное не предусматривает и не поддерживает. Другое дело, что ты пытаешься сделать хуйню, тебе нужно хранить состояние "выбрана такая страница" отдельно и передавать эту страницу в запрос, а не получать с сервера, как ты делаешь сейчас, тогда все будет меняться сразу же.
>не сидеть за пк 7 месяцев
>до сентября дрочить каждый день js
Выходит, что ты собираешься сидеть за пк 7 месяцев. По крайней мере в глазах родителей так и будет. Что ты делаешь что-то за пк, хуй знает что и эффекта нет. А для родителей так оно и выглядит, что если прямо сейчас нет триллиардов дохода, значит ты занят хуйней и играешь в пеку и переписываешься с тёлочками.
Неправильно сформулировал, да. Я имею в виду, что могу сказать, что занимаюсь программированием хотя я и так им занимался - расскажу все, что думаю и чего хочу добиться, мало ли, доверятся. Вопрос скорее в том, возможно ли получить существенный прогресс за <=7 месяцев. посколько дохуя на дваче вкатунов с хорошей зарплатой, которые вкатились 4 месяца назад, по их же словам
ЖС не "самый востребованный для фронтенда", а единственный. ПХП нихуя не самый востребованный, на бэке зоопарк языков и у каждого своя ниша и сфера применения, можешь просто гуглить топ популярных языков для веба и выбирать какой первым понравится, разницы особой нет, работу найдешь на чем угодно.
Когда-то тут была совсем иная атмосфера.
>А как это в фреймворк вкатиться быстрее, чем в язык, на котором этот фреймворк работает?
>Зачем в мертвом языке ждуны? Там диды нужны поддерживать могилки в порядке.
В JS 1000 Джунов на одну вакансию
В Ruby обратная конкуренцтя, 10 контор готовы принять джуна, лишь бы знал синтаксис
>Все треды это сплошное как войти в айти, наполненные чуть более, чем полностью долбоёбами.
Это НЕ из-за МВП или людей. Просто JS считается как параша для вкатунов, такая судьба оверхайпа. Мне в этом треде тоже неприятно, сижу и охуеваю от ЕБАНУТЕЙШИХ вопросов, просто пиздец. Челик вчера переменную в строку не мог передать, кому нужны такие программисты в будущем? Постоянно в треде создают вопросы уровня "как двигать кнопку влево". У людей нет навыков гугла, все хотят сразу тут и сразу здесь
Я и не говорил, что это ИЗ-ЗА мвп треда. Я сказал, что жс-тред стал его филиалом.
ВСЁ, что тут обсуждается, всегда обсуждалось именно в мвп. Он для этого и был создан. Раньше всех вкатунов и обсуждения собесов, зарплат и прочих "подводных" ссаными тряпками гнали именно в мвп. Теперь это не так лишь потому, что контингент треда сильно скатился за эти последние 5-7 лет.
Смотря где работу ищешь. В мухосрани найти контору на 200 зеленых в месяц в целом реально. Но если чо одного js будет не достаточно. Кури css за одно как адаптив пилить и всякие бест практики. В целом научится можно месяцев за три потом залелеть на вакансию сразу если повезет или стажером и через месяц на вакансию.Попробуй на сайтах с работкой поискать стажировки/курсы со стажирковкой когда какую то базу получишь. Но сразу говорю задачи будут той еще хуетой. Во фриланс даже лезть не думай
>Челик вчера переменную в строку не мог передать, кому нужны такие программисты в будущем? Постоянно в треде создают вопросы уровня "как двигать кнопку влево". У людей нет навыков гугла, все хотят сразу тут и сразу здесь
А какие ещё вопросы задавать?
Я что во время вкатунства не видел смысла задавать вопросы в треде, что тем более после вкатунства. 95% гуглится, а если не гуглится, то проблема в твоём говнокоде или в тебе.
Так что вижу две цели треда - хуесосить друг друга, флеймить, спорить почему твой фреймворк говно а мой лучше. Другими словами кидать говном в друг друга.
Ну и другая цель, это на вопросы вкатунов унижать их. Чтобы у них выработалась привычка сначала загуглить. А потом спрашивать , а спрашивать уже и не нужно будет.
Ярн уважает локфайл, а не переписывает его при каждой установке, как это делает обосранный npm, одной этой причины достаточно чтобы npm отправился на помойку. Ну и выполнение кастомных скриптов у него лучше, npm-run это тоже костыльное говно, которое даже параметры в скрипт передавать не умеет по умолчанию, надо подпирать костылем.
Как происходит принятие на удаленную работу? Как детектить персон, желающих наебать меня на личные данные?
Скажите, плес, если у сайта обмен запросами и ответами проходит через GraphQL, то я смогу их увидеть в браузере в инструментах разработчика во вкладке Network/Fetch/XHR или надо отдельно скачивать расширения для браузера GraphQL, чтоб увидеть запросы и ответы?
Есть идеи, как сделать это покрасивее? Мой вариант выглядит всрато как-то.. Плюс дублирование кода ещё (список строк в типе юниона и внутри функции этой).
Круто + классно и я так делал с функциями.
Но тут фишка в том, что у меня это за получение данных с API отвечает кастомный хук.
А хуки внутри других хуков не работают.
На скриншоте ход этого хука. Внутри хука действительно есть функция, которая собственно и делает запрос.
Может мне тогда лучше использовать только эту функцию? Но как тогда возвращать кортеж [data, loading, error]?
Вообще не хотелось бы отказываться от идеи использования хука. Может у кого есть какие идеи? Было бы интересно послушать.
> Ты забыл дженерик прилепить к своему хуку.
Это что-то с TS связанное? Я еще учу его, поэтому не разобрался.
> И getData() на ассинхронную функцию переписать.
А сейчас она разве не асинхронная? Я же then использую.
> Ну а за то, что переменную называешь как один из глобальных объектов без ведомой на то причины, вообще пиздить надо сапогами.
Справедливо, совсем не подумал.
>>2265062
Хорошо: хуки должны быть на верхнем уровне компонента. Надеюсь теперь правильно.
А почему тогда их объявляют через const? Я просто смотрю упражнения на freecodecamp, да и просто куски кода если что-то гуглю, везде const. Здесь
https://www.w3schools.com/js/js_array_const.asp
даже написали, мол
>It has become a common practice to declare arrays using const
const - это бессмысленная религия, воспринимай ее просто хуевый как стайл гайд, который в проекте соблюдают просто для консистентности. Чему-то полезному он не служит и служить не может, отличия от let номинальные и в основном существуют только в шизоидной голове const-адептов в виде абсурдных рационализаций.
>undefined == null // => true
>undefined === null // => false
>NaN === NaN // => false, NaN == NaN // => false
>isNaN(1 + null) // => false
>isNaN(1 + undefined) // => true
>isNaN('hello world') // => true
>Number.isNaN('hello world') // => false
typeof NaN === 'number' // => true
>if (new Boolean(false)) {alert('evaluarted to true')}
Спасибо, чекнул!
Для тех кому надо ссылка: https://www.udemy.com/course/understanding-typescript/
>15 часов
За выходной явно не освою. Ладно, поищу что-нибудь ещё более поверхностное...