Больше пары строк кода в посте или на скриншоте ведут в ад.
Для программирования на HTML https://codesandbox.io
Для Node.js с консолькой https://repl.it/languages/nodejs
Если рассчитываешь получить дельный ответ, сформулируй правильно вопрос: «что я хочу получить, что я для этого делаю, что я вместо этого получаю». Если/когда самостоятельно найдёшь решение — поделись в треде, мы за тебя переживаем.
Документация - https://developer.mozilla.org
Руководство для вката - https://github.com/acilsd/wrk-fet#javascript
Динамикодриснявая мартышка, ты снова выходишь на связь?
Но ts это динамикодресня с типами. Как мне с интами работать?
В ЧЁМ ОТЛИЧИЕ ТИПОВ ОТ ИНТЕРФЕЙСОВ?
Ангуляр для чедов.
Вью для беток.
Реакт для омежек.
int'ов мне не хватает! Хочу арифметические операции с интами, как в настоящих статических языках.
Если просто напишешь (x) => { doSomething(x + 1) }, другие могут подумать, что ты просто написал лишние фигурные скобки. Поэтому если тебе надо, чтобы функция ничего не возвращала, стоит писать так: (x) => void doSomething(x + 1)
number тебя чем не устроил?
>>3294196
Ежедневная мантра обезумевших ангулярщиков
>>3294032
Правильный ответ - ничем, иди нахуй. Ну и интерфейс можно implements в классах
А еще если ты не собираешься ждать промиса то надо писать void asyncOperation()
>Правильный ответ - ничем
Интерфейс можно расширить с extends от интерфейса или пересечания интерфейсов, а тип нельзя extends.
Интерфейс можно переопределить, а тип нельзя
Интерфейс нельзя как юнион определить, а тип можно
мимо
>Интерфейс можно расширить с extends от интерфейса или пересечания интерфейсов, а тип нельзя extends
Тип зато можно юнион что по-сути то же самое
>Интерфейс можно переопределить, а тип нельзя
Единственное реальное различие
>Интерфейс нельзя как юнион определить, а тип можно
Зато можно как экстендс лол
В целом, >>3294506, ирл всем поебать
1) Остается потребность в babel?
2) Насколько долгая компиляция?
3) Есть какая-то автокомпиляция налету чтобы во время кодинга не чувствовать ее?
4) Почему тс так и не подружили с дотнетом?
2) Насколько долгая компиляция?
https://github.com/swc-project/swc Раз в 20 быстрее компилится чем с официальным тайпскриптовым компилятором
3) Есть какая-то автокомпиляция налету чтобы во время кодинга не чувствовать ее?
https://www.typescriptlang.org/tsconfig/#incremental
То есть ты выдумал какую-то проблему "компиляции", которая как-то может "чувствоваться", а болен - я?
>1) Остается потребность в babel?
Остается. preset-env все еще никто не заменил
>2) Насколько долгая компиляция?
Долгая, но не настолько, что бы входить в резонанс из-за тряски. У нас на проекте с ~500к строк тс кода около 4-5 секунд в вотче перекомпиляция двух билдов для фронта и сервера. Вебпак.
>Есть какая-то автокомпиляция налету чтобы во время кодинга не чувствовать ее?
В вебпаке есть эксперимент, который позволяет компилить только то, что нужно в данный момент. Я не тестил, но вроде должно хорошо работать.
>4) Почему тс так и не подружили с дотнетом?
Зачем? И что ты понимаешь под "подружить"?
>>3294681
>swc
Хуета. В один момент столкнешься с тем, что нужен будет какой-нибудь кастомный плагин вроде бандл аналайзера и пойдешь с лицом грустной лягугки затягивать старый добрый вебпак или витю в проект.
1) Вебпук актуален (был когда-то) только для фронетенд макак
2) Бандлер уже почти не нужен, скажи одмину чтобы переходил на http/2/3
> скажи одмину чтобы переходил на http/2/3
У нас уже давно используется CDN в нескольких странах с http3. И я могу тебе сказать, что бандел все равно нужен, даже если использовать es модули, слишком большая разница получается из-за постоянных раундтрипов, даже когда CDN находится рядом с тобой в пределах города
Благодарю
>4) Почему тс так и не подружили с дотнетом?
>Зачем? И что ты понимаешь под "подружить"?
Хотел дергать asp.net, но теперь вижу что тс просто лайтовая надстройка над js, это было бы сложно.
DHH сказал что не нужен. Можно просто уволить фронтендомакак и нанять бекендеров, как в старые добрые писать на шаблонах, а сверху нахлобучить stimulus hotwire htmx alpine.
Очень удобно для меня, осталось сниппеты для jsDoc сделать.
Кто знает когда вообще планируется аннотация типов? Я так понял в ECMAScript 2025 не будет?
Ты не поверишь, но jsdoc работает из коробки и никакой tsconfig и ts в целом нахуй не нужны. Подсказки для библиотек написанных на ts тоже показывает автоматически
Мне нужна проверка еще, житбрейнских IDE был какой-то автоматический чекер, который подсвечивал.
В чём твоя проблема?
https://www.typescriptlang.org/play/?#code/DYUwLgBAhgXBB2BXAtgIxAJwgXggVggHoIBmAKAGMB7eAZytADpgqBzACigEog
Мимо другой анон, не использую jsdoc, зачем он нужен когда есть тайпскрипт?
Затем, что тайпскрипт - это громоздкая хуета, jsdoc решает вопрос "проверки типов" и "подсказок" гораздо проще
Чем он громоздкий? По-моему ничем. И решает вопрос проверки типов и подсказок гораздо проще и автоматически, не нужно лишние костыли подключать.
Лишний костыль - это тайпскрипт, все тоже самое есть без него и "подключать" нужно гораздо меньше.
>preset-env все еще никто не заменил
Пиздос, я правильно понял, что тс-дебилы сначала "компилируют" один раз в жс, а потом еще второй раз Бабелем? Или этот ваш коллега что-то попутал?
Но он не лишний и не костыль, он расширяет функционал, которого не хватает. С jsdoc нужно срать в код каким-то манясинтаксисом вместо стандартного в индустрии тайпскрипта.
jsdoc - стандартный инструмент в индустрии, если ты его не знаешь, то мы перезвоним.
Я его знаю, но его далеко не везде используют, и он в целом бесполезный, если есть тайпскрипт, который есть в 99% проектов.
Ну да, там где старшему покрасчику кнопок насрали в голову тайпскриптом - используют тайпскрипт, все верно.
То есть 99% разработчиков не правы, один ты познал истину?
99% разработчиков от тайпскрипта используют только расширение .ts у файлов, и есть 1% идейных дебилов, которые выводят типы ради выведения типов вместо решения задач
Чтобы написать ровно тебе самые типы на jsdoc надо банально больше строк, а также не реализовать упоротые дженерики с инферами и условными типами. Но 99.999% клиентского кода это банально ничего не нужно.
Другое дело, что в jsdoc давно можно херачить типы прямо в ts стиле, а при желании совсем упоротых типов ничего не мешает их описать в d.ts и заимпортить в jsdoc.
И получить в итоге лучшее от двух миров - краткость, лаконичность и мощь типов от ts и скорость сборки/пересборки для хотрелоада от ванильного js.
Совершенно верно, здесь лишь проблема в тс-дебилах, которые слышать ничего не хотят и считают, что у них отбирают любимую игрушку
Все же ts - уже стал стандартом, от него никуда не деться. Работал в трёх компаниях в мяскоте и везде был или внедрялся тс. И сейчас с третьей компании ts последний год уже полностью обязателен для всех новых проектов.
Но у меня осталась старая админка внутреннего проекта с jsdoc, отвожу на ней душу.
Анончик, ты пока что на стадии отрицания, или уже на стадии злости/гнева? Ведь по факту-то практически везде пишут на тайпскрипте. И чем лучше компания, чем лучше её продукт/проект, чем сильнее там команда, тем выше шанс, что там пишут именно на тайпскрипте.
Всё-таки похоже на злость. Если ты не согласен с тем, что практически везде пишут на тайпскрипте, то как раз ты заливаешься копиумом, ведь ты пытаешься отрицать реальность.
Тяжело наверное быть тобой, когда ты вынужден отрицать неприятную тебе реальность, при том даже этот копиум не спасает тебя от злости.
Тяжело наверное быть тс-дебилом, который не умеет читать, выдумал воображаемых врагов, приписал им воображаемые утверждения и сражается с ними
Я как раз почитал тебя и сделал вывод, что ты буквально отрицаешь реальность и живёшь в манямирке либо просто застрял в 2014 году, где всё делалось на чистом жс. Врагов у меня нету, я не более чем зоонаблюдаю и жду, когда у тебя стадия гнева перейдёт в стадию торга.
О чем и речь - тс-дебил не умеет читать, но "делает выводы" космической глупости
Космическая глупость - это гневно коупить, отрицая реальность, как будто она от этого изменится.
ТС-дебил настойчиво продолжает спорить с вымышленными утверждениями собеседника
Типовая дискуссия с ТС-дебилом:
- Тайпскрипт кал и моча
- АААА НЕЕЕТ ВЫ ВИДИТЕ МАМ СКАЖИ ОНИ ОТРИЦАЮТ РЕАЛЬНОСТЬ МАМ КОУПЯТ
- Дебил, ты сам это придумал
- РРЯЯЯЯ РЕАЛЬНОСТЬ ОТРИЦАЮТ МАМ СКАЖИ ИМ
>>3295024
Ого, это уже кульминация стадии гнева, или будет продолжение? Когда у тебя мания величия, то стоит научиться быть более эмоционально стабильным. Ведь ты один прав, против тебя 99% остальных разработчиков.
- тайпскрипт говно и моча
- РЯЯЯЯЯ У ТИБЯ ГНЕВ МАМ СКАЖИ ЕМУ ТЫ ПРОТИВ РАЗРАБОТЧИКОВ РЯЯЯЯЯ Я СДЕЛАЛ ВЫВОД ГОЛОВОЙ А ЕЩЕ Я В НЕЕ ЕМ
От того, что ты десятый раз припишешь выдуманные тобой утверждения собеседнику, ничего не изменится, дурачок
Капсовый визг интенсифицируется, думаю ты уже приближаешься к торгу.
>>3295031
Но я ничего не выдумывал, ты же буквально считаешь, что ты прав, а 99% других разработчиков нет. Тебе требуется лечение, ты погряз в манямирке слишком глубоко. В 2014 большинство проектов спокойно обходились чистым жс, но сейчас уже почти 2025, любой качественный да и абсолютное большинство вторсортных проектов делаются на тайпскрипте. Один ты особенный у нас. Специальный.
Одиннадцатый раз тс-дебил приписал собеседнику выдуманные им самим утверждения, как и свой визг, выделенный капсом
Во первых, нет. Во вторых - babel используется еще задолго до входа тс в широкие массы.
1) экспортировать их
2) апи пакета, которое должно торчать наружу, реэкспортировать в одном файле, например index.js
export myFunction from "./path/to/my/function"
3) package.json отграничить экспорт (импорт для пользователя), оставив возможность импотрировать только из index.js
"exports": {
".": "./index.js"
},
Нефига непонятно, можно пример на гитхабе или на статью, если не сложно.
Вот этих додиков не слушай >>3295049 >>3295074
Все это тестируется через публичный интерфейс и моки зависимостей. Тестируется конечный результат, а не отдельные составляющие класса или функции.
Допустим, у тебя есть класс с одним публичным методом initialize:
initialize() {
document.addEventListener(“click”, event => this.handle(event));
}
Тебе не нужно делать метод handle публичным, тебе нужно создать мок document.addEventListener и проверить
1. При вызове initialize зарегистрирован обработчик
2. При клике обработчик вызывает/не вызывает preventDefault в таких и таких случаях
И т. д. пока не покроешь все кейсы использования.
документация nodejs https://nodejs.org/api/packages.html#package-entry-points
>>3295085
Поток сознания не относящийся к вопросу
>как тестировать не экспортные функции
>пишет гайд как тестировать экспортные функции и бонусом гайд как ограничивать импорт из пакета
>пуксреньк поток сознания
В голос с одебилевшего вкатуна
Твое ряя юнит тесты не нужы, только конечный результат тестировать, какое отношение к вопросу имеет? Тебе не нужны, а кому-то нужны. Например сложный алгоритм протестировать, так как он может поломаться из-за зависимостей. Откуда тебе видать, что чел там не экспортировал, ванга что-ли?
Я показал пример как экспортировать внутри пакета, не экспортируя вовне. Экспортировать или не экспортировать внутри пакета, это уже вопрос феншуя либо конкретной ситуации в коде.
Где ты хоть что то про ненужность юнит тестов увидел, шизик? Вопрос был про тестирование закрытого для внешнего мира кода в рамках юнит тестов, а не про то как заэкспортить функцию и сделать ее не импортируемой для внешних пакетов.
Ппц насколько эти модули неудобные и vscode еще тупит, постоянно commonjs мне автокомплитит, трудно вычитать конфиг "type": "module", я не понимаю.
За день я натрахался столько, сколько не с одним языком и IDE, спасибо вам, джаваскрипщики.
Глянул доку таури по сайдкару.
Буквально две-три строки конфигураций и нода живет при билде.
Так что пердолинга нет, раст нинужон, таури суприме!
Главное чтобы модные и молодежные хрустеры не забросили, за электроном хоть гиганты стоят, а этим могут обои наскучить и что тогда?
все просто, нужно экспортировать только для тест-окружения, например:
const notExporting = () => "foobar";
export const notExportingButTest = process.env.NODE_ENV === "test" ? notExporting : undefined;
>>3295085
>>3295074
пиздец больные, какие пакеты нах, какие package.json, у чела был простой вопрос
еще и реализацию предлагают тестировать, ахуй
>экспортировать только для тест-окружения
Да охуенно, потому тайпгварды расставлять на каждый пук, потому у модуля будет пересечение с undefined
к вопросу об экспортах это какое отношение имеет?
просто подскажу тебе по доброте душевной, что можно тестировать ts-код тестами на js
>к вопросу об экспортах это какое отношение имеет?
В чем проблема сделать экспорт? Если тебе прям настолько припекает что бы не импортили этот модуль - настрой правило для услинта или насри в коде
if (__IS_AUTOTEST_RUNTIME__) {throw new Error("Пошел нахуй")}
>можно тестировать ts-код тестами на js
использовтаь чистый js в любом виде моветон уже лет 10. Едиснтвенное, где его целесообразно использовать вместо тс - всякие перформанс штуки, где добавление рантайма от тс повлечет за собой проблемы. И тесты к этому не относятся.
>использовтаь чистый js в любом виде моветон уже лет 10
ты сказал?
>добавление рантайма от тс
что ты несешь блять, одебилевший джун-самозванец-тролль, у тс нет рантайма
>__IS_AUTOTEST_RUNTIME__
торчат уши питониста, вообще не палишься, долбоеб.
>В чем проблема сделать экспорт?
проблемы нет, это у тебя появились какие то проблемы с тайпгардами и прочей дуркой, которую ты сам высосал из пальца. вопрос изначальный от чела был в том, как протестировать без экспорта
>ты сказал?
Да, я скозал. Никаких преимуществ писать на жс НЕТ. Эникасты находятся в топе источников багов, наряду с регулярками и прямой работой с памятью.
>у тс нет рантайма
Есть, tslib.
>питониста
Конвенция именования дефайнов старше нас с тобой вместе взятых и появилась еще во времена языка си.
>Гиганты стоят
Гугол тоже много за чем стоял и что с того?
Тот же дарк полумертвый используется онли в флюттере.
Ну а аппы можно еще и на том же C# найти, где деды упражнялись в древних стилях, до сих пор работают.
В то же время аппа на таури, ее сайдкары - чуть ли полностью не связанны с растом и самим таури, буквально разделенные сущности.
Могу прямо сейчас скопировать папку фронта и запилить на ионике или каком-нибудь электроне.
>Есть, tslib.
толсто
>Конвенция именования дефайнов
срыдни с треда, долбоеб. никто так ничего в жс-мире не дефайнит, кроме единичных залетух-питонистов типа тебя
>никто так ничего в жс-мире не дефайнит
Ты скозал?
https://github.com/facebook/react/blob/5636fad840942cfea80301d91e931a50c6370d19/packages/shared/enqueueTask.js#L29
https://github.com/vuejs/vue/blob/9e88707940088cb1f4cd7dd210c9168a50dc347c/src/v3/h.ts#L11
>>использовтаь чистый js в любом виде моветон уже лет 10
>ты сказал?
Индустрия сказала
Мимо
>Гугол тоже много за чем стоял и что с того?
Конкретно тут написаны коды и строятся большо бизнес, например дискорд, да еще и нейтив.
>C#
Растет и процветает. Если открыть гитхаб то даже удивляет сколько готового софта под разные задачи, а не долбежка одних веб либ как в го и джаве.
И я молчу про индустию геймдева, юнити/годот. В геншин или раст играл? Так вот раст написан не на расте, а на шарпе, лол.
У раста слишком много драм и мухожухов последнее время, какой там статус либ тоже неизвестно, но релизному языку уже 10 лет и тенденция не прям вау, а еще 10 лет ждать не очень хочется.
Это местный динамикошиз. Вон в редаксе тоже питонисты видимо отметились, лол.
https://github.com/reduxjs/redux-toolkit/blob/master/packages/toolkit/src/devtoolsExtension.ts#L220
>>3295287
Так смысл моего поста в том, что похуй на раст, вы сайдкарами кайфуйте.
Раст просто билдит аппу. Причем билдит лучше, меньше, защищеннее.
Нода как сайдкар и фронтендд полностью независимы, если не писать на расте, офк, а кайфовать от сайдкара.
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01
https://www.youtube.com/watch?v=zPOHY-cZ1wE&t=82s
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01
https://www.youtube.com/watch?v=zPOHY-cZ1wE&t=82s
Ты до конца то эти видосы досмотрел? Они отказались от TS описаний типов, сам TS никуда не делся и все еще есть в проекте и проверяет .js файлы.
https://github.com/sveltejs/svelte/blob/main/packages/svelte/tsconfig.json#L35
Спасибо, анон. Чекну. Времени сейчас маловато и знание раста тормозит.
>>3295324
Нихуя не понял причём свелт и турбо с шизой DHH.
Ричи Харрис - гений. Который хоть и использует JSDoc, рядом лежат TS дефинишены.
Лучшее из двух миров для удобства разработки, за что он платит временем на написание того и другого, но имеет удобство в отладке.
В свелт можно писать и на JS и на TS, и вся типизация там есть.
мимо
проверяются типы на jsdoc, да, кода на ts там нет
т.е. используется то за что и хвалят ts - статический анализ
никакой компиляции, никаких суперсетов языка, никакой сложной системы программирования типов ради типов - весь этот мусор нахуй нинужон
по большому счету все возможности ts на 99% проектов используются как линтер для статического анализа, генератор контрактов и автокомплит(что даже без всяких TS IDE от jetbrains умеют из коробки десяток лет - привет долбоебам жрущим бесплатный vscode, который тоже выбрала "ИНДУСТРИЯ" стандартом)
>проверяются типы на jsdoc, да
Давно jsdoc научился типы ПРОВЕРЯТЬ, а не декларировать? Хватит срать под себя.
tsc хавает аннотации jsdoc и проверяет js
никакого тайпскрипта в коде свелта нет, кроме дефиниций для паблик апи, если это вообще можно назвать тайпскриптом
ты прикидываешься или на самом деле тупой?
моя мысль в том большинство людей подменяют целью "ПИСАТЬ НА TS", цель того что им нужен статический анализ, линтинг, автокомплит и возможно кодогенерация, всё
ts получил распространение лишь потому что у него лучше тулинг именно для всего этого, чего не давал jsdoc или flow, а не потому что он якобы на голову лучше js или имеет охуенную систему типов((не имеет))
>Май 2023
И что, много кто отказался от тайпскрипт кроме руби-шиза DHH?
> имеет охуенную систему типов((не имеет))
Имеет, его система типов ебёт почти все популярные языки.
Да, был простой вопрос «как тестировать код который не экспортится.
Налетели одебилевшие вкатуны вроде тебя с ответами «заэкспорти». Алсо, проорал с
>export
>notExporting
Уровень читаемости твоего кода даже представлять не надо
>jsdoc
Чел, я хочу безопасный код писать, а не дрочить простыню из комментов и надеяться на линкер.
В тс есть конкретная фича - ты не можешь выполнить код, пока не сделаешь его корректным с точки зрения компилятора. Жсеры считают это багом, а не фичей.
Линтер жс дока не совсем так работает. Что он делает если в тип из жс дока неясен, он просто как any это интерпретирует? В тс я обязан написать и импортировать тип, если можно запретить писать any в проекте.
С жсдоком в конечном итоге будешь дублировать тайпскрипт код в комментах. Очень громоздко выглядит, а по сути от тайпскрипта никуда не денешься, если захочешь такой же строгогости как с компилятором.
Поэто любители жсдоков не пользуются не тайпскриптом, ни пишут аналогичный код в жсдоке. Что логично, иначе в чем свобода жсдоков заключается?
мимо
Ты можешь зафорсить такое же поведение с jsdoc, о чем и речь. Но тс-дебил свято верит, что это послано сверху только тс и никак иначе
>В тс есть конкретная фича - ты не можешь выполнить код, пока не сделаешь его корректным с точки зрения компилятора. Жсеры считают это багом, а не фичей.
Для фронтенд разработки с его лайврелоадами и хот модуль реплейсментом эта фича действительно может снижать темпы и экспириенс разработки. Особенно при работе с ide, где есть авто сохранение файлов.
Поэтому зачастую для пересборки в дев окружении для тса делают банальный омит типов, чтобы не мешался, а все проблемы отслеживают уже от линтера в самой ide.
Тем самым получая и скорость разработки (в дев окружении тс не блочит LR / HMR), и подсказки (ide сама обрабатывает типы), и подсветку ошибок (линтер в отдельном потоке не мешает пересборке и не блочит её), и строгость типизации (билд уже нормально собирается со всеми проверками).
Но, возникает закономерный вывод - ровно тоже самое можно сделать с jsdoc. Тайпскрипт настроить на проверку js файлов, типы в jsdoc или в d.ts. IDE умеют работать с jsdoc, линтер умеет, даже тайпскрипт умеет.
Ну то есть, с точки зрения строгости кода то на то и выходит.
Вся разница только в том, что будет быстрее работа при пересборке (минус конь_пеляция), но ценой большего объема описания типов в комментах.
>>3295404
Суть в том, что без тс вы не устроитесь на хорошую работу, так что жсдок не заменяет тс
Почему ты компиляцию минуснул, а проверку типов линтером нет. Если линтер аналогичен компелятору, то от должен для всего кода AST постоить как и компилятор
Плюс я написал что достигая в строгости тайпскрипта, ты тот же тайпскрипт должен будешь писать в комментах. Плюс это выглядит монструозно
/
@typedef {import('./person').Person} Person
/
class Person {
Поэтому либо голый динамический жс за который топит DHH, либо строгий тайпскрипт. В чем смысл других опций?
Естественно.
Поэтому не очень понятно, зачем копротивляется местный тс-неосилятор, лучше бы пошел тс внедрять, чтобы к следующему собесу был уже опыт работы с тсом на продакшене.
>В чем смысл других опций?
В том, что можно взять лучшее от двух миров, оставив за бортом мешающее.
Строгий линтер и строгая проверка при сборке продакшен билда от тса и мгновенная пересборка для мгновенного хот релоада, простое написание тестов, быстрое прототипирование в девелопменте от ванильного жса.
Пойми одну простую вещь - из бочки мёда оказывается можно убрать почти всю ложку дегтя, так как её не перемешали.
>Поэтому либо голый динамический жс за который топит DHH,
Не задавался вопросом, почему за голую динамикодрисню топит один шиз, а за тс все остальные?
Ну да, ну да. Все легаси ведь давно переписали с js на ts)
Умеешь писать на жс=умеешь писать на тс. По крайней мере на фронтенде. Привыкнуть к нюансам и сахарку можно за неделю, пописывая свой пет или порефакторив чужой. На техсобесах 2-3 вопроса релевантных если и будет, то ок. Все остальное будет про алгоритмы, кишки рантайма и вебапи, браузеров, вёрстку, фреймверки, тесты, процессы, архитектуру, систем дизайн, опыт.
Я лучше возьму на работу сеньора который повидал некоторое дерьмо с жквери, первым ангуляром, бэкбоном, сборщиками типа гранта и вёрстку в ие9, но который никогда не писал на тс, потому что он вольется в проект максимум за месяц. Чем мидла/джуна, который тс считает отдельным навыком и имеет опыт с ним. Даже на проект на котором 100% известно уже используется или планируется тс.
где можно захостить приложение на ноде+нг бесплатно но так чтобы кредитку не требовало? типа как раньше на хероку
>Я лучше возьму на работу сеньора который
Молодец, а другие 99% нанимающих возьмут с опытом разработки в проектах на тайпскрипте, у них ведь поток кандидатов огромный, могут позволить себя выбирать из широкого пула кандидатов. Найдётся такой, который
>повидал некоторое дерьмо с жквери, первым ангуляром, бэкбоном, сборщиками типа гранта и вёрстку в ие9,
При этом ещё и с тс работал последние лет 5. Если сеньор не работал с тс последние лет 5, то он и скорее всего и не сеньор вовсе, да и у него не опыт, а стаж, ведь он работал на второсортных легасных помойках, а не на качественных тир 1 проектах.
> так что жсдок не заменяет тс
Опять тс-дебилы придумывают утверждения и приписывают их собеседникам. Зачем ты выдумал это утверждение?
>это выглядит монструозно
Любитель повыводить многоэтажные типы с интерфейсами ради самих типов рассказывает про монструозность, кек.
Напрасно смеетесь бабуля. В каждой сказке есть доля правды. Есть разные способы сделать это.
Например у тебя 100-200 рублей на дешевую впску не найдется?
1) Покупаешь дешманскую впску
2) На впску ставишь нжинкс
3) Нжинкс настраиваешь как реверс прокси
3) На своей пеке поднимаешь мега пет
4) через ssh делаешь тунель к своему пету
5) Профит
>мидла/джуна, который тс считает отдельным навыком
Да он не просто отдельным навыком, он считает это вообще отдельной вселенной со Строгой Типизацией, а все остальное - это ДинамикоДрисня Сраная. На курсах наверное так рассказывают.
>Есть разные способы сделать это
Это отимальный способ не доверять свой комп всякому говну, а сделать шалаш самому из палок и листьев.
Ору. Ты либо вкатун, либо долбоеб с рабской ментальностью. Тсдебил даже не понимает, что тс это не навык. Это примерно как джуны указывают себе в резюме знание sass или tailwind. Нужно ли время чтобы их освоить? Нужно, никто не спорит. Являются ли эти вещи базовыми и необходимыми? Нет. Хочешь ли ты называть себя sass-разработчиком, ts-разработчиком, jquery-разработчиком или все таки инженером? Если работодателю нужен не инженер, а исключительно ts-макака, винтик под его(а скорее даже не его, а другой тс-макаки на должности тимлида) фантазии об идеальном стеке - тогда и флаг им в руки.
>>3295512
Снова начались маняотрицания. Приведи пример тир 1 проектов и компаний, где пишут без тс.
Здесь не было утверждений, что где-то пишут без тс, тс-дебил снова выдумал утверждения и приписал собеседнику
По делу - мы вам перезвоним, товарищ вкатун с пет-проектом на тайпскрипте.
>>3295526
Я пишу на тайпскрипте 5 лет, на жсе около 10. В 99% тир 1 проектов пишут на тайпскрипте, без него вы в таких проектах работать не сможете.
Вкатунчик, ты палишься по своему отношению к тайпскрипту как к чему-то особенному.
>Вкатунчик
Это проекции?
>ты палишься по своему отношению к тайпскрипту как к чему-то особенному.
Зачем ты выдумываешь какое-то отношение иприписываешь собеседнику? Для меня это просто один из инструментов.
Тебе не нужно знать ts или иметь опыт с ним, чтобы пройти собесы и устроиться в faang. Кажется разговор был именно об этом, а не о том где он используется, ты сейчас уже как раз сам маняврируешь и подменяешь понятия. Компании используют много всякого дерьма(вспомнить тот же бэм в яндексе или closure у гугла) и тулинга, но найм немного сложнее чем матчинг релевантных и актуальных инструментов.
https://www.google.com/about/careers/applications/jobs/results/76189288726700742-senior-software-engineer-front-end-search-content-platform?q=Frontend&skills=Frontend
Ну вот так выглядишь взрослым. Не повторяй больше вкатунскую ржаку про 99% тир 1 проектов.
>Не повторяй больше вкатунскую ржаку про 99% тир 1 проектов.
А как это противоречит тому, что тс просто один из инструментов? Он один из инструментов, но в индустрии он действительно стал настолько сильным стандартом, что его используют практически везде.
>что его используют практически везде.
npm и yarn тоже используют везде
Надо ли мне 5 лет поработать с yarn, если я до этого 5 лет работал с npm. Нужно ли указывать это в резюме? Будут ли задавать по yarn вопросы на собесе и какие? Есть ли аналог литкода чтобы задрочить все команды ярна?
пиздец ты долбоеб конечно, братишка
>Надо ли мне 5 лет поработать с yarn, если я до этого 5 лет работал с npm. Нужно ли указывать это в резюме? Будут ли задавать по yarn вопросы на собесе и какие? Есть ли аналог литкода чтобы задрочить все команды ярна?
Нет, а при чём тут ярн и нпм, к чему эти манявры фальшивыми аналогиями? Речь про тайпскрипт, его нужно указывать в резюме как навык, и нужно чтобы последние несколько лет он использовался в рабочих проектах, иначе ты не нужен.
Ты ведь без чатгпт не сможешь вот такой тип написать.
type SomeType<T, K extends keyof T> = {
[P in keyof T]: P extends K ? (T[P] extends object ? Partial<T[P]> : T[P] | undefined) : T[P]
}
Выучить yarn add вместо npm install это все таки по сложности не то же самое, что понимать, как в тупоскрипте использовать infer или как сделать тип для конструктора
мимо
А сколько велью эта формула добавляет к продукту?
мимо кабаныч
У моего лида спрашивай. Я в любом случае быстро напишу этот тип и пойду дальше.
Красота какая, как минималистично! Не то, что этот монструозный жсдок
Покажи как такой же функционал будет выглядеть на жсдоке.
>Речь про тайпскрипт, его нужно указывать в резюме как навык, и нужно чтобы последние несколько лет он использовался в рабочих проектах, иначе ты не нужен.
Нет, не нужно. Если тебе это нужно чтобы конкурировать - то это лично твой скил ишью. Получаю по потолку рынка сеньоров уже несколько лет без всякого тс и в хуй не дую.
>Ты ведь без чатгпт не сможешь вот такой тип написать.
Выглядит несложно. За неделю можно надрочиться такую хуйню читать и писать, это же просто дженерики и преобразования над ними. Другой вопрос что заниматься этим я бы не хотел, удачи в петле или в дурке оказаться через несколько лет такого погромирования типов ради типов и ложной "безопасности".
Ебать базанул так базанул.
>Получаю по потолку рынка сеньоров уже несколько лет без всякого тс и в хуй не дую.
Практика твоей тир 2 галеры не репрезентативна, в тир 1 компаниях везде тс.
>Выглядит несложно. За неделю можно надрочиться такую хуйню читать и писать, это же просто дженерики и преобразования над ними. Другой вопрос что заниматься этим я бы не хотел, удачи в петле или в дурке оказаться через несколько лет такого погромирования типов ради типов и ложной "безопасности".
А опыт работы в несколько лет ты тоже за неделю получишь?
Значит тебе должно быть ещё проще. Решение уже есть, напиши такое же на жсдоке
Это не так работает, решить задачу можно разными способами, не похожими друг на друга. Вот ты задачу напиши, а не свое решение
Так и скажи, что ты занимаешься программированием типов ради выведения типов, а не решения задач бизнеса
Да собственно также, просто тип будет описан в отдельном .ts файле и импортироваться в жсдоке
мимо
>А опыт работы в несколько лет ты тоже за неделю получишь?
Ну пока ты дрочил свои типы несколько лет, чтобы изящно описывать как жсон по банальным крудам передаётся, я решал бизнесовые задачи, иногда очень нетривиальные. Как думаешь о чем кабанчику или тимлиду будет интереснее послушать на собесе?
>Практика твоей тир 2 галеры не репрезентативна, в тир 1 компаниях везде тс.
Гугл и Яндекс выписаны из тир1 со своими костылями и легаси. Так и запишем) Держи в курсе.
>тестируется
>докьюмент аддЭвентЛистенер(кликк
А как написать тесты для анимаций?
Ради решения задач бизнеса. Вот эту задачу ты решить не в состоянии, похоже.
>Ну пока ты дрочил свои типы несколько лет, чтобы изящно описывать как жсон по банальным крудам передаётся, я решал бизнесовые задачи, иногда очень нетривиальные. Как думаешь о чем кабанчику или тимлиду будет интереснее послушать на собесе?
Школьник с бинарным мышлением, ты? Я делал и то, и другое, они не исключают друг друга.
>Гугл и Яндекс выписаны из тир1 со своими костылями и легаси. Так и запишем) Держи в курсе.
Какие проекты в Гугле и Яндексе не используют тс? И какой процент таких проектов от всего количества? Вопрос риторический. Особенно смешно про Гугл, который буквально создал Ангуляр, где на чистом жс в принципе невозможно писать. Про Яндекс в принципе тоже:
https://yandex.ru/jobs/vacancies?from=cp_header&professions=frontend-developer&text=typescript
Итак, задачу сформулировать тс-дебил не в силах, ясно-понятно.
Ты не способен вывести задачу из решения, ты точно сеньор, или просто носишь лычку сеньора?
>Яндекс
Шиз, нука покажи мне в каком проекте в яше использует ЖС вместо ТС. Сразу можешь на вики скинуть страницу или название - я проверю.
Кого наймёт кабанчик, сеньора, который много лет решал задачи бизнеса в качественных проектах с использованием тайпскрипта, или "сеньора", который много лет решал задачи бизнеса без тайпскрипта, то есть в легасных второсортных проектах?
https://github.com/orgs/yandex/repositories?q=lang%3Ajavascript&type=all
Поможем же Даше найти жаваскрипт в яндексе. И это только публичные oos, а сколько там внутри собственных сервисов/тулов, в тч внутри всяких дочек/внучек типа лавки/практикума/макета никто не скажет.
>>3295713
Наличие тайпскрипта в проекте не делает его первосортным. Верно так же и обратное - отсутствие тайпскрипта не делает проект второсортным. Ты сделал беспруфное утверждение(что тайпскрипт тождественен тир1 бизнесу) и пытаешься на этом построить остальную логику, беспощадная софистика, которой разве что вкатунов наебывать на покупку курсов по тайпскрипту.
>Поможем же Даше найти жаваскрипт в яндексе. И это только публичные oos, а сколько там внутри собственных сервисов/тулов, в тч внутри всяких дочек/внучек типа лавки/практикума/макета никто не скажет.
>https://github.com/orgs/yandex/repositories?q=lang%3Ajavascript&type=all
Хуя дэбил. А тебя не смущает, что в вакансиях для фронтендеров 41 вакансия из 50 содержит typescrtipt? То, что у них на гитхабе, это хуитка нерелевантная. Вот что релевантно:
https://yandex.ru/jobs/vacancies?from=cp_header&professions=frontend-developer&text=typescript
>Наличие тайпскрипта в проекте не делает его первосортным.
Да.
>Верно так же и обратное - отсутствие тайпскрипта не делает проект второсортным.
Почти всегда это не верно, за редчайшими исключениями, где настоящие 10х инженеры-глыбы делают что-то особенное, выходящее за рамки обычной коммерческой разработки. А обычный коммерческий проект без тс (к ним относятся те же яндекс музыка, карты, еда, маркет, такси, аналоги гугла) - второсортный, потому что динамикошизы и жсдок-макаки типа тебя будут вместо типа как тут >>3295559 писать огромную портянку.
>https://github.com/orgs/yandex/repositories?q=lang%3Ajavascript&type=all
Ебанат, ты показываешь не яндекс, а какие-то высратые на гитхаб говносниппеты. Все фронтовые проекты в яндексе уже давно на ТС. Во всех> технорадарах JS в холде.
>никто не скажет
Я тебе скажу. В нашем бизнес юните JS есть только в виде какого-то легаси кода, последний коммит в который был более 5 лет назад. Все CLI, либы, проекты, ui-kit'ы и прочее давно использует TS.
Так раз уж ты яндексом прикрывыешь - назови мне проект, который в написан на ЖС и который активно поддерживается. Я посмотрю исходники. Или ты напиздел и всю жизнь работал в ООО рога и копыта, делая простейшую хуйню на jquery?
@
а все остальное это ООО рога и копыта
>Вот что релевантно:
>в половине вакансий требуется redux
Охуенный техрадар. Прямиком из 2017
>>3295770
Тебя уже попустили с Яндексом, но если ты мазохист и хочешь ещё, то давай посмотрим остальных из КОТВАСЯ.
Касперский, 3 вакансии из 3 с TS
Озон, 6 из 9 вакансий
Тбанк, 3 вакансии из 3
ВК, 6 из 6
Авито, 3 из 3
Сбер, 7 из 7 на developers.sber.ru, 70 из 79 на rabota.sber.ru
Яндекс, обновлю: если указать только фронтенд и фуллстек вакансии, то javascript 26 вакансий, typescript 42, лол
В итоге выделяется только Озон, где пишут на вью, возможно в том числе используют легасный вью 2, так что с тайпскриптом у них хуже, но вообще у них во всех вакансиях тестировщиков указан тайпскрипт.
Да не стоило утруждаться, уже разобрались, что вся мощь тайпскрипта необходима тир1 компаниям, чтобы увлекательно типизировать экшены редакса трехэтажными типами. Современные проблемы требуют современных решений.
>увлекательно типизировать экшены редакса трехэтажными типами
Чел, ты всё-таки реально застрял в прошлом. Уже минимум 4 года существует redux toolkit, в котором не нужно писать большое количество бойлерплейта. Не то чтобы я фанат редакса, но с тулкитом всё намного проще. В своих проектах я другие стейт менеджеры использую, либо не использую вовсе (только tanstack query для асинк стейта).
>на скрине три дива
>первый в красный, второй в синий
Чел... выкидывай эти примеры и тех кто его давал нахуй, такое на работе не пишут.
Ахаха, в ахуе какой же ты инфант ебаный. Ты опять додумываешь про меня хуйню, которую сам же и высосал из пальца. Что я нихуя не юзал, нихуя не видел, нихуя не пробовал, работаю в рога и копыта, ковыряю свой жс ванильный. Думай дальше так. Чем больше таких вот снобов-нпс-болванчиков и компаний, которые технологии для проектов по техрадарам выбирают, а не исходя из инженерных изысканий, реальных требований, ограничений, dx, здравого смысла и культуры, то тем больше интересных вакансий, проектов и опыта для меня.
Самое забавное что шобла даже не осознает что весь этот техстек выбран топовыми компаниями не чтобы улучшить продукт, а чтобы упростить и удешевить найм. В моменте пузырь надувается, зарплаты растут, но достивнув плато в итоге стагнируют, когда рынок перенасыщается специалистами с удовлетворительной квалификацией. В итоге бизнес получает на длинной дистанции дохуя мидлов, готовых работать за еду в лучшем случае(привет постковидный кризис), а в худшем только дохуя мидлов на рынке. Выше наглядно такой вот раб системы с пеной у рта доказывал что мне надо конкурировать с ним за место в тир1-компаниях, учить тс, какие то года нарабатывать на этом говне, создавая ещё больше конкуренции за места. Нахуя, зачем это лично ему? Инфантильность на мой взгляд, чтобы показать свою значимость или оправдать свой выбор стека(смотрите, я ем говно с тс, но это стандарт индустрии!) ххххрр тьфу!
>снобов-нпс-болванчиков
>считает, что один он прав, а тимлиды, техлиды, архитекторы в топовых и околотоповых компаниях дурачки
Дооооо, ты такой не сноб, лол, образованный-революционер в окружении дремучих тс-дебилов
>считает, что тимлиды, техлиды, архитекторы принимают решение о разработке проекта на тайпскрипте НЕ исходя из инженерных изысканий, реальных требований, ограничений, dx, здравого смысла и культуры
Уровень ЧСВ и грандиозность марямирка поражают
>тем больше интересных вакансий, проектов и опыта для меня
Ага, тем временем практически все годные проекты пишутся на тс, и это далеко не первый год так
>type SomeType<T, K extends keyof T> = {
>[P in keyof T]: P extends K ? (T[P] extends object ? Partial<T[P]> : T[P] | undefined) : T[P]
>}
Я не вдупляю нахуя это надо. Типа выввести тип ключей из объекта?
>>3295783
Ребятушки, а что на счет стандартного контекста?
Или редакс тулкит чем-то намного лучше?
У контекста есть проблемы с перфомансом. Во многих случаях он подойдет- например чтобы хранить шаред стейт для большого компонента, разбитого на маленькие, или хранить тему\данные юзера(то что требует инициализации один раз и не часто меняется).
Редакс хоть без тулкита, хоть с тулкитом, хоть с санками, хоть с сагами - ебейший бойлерплейт и многословность. Из плюсов только то, что плюс-минус все с ним работали и понимают концепцию.
Для состояния запросов можно и нужно взять react-query\apollo и не хранить этот стейт от слова никак.
Для всего остального глобального стейта - mobx и zustand на выбор. Или effector если ты адепт хайп-драйвен-девелопмента.
Для запросов и стейта нужно делать отдельные сервисы, которые будут его хранить, никакие квери аполо хуело мобиксы не нужны, максимум rxjs в сервисах
>никакие квери аполо хуело мобиксы не нужны, максимум rxjs в сервисах
конечно не нужны, можно еще xhr дергать и в window хранить, тоже удобно
>нужно делать отдельные сервисы
инстанс клиента аполло и есть отдельный сервис, если тебе так хочется ярлыки паттернов клеять на все сущности, со своими мидлварями, хуками, кешем, обработкой ошибок
удачи тебе gql крутить в своих пайпах на рх, повышая verbosity кода, когда все давно люди придумали за тебя
вот пример запроса на apollo в компоненте, ничего лишнего:
import { gql, useQuery } from '@apollo/client';
const GET_DOGS = gql`
query GetDogs {
dogs {
id
breed
}
}
`;
function Dogs({ onDogSelected }) {
const { loading, error, data } = useQuery(GET_DOGS);
if (loading) return 'Loading...';
if (error) return `Error! ${error.message}`;
return (
<select name='dog' onChange={onDogSelected}>
{data.dogs.map((dog) => (
<option key={dog.id} value={dog.breed}>
{dog.breed}
</option>
))}
</select>
);
}
примерно так же будет и react-query выглядеть, если в проекте обычный rest, а не gql
это именно что слой по работе со стейтом запросов, не нужно(хотя конечно кто же тебе запретит?) эти данные тащить в глобальные сторы, как в далекие времена на каждую рест ручку в редаксе писали редюсер, слайс и экшены, это пиздец
TS и не нужен для скриптов. Он нужен для командной разработки больших приложений.
> так же будет и react-query
Не будет. React-query уже давно умеет суспендить в отличии от твоего кала, который на каждый чих вынуждает писать
if (isLoading)
if (isError)
if (isSuccess)
https://www.apollographql.com/docs/react/data/suspense
apollo тоже умеет
>отдельный сервис
Охуенно, очередной год-обжект по типу редакса. Минусы все те же только в другой обертке. Опять эти магические useQuery которые все за тебя делают, а чуть в сторону - расстрел и костыли на весь проект.
Явное лучше неявного
Глобальный стейт - зло
Вот когда эти два принципа буду соблюдены, тогда приходи.
>Охуенно, очередной год-обжект по типу редакса.
Нихуя себе, любой стейт-менеджер, оказывается, - антипаттерн.
Где ты тут год обжект увидел? Для слоя апи есть apollo/swc/tanstack-query, они выполняют свою задачу удобно и хорошо(и используя все современные оптимизации и концепции реакта типа саспенса). Если хочешь обмазаться глобальными сторами и реализовывать эту логику обработки ошибок, кеширования, ожидания загрузки, валидации и разбора реквеста/респонса, мидлварей, поведения для ssr, провайдера/консумера/биндинга для компонентов внутри них ручками - твой выбор, мне похуй. Тебе лишь показали возможность, эти инструменты появились не на пустом месте.
Не любой, а тот который хранит стейт всех частей приложения
Чем плохо? Всегда должно быть одно централизованное место, из которого происходит управление. Иначе хрен поймешь, что где откуда управляется.
Его нет, у тебя место которое хранит все и отдает всюду. Централизация это когда у тебя есть слои и взаимодействие между ними, центральным должен быть предметный слой с бизнес логикой. В случае глобального стейта границ нет, я могу влиять на ui пукнув в стейт из любого места.
>я могу влиять на ui пукнув в стейт из любого места
И это хорошо. Зачем лепить себе какие-то безумные ограничения?
Вот и пришли к начальному >>3296093
Т. е. ты только что буквально сказал "год обжекты и глобальный стейт это хорошо, вы ничего не понимаете"
А react-query тут причём? Из глобального стейта там только кэш, который ты можешь и не использовать вовсе. Запросил в компоненте данные, отрендерил, анмаунтил и они почистились gc. Это и есть локальный стейт блять, абстракция над фетчом со свистелками и перделками, которые тебе все равно понадобятся в проекте чуть сложнее туду-листа(и придётся писать свои велосипеды). Работать со стейтом запросов можно и в классических сторах типа редакса, мобикса, контекста, но лучше не надо - только про это и речь.
>>3296120
>>3296135
>>3296149
Назови решения для работы с асинхронным стейтом лучше чем apollo/tanstack-query/swr?
>Работать со стейтом запросов можно и в классических сторах типа редакса, мобикса, контекста, но лучше не надо - только про это и речь.
В редакс тулките есть удобный rtk query, единственный минус - до сих пор нет поддержи suspense
Во-первых, типизация, она как бы есть, но её как бы и нет. То есть, любой может случайно изменить объект за пределами тайпскрипта, и это с удовольствием проглотиться системой.
Во-вторых, сама по себе типизация, особенно в ORM системах и более-менее продвинутых скриптах приводит к тому, что ты часами сидишь в этих ошибках с Omit и пытаешься выяснить, каким был базовый тип, сообщение о том, что у тебя поле является строкой вместо числа не прокатит, потому что оно скрыто за бесконечными сообщениями от всякой мишуры, которая должна работать с типами.
В TS тебе приходится тратить больше времени на мороку с типами передаваемых переменных, и в три раза больше времени на мороку с типами стандартных переменных.
В итоге весь код обрастает тайпгардами и функциями, которые сравнивают значения.
При этом, в скорости это нифига не выигрывает, и просто добавляет ложку мёда в цистёрну дёгдя йаваскрипта.
Решение для типизации было следующим - сервер, написаный на golang, который возвращал объект нужного типа. (40 строк кода). Смысл TS быстро попадает, когда в мире столько других замечательных языков программирования.
И тут приходит бизнес и говорит, чот сео не очень, бандл слишком большой, куча запросов от клиента, для части сервисов безы требуют прокси поднимать, так как токены не следует светить, ещё миллион причин,,, а подними ка ты Вася ssr для проекта, чтобы все это решить внутри контура, а наружу только то отдавать, что требуется.
И тут ты понимаешь, что ничего удобнее глобального стейта - еще не придумали. В одном месте собрал все данные и настройки ui - и отдал с разметкой.
>То есть, любой может случайно изменить объект за пределами тайпскрипта, и это с удовольствием проглотиться системой
Я тебе больше скажу, можно отредактировать память процесса и вообще не важно на каком языке была написана программа - также с удовольствием программа на любом языке все сожрёт и будет работать пока не упадет из-за мусора в указателях или том же делении на ноль.
У rtk query примерно похожий апи по получению данных в компоненте. Только для него нужен редакс и бойлерплейт на КАЖДЫЙ запрос, это пиздец. В этом и минус, это просто лишний шаг, когда тебе нужно просто получить данные и отрендерить/передать дальше.
>Во-первых, типизация, она как бы есть, но её как бы и нет. То есть, любой может случайно изменить объект за пределами тайпскрипта, и это с удовольствием проглотиться системой.
Примеры таких объектов за пределами тайпскрипта?
>Во-вторых, сама по себе типизация, особенно в ORM системах и более-менее продвинутых скриптах приводит к тому, что ты часами сидишь в этих ошибках с Omit и пытаешься выяснить, каким был базовый тип, сообщение о том, что у тебя поле является строкой вместо числа не прокатит, потому что оно скрыто за бесконечными сообщениями от всякой мишуры, которая должна работать с типами.
С какими ORM у тебя были подобные проблемы? У меня не было ни с TypeORM, ни с Prisma, ни с MikroORM, и нет, проекты были не просто круды.
>В TS тебе приходится тратить больше времени на мороку с типами передаваемых переменных, и в три раза больше времени на мороку с типами стандартных переменных.
Звучит как джуновские skill issues, когда исправление ошибки с типизацией кажется чем-то долгим и сложным.
>В итоге весь код обрастает тайпгардами и функциями, которые сравнивают значения.
Не весь.
>При этом, в скорости это нифига не выигрывает, и просто добавляет ложку мёда в цистёрну дёгдя йаваскрипта.
Не особо и замедляет. Тайпскрипт не какой-то сложный язык, чтобы с ним было долго возиться, если ты не разработчик инструментов для других разработчиков, каких-то библиотек. А в долгосроке так вообще ускоряет разработку за счёт ускорения исправления ошибок.
>Решение для типизации было следующим - сервер, написаный на golang, который возвращал объект нужного типа. (40 строк кода). Смысл TS быстро попадает, когда в мире столько других замечательных языков программирования.
На фоне TS golang сложно назвать замечательным. Да на фоне практически чего угодно. Разве что виртуал треды крутые в го, так они и в сишарпе, есть, в котлине есть, и даже в джаве уже есть.
"Вероятность найти работу с React + Node.js даже выше, чем с Angular + ExpressJS. Этот стек является одним из самых популярных и востребованных в веб-разработке на сегодняшний день. Многие компании, включая стартапы и крупные организации, используют его для создания современных, высокопроизводительных веб-приложений."
Это так?
Да, это довольно точное утверждение. Стек React + Node.js действительно очень популярен в веб-разработке и востребован на рынке труда. React часто используется для создания пользовательских интерфейсов, а Node.js — для серверной части приложений. Этот дуэт позволяет разрабатывать эффективные и масштабируемые веб-приложения.
Angular + Express.js также востребованы, но в последние годы популярность React продолжает расти, что делает его более предпочтительным для многих работодателей. Если вы хотите повысить свои шансы на трудоустройство, изучение стека React + Node.js может быть отличным выбором.
>>3296214
Имею ввиду что из всех стеков и видов айти наш пока что мирный Скайнет указал именно на React и NodeJS.
Не Spring, не дотнет - именно React и NodeJS.
Это соответствует правде?
Да, это соответствует реальному положению дел. React + Node.js действительно выделяются среди других стеков благодаря своей популярности и востребованности в современной веб-разработке. Есть несколько причин, почему именно этот стек упоминается особенно часто:
### 1. Популярность JavaScript
- JavaScript остаётся основным языком для веб-разработки, и сочетание React (на клиенте) и Node.js (на сервере) позволяет разрабатывать приложения полностью на одном языке.
- Это делает стек особенно привлекательным для компаний, которые хотят уменьшить сложность разработки и нанимать разработчиков с универсальными навыками.
### 2. Гибкость и производительность
- React благодаря своей гибкости, компонентному подходу и производительности стал стандартом для создания пользовательских интерфейсов. А с поддержкой TypeScript и новыми функциональностями (например, серверными компонентами в React 18), он продолжает развиваться.
- Node.js также предоставляет отличные возможности для создания серверной логики, особенно для приложений с высокими требованиями к масштабируемости и производительности.
### 3. Широкое использование в индустрии
- Многие компании, включая крупные корпорации (Netflix, Uber, PayPal и другие), используют React + Node.js для разработки высоконагруженных и масштабируемых приложений. Это способствует увеличению спроса на специалистов с этим стеком.
- Кроме того, в стартапах этот стек особенно популярен из-за скорости разработки и гибкости.
### 4. Альтернативные стеки
- Spring (Java) и .NET остаются востребованными, но часто применяются в корпоративном и крупномасштабном программировании. Эти стеки отлично подходят для разработки комплексных и устойчивых к высоким нагрузкам систем, часто используемых в банках, финансах и государственном секторе.
- Однако в веб-разработке (особенно в приложениях с богатым пользовательским интерфейсом и высокой интерактивностью) React + Node.js часто выигрывают благодаря своей простоте и отличной поддержке.
Итог: Стек React + Node.js выделяется благодаря своей универсальности, простоте, огромной экосистеме и популярности в современной веб-разработке. Он не замещает более «традиционные» стеки вроде Spring или .NET, но часто является более популярным выбором для динамичных, интерактивных веб-приложений и SPA, что отражает высокий спрос на рынке.
Надуманная проблема. На сервере ты генеришь одну страничку, которая использует и локальный и общий стейт. Регидрируй их отдельно как локальный и глобальный, нахуя все в одну помойку то складывать.
Учи базу, чел https://en.wikipedia.org/wiki/God_object
Тебе уже назвали - rxjs и сервисы с явным предназначением и целью
> бизнес
> сео не очень, бандл слишком большой, куча запросов от клиента, для части сервисов безы требуют прокси поднимать
В голос с маняфантазий вкатунца. Бизнесу на все это похуй, все что он говорит "фича нужна была вчера".
У tanstack-query вполне явное предназначение и цель, при чём все есть из коробки и применяется крайне просто. У rxjs предназначение довольно абстрактное, тебе нужно вокруг него делать свой велосипед, но зачем, если проще и надёжнее взять готовые и проверенные решения?
Это примитивы и паттерны, которыми ты будешь реализовывать свой велосипед. Никаких задач, которые решают эти либы, сам по себе rxjs не решает.
В итоге ты напишешь в лучшем случае хуевую версию react-query с багами, неполным функционалом и большим бандлсайзом, а в худшем хуйню которой будет неудобно пользоваться и дебажить всем, кроме тебя. Про то что этот код ещё и поддерживать надо будет скорее всего уже даже и не тебе я даже и думать не хочу. Дерзай, хуле.
>>3295909
А зачем тебе тут тс, что ты собрался типизировать? И зачем ты ставишь эти загрушки? Ну можно параметр конструктора типизировать, а ещё что?
Вот только ты забыл, что после того, как ты нахуевертил фич, бизнес заказывает аудит, так как с такими крутыми фичами чтот собственно сам бизнес проседает. И этот самый аудит выявляет все эти проблемы и идёт уже тебе ебать мозги не фичами, а проблемами.
В том и суть, что их достаточно. Велосипед ты будешь делать когда твое приложение начнет сыпаться из-за неочевидного, антипаттерного дерьма которое ты затащил.
Нет, не достаточно, даже в ангуляре поверх rxjs сделали HttpClient. Так что для вью и реакта тебе придётся васянить костыли, и скорее в этом случае твоё приложение будет сыпаться, а не из-за tanstack-query и apollo, которые давно сформированы и проверены временем.
Еще раз. Как ты с этим дерьмом поддерживаемую архитектуру строить собрался?
rxjs это инструменты для менеджмента стейта, ты хоть раз слышал такой принцип как Single Responsibility? Почему в rxjs должно быть что то похожее на httpclient ангуляра?
Есть много мест, где всё только на несте, ну либо выкатывайся обратно в жяву/котлин, дотнет тоже норм вариант
Самописную хуйню круто писать, когда ты сам джун+/мидл на первой работе и на небольшом проекте.
Пока сам придумываешь эту дрисню (а не поддерживаешь чужой набор костылей) получишь очень сильный буст к кругозору, пониманию работы фреймворков/библиотек, аналоги которых пытаешься написать.
Представьте код с пикрила, только с точками с запятой. Как же отвратительно это выглядело бы, аж неприятно стало от одной мысли.
Без них жс код работать не будет, да и они улучшают читаемость, т.к. выделяют блоки кода
Странно, но сегодня тс не выдает ошибок, агенты тс прочитали и подкрутили что-то.
Тебе новая строка блоки выделяет, точка с запятой это анахронизм древних (сам олд и самому уже надоело)
Показывай свою "архитектуру" на rxjs. В частности как ты данные фетчишь в компоненты.
"type" = "module" стоит, что ему еще надо?
Нет нормальной доки, на треть сайта фиксированный сайдбар с какими то баннерами о конференциях и прочей хуйне(сматритееее нас юзает %хуйнянейм% сматритееее!!11), такое ощущение что мне пытаются что то продать
Нет замены части плагинов из вебпака
Нет нормального гайда по миграции с вебпака на вайт
Сам конфиг с кучей неявных дефолтов, в доке это никак не описано
Перфоманс не сильно лучше вебпака, даже в бенчмарках
По большому счету это rollup в красивой обертке
Такой геморой по миграции, ради того чтобы начальная сборка на 5 секунд быстрее стартовала? Если уж переходить то на что то, то взять rspack, где разрабы хотя бы думают о совместимости, а не о маркетинге
https://github.com/farm-fe/performance-compare?tab=readme-ov-file#full-benchmark
>>3296756
Дебсы, вит и вебпак - несравнимые вещи. В вите бандлер - ролап, вот его и надо сравнивать с вебкапом.
>Конвенция именования дефайнов старше нас с тобой вместе взятых и появилась еще во времена языка си.
А еще есть конвенция у жсеров не тащить такой мусор в код. Даже в еслинте правило
https://eslint.org/docs/latest/rules/no-underscore-dangle
И то что такое встречается даже в коде вью или реакта не говорит о том, что это общепринятая практика.
Вот тебе отрефакторенный пример из твоего мусорного пакета: https://stackblitz.com/edit/github-ybszlh?file=src%2Findex.tsx
Как и должно компоненту - он просто берет готовые данные и отрисовывает их, ему не нужно знать о том из каких источников они получаются и как обрабатываются. Уровнем ниже презентационный слой, который знает как подготавливать данные от API для интерфейса. В самом низу дата аксесс слой, который знает все об API и не более того.
Вот для сравнение пример с тэнсасак - https://stackblitz.com/github/TanStack/query/tree/main/examples/react/simple?file=src%2Findex.tsx
который рассыпется при первых изменениях требований, либо как минимум будет тянуть с собой кучу ненужных зависимостей и магии, которую никто кроме бывалых тэнсасак не поймет.
В eslint половина правил противоположны другой половине правил.
Еслинт не про то, что вот у нас есть правила и вот именно так надо делать. Он про то, что если в вашем проекте принято такое соглашение по коду - то вот кстати у нас есть для него подходящее правило и не придется на кодревью это проверять.
>я написал 200 строк бойлерплейта чтобы дернуть одну ручку
>у меня слоёная архитектура
Ясно. А фронтенд то тут при чем?
Даже на таком простом примере видна разница в размерах и времени билда. Очевидный отсос тэнсака и любителей затянуть говна в приложение. Это так, чисто макаке хоть как-то доказать, потому что она только сравнение циферок понимает, смысла объяснять что-то про архитектуру и поддерживаемость нет, для макаки это "бойлерплейт".
Ору. Когда ты затащишь такое на реальное приложение то сожрешь эти 4кб уже после добавления 20 запросов своим бойлерплейтом.
Сначала переведи 4кб в количество строк минифицированного кода, чучело. Во-первых.
Во-вторых, это будет код приложения, а не сторонней свистоперделки с багами и вшитыми троянами.
Ничего никуда не приводится, в JS число всегда будет double если не учитывать BigInt
>Вот тебе отрефакторенный пример из твоего мусорного пакета: https://stackblitz.com/edit/github-ybszlh?file=src%2Findex.tsx
Какой пиздец.
>Вот для сравнение пример с тэнсасак - https://stackblitz.com/github/TanStack/query/tree/main/examples/react/simple?file=src%2Findex.tsx
который рассыпется при первых изменениях требований, либо как минимум будет тянуть с собой кучу ненужных зависимостей и магии, которую никто кроме бывалых тэнсасак не поймет.
При каких именно изменениях он рассыпается? Раз уж тебе было не лень запилить эти два примера, запилишь пример рассыпания?
И Какие там ненужные зависимости? И тем более какая там магия? Это очень популярная либа, её знает почти любой, кто разрабатывал на реакте, а кто не знает, тому изучить её не трудно и не долго. Твой пример с rxjs намного более магический и разбираться в нём труднее и дольше. Сейчас бы тащить фп на фронтенд...
>>3296946
Скоро сборки продакшен билда не так уж важна, если это не десятки минут. А бандл сайз ты бы лучше смотрел на реальном большом приложении, там разница будет незначительна.
Если прописан тэг <script src="qweewqqwe...">, то какой тип запроса совершает браузер?
Была мысль, что будет GET запрос, но есть сомнения, что это так.
Ещё часто возникает вопрос, можно ли в src закинуть адрес с другим доменом или нет.
Да, GET. Да, можешь засунуть любой урл. Скрипты с чужих ориджинов могут не загружаться и не выполняться в зависимости от политик сервера, который будет отдавать этот скрипт, и от политик документа/браузера. Можешь почитать про cors и secure context в браузерах.
>При каких именно изменениях он рассыпается?
queryKey: ['repoData'] используется в другом компоненте, queryFn при этом в этом компоненте не задается. Этот компонент рендерится раньше чем Example компонент.
Ой, что это такое? Что-что? Ошибка? Да как же это так, у тебя же топовая архитектура, не может такого быть! Что говоришь? Совсем не связанные компоненты, которые просто зависят от одного источника данных, оказываются зависят еще и друг от друга? Давайте вынесим queyFn и будет тыкать в каждый компонент, а потом бегать и по каждому референсу и проверять что мы ничего не сломали, изменяя код этой квери.
Вопрос: а почему никто не замутит-то именно нативное на js? Зачем всякие дарты лепить никому не нужные?
>Зачем всякие дарты лепить никому не нужные?
Бабки сами себя не распилят.
Текст комментария:
>Я бы добавил, что работу надо начинать искать сразу после изучения JavaScript. Как ни странно есть конторы, где этого хватит. Я именно так нашел первую работу спустя 4 месяца обучения с абсолютного нуля.
РЕАЛЬНО????!!!!!! Можно зная только html, css, js, vue, vite уже пытаться искать работу чистым фронтендером?
Просто мне на двоще сказали, что фронтендером не реально работу найти из-за 2000 тысяч человек на 2 вакансию. И что надо фуллстеком быть, там в 4 раза меньше 500 человек претендуют на 1 вакансию.
Так чё выходит реально можно пытаться чистым фронтендером идти??? А то что надо учить фуллстек - это меня на двоще затроллили и надули? Меня надули аноны? НА-ДУ-ЛИ?
В чём твоя проблема? https://stackblitz.com/edit/github-pyayb6-vunv2j?file=src%2Findex.tsx
Если ComponentB будет где-то в дальней части крупного приложения рендериться первым, то просто-напросто в нём первым запустится фетч, и они вместе со вторым компонентом будут отображать лоадеры пока идёт загрузка. Двух параллельных запросов не будет.
Признайся, ты ангулярщик, который зачем-то лезет в реакт? Или вообще скуфоджавист?
В каком году он вкатывался во фронт? Я нашёл свою первую работу в 12-ом году гораздо легче, чем сейчас, ещё и выбирал из контор. При этом знал JS я на уровне "полгода прогал пет-проект" и собесы были в стиле "покажите пример замыкания".
>И что надо фуллстеком быть, там в 4 раза меньше 500 человек претендуют на 1 вакансию.
Фуллстеков правда в разы меньше, КМК есть даже смысл напиздеть, что ты фулстэк, если хотя бы отдалённо владеешь запрошенными технологиями (php, node, python) освоишь всякую серверную хуйню на месте.
Даунизде, ты бы вместо того чтобы проценты шансиков высчитывать и мнения чужого спрашивать, пошёл бы да вкатился. Как я, взял и вкатился, напиздев с три короба в резюме. И это в 30+
Ок, допустим ты дурачок и не понял примера. Тебе в компоненте А нужны другие настройки кеша, что делать будешь? Создав еще один клиент у тебя запросы будут дублироваться, как этого избежать?
>Тебе в компоненте А нужны другие настройки кеша
Какие? Какие настройки кеша ты не можешь сделать с tanstack query?
Отличные от компонента Б
Примере тенсасакозависимого это
queries: {
staleTime: Infinity,
cacheTime: 1000 60 60,
},
Допустим, компонент А должен обновляться, его не устраивает staleTime: Infinity, при этом API эндпоинт один.
В чём твоя проблема?
https://stackblitz.com/edit/github-pyayb6-hkm4fy?file=src%2Findex.tsx
Перепутал местами компонент А с компонент Б, но суть ясна, у одно из компонентов специфично заданный staleTime, у другого дефолтный для всего клиента.
указывать что конкретно импортируешь или импортировать все как объект?
В учебнике по js говорят, что первый вариант, книги по шаблонам проектирования от O'Reilly говорит, что второй.
retryDelay и подобные настройки принимают только синхронные функции, что будешь делать когда это решение нужно принимать асинхронно или ретраить после завершения другой асинхронной операции?
Отдельно, иначе у тебя оптимизатор билда не будет отбрасывать код который ты никогда не используешь.
У тебя всегда синхронно есть и текущий статус и результат первой query. Тут не нужен никакой асинхронный retryDelay.
В любом случае сложной логики ты всегда можешь сделать ретрай в эффекте или засунуть асинхронную функцию в сам запрос и творить с ней любую дичь, хоть дрочить внутри миллионы запросов на миллионы разных ручек, тот же пайп от rxjs засунуть если тебе с этим работать привычнее. Сколько у тебя таких случаев на проекте от всей логики запросов? 0%? 1%? Остальные 99% случаев покрывает базовый апи tanstack(из них большинство это просто дернул ручку, отобразил загрузку или оптимистик, получил ответ). Именно поэтому он сделан так как сделан, чтобы не ебать себе мозги в типовых ситуациях.
Это примерно как доебаться что в setState() нельзя закинуть асинхронную функцию в виде инициализатора, ахуй просто с твоих маневров.
Мне сдается что ты сам не пробовал работать с подобной либой - хотя бы пару месяцев и ты свой бойлерплейт и "архитектуру" забудешь сразу как страшный сон, а для единичных сложных мест никто не запрещает тебе организовать и обработать поведение так как хочется.
При этом npm ставит под тысячи пакетов, но удаляет только половину или треть.
Ппц, даже в мире пхп было 15 лет назад все более надежно и вообще как минимум работало.
Как заплачено, так и захуячено.
Думаешь мы тут жопу рвём за сотыгу.
>в любом случае можно накостылить
Ну про это речь и шла изначально. Мало того что притащих хуйню в проект, так еще и костылями покрывать нужно
>у тебя таких случаев
Т. е. ретрай запроса только после релогина пользователя - это не типовой случай? Хорошие маневры, но я так и не понял, как это влияет на то что выбор нужно делать в пользу гибких и общих инструментов типа rxjs, а не узконаправленных типа твоего тенсасака, который еще и костылями подпирать надо.
заплатили
@
все равно нахуевертили
@
js проектировался не для верчения деревьями, а для верчения на хуях снежинками хомепейджа на НГ
>retryDelay и подобные настройки принимают только синхронные функции, что будешь делать когда это решение нужно принимать асинхронно
В смысле устанавливать значение retryDelay через асинхронную функцию? Чем тебя пример из доки не устраивает?
The default retryDelay is set to double (starting at 1000ms) with each attempt, but not exceed 30 seconds:
retryDelay: (attemptIndex) => Math.min(1000 2 * attemptIndex, 30000)
>ретраить после завершения другой асинхронной операции?
>ретрай запроса только после релогина пользователя - это не типовой случай?
Другой анон скинул Dependent Queries, почему ты с помощью них не сможешь это сделать?
И ты вообще можешь сделать другим способом, если запосы рядом. Из первого запроса (какой-нибудь getUserData) извлекать refetch:
const { data, isLoading, isError, error, refetch: refetchUserData } = useQuery({ queryKey: ['userData'], queryFn: getUserData, })
И потом его вызывать во втором запросе:
const { mutate } = useMutation({ mutationFn: login, onSuccess: () => refetchUserData() })
Либо если запросы выполняются в разных компонентах, ты можешь в компоненте логина сделать так:
const { mutate } = useMutation({ mutationFn: login, onSuccess: () => queryClient.invalidateQueries(['userData']) })
>общих инструментов типа rxjs
Да, такой общий, что кроме как ангуляра его никгде не видно.
>узконаправленных типа твоего тенсасака
Дружище, ты решил переключиться на толстоту?
>Да, такой общий, что кроме как ангуляра его никгде не видно.
На бекенде его любят некоторые, особенно с нестом. С ангуляром он напрямую не связан. И вообще это часть большой системы https://reactivex.io/
мимо
Знаю, но речь про фронтенд же. Я как раз изначально спросил его, не джава-скуфидон ли он, а то они часто очень любят реактивное погромирование.
Ты чем то мне напомнил этого чела
https://www.youtube.com/watch?v=XAGCULPO_DE
Уверен что ты читал доку жопой или по диагонали
>Ставишь юнит тесты
Что именно ты ставил? Опиши проблему, может поможем
>Т. е. ретрай запроса только после релогина пользователя - это не типовой случай?
а retryDelay тут при чем? ты даже из названия что ли не понимаешь нахуя она нужна? это блять задержка при ошибке, а для повторного запроса у тебя есть refetch, который как раз и возвращает промис, на случай если тебе его руками захочется обработать или куда то передать
залогинился - дернул refetch() или queryClient.fetchQuery, если в сторе надо эти данные обрабатывать
разлогинился - дернул queryCache.clear или очистку стора
всё блять просто
И что ты этим списком сказать хотел? rxjs тоже в любом js фреймворке можно использовать, при этом не нужны разные имплементации со свистоперделками по типу твоего тесакквери, в этом и отличие инструмента общего назначения, от очередной лишней зависимости, которая еще и под разные фреймворки переписывалась. Даже страшно представить уровень поддержки этого дерьма.
У тебя ошибка будет 403, тебе нужно перезапросить авторизационный токен и после этого делать ретрай, поэтому и нужен retryDelay асинхронный, которого в твоем костыле нет.
new QueryClient({
queryCache: new QueryCache({
onError: (error) => {
if (error?.response?.status === 403) refreshAuthToken()
}
})
})
Так, а где ожидание получения токена перед ретраем? Токен в процессе получения, у тебя летят ретраи, как исправлять будешь, тенсасакер?
Зависимость не лишняя. У тебя + 1 зависимость в проекте из-за rxjs, у меня тоже всего лишь +1 из-за tanstack query. При этом я получаю весь нужный функционал из коробки, а ты пишешь васянские портняки, велосипеды и костыли вокруг rxjs. Если на мой проект придёт новый человек, но ему не нужно будет разбираться в костылях, он будет работат с либой, которую и так давно знает.
После условия добавить:
queryClient.invalidateQueries({ active: true })
И где в этом ожидание запроса токена? Как летели ретраи с апдейтами, так и будут лететь. Может цикл ебнуть с дерганием этого дерьма, хорошая идея?
Щас бы токены использовать в 2024 на фронте. И этот человек говорит об архитектуре какой то.
Если у тебя токен может протухнуть в любой момент и с любой ручки может вернуться 403, то придется оборачивать каждый запрос в обертку для такой ситуации. Делать какой то свой аналог interceptor в axios. При чем тут либа то и retryDelay?
https://tanstack.com/query/latest/docs/framework/react/guides/query-functions#handling-and-throwing-errors
Алсо в твоем примере на rxjs ответ тоже никак не разбирается и тоже никаких 403 не обрабатывается. Очередные маневры?
У apollo есть onError и подобие мидлвар,там это делается проще.
>все просто, затащим еще одну зависимость в виде Аксиос или аполло!
Все еще не костыль? Ок. В rxjs это делается добавлением в Пайпер одного оператора, помимо сервиса отвечающего за авторизацию, который при любом подходе нужен, при этом UI компоненты никак не задеваются.
>затащим еще одну зависимость в виде Аксиос или аполло!
Жопой читаешь? Аполло ты затащищь и так, если на проекте будет gql, это аналогичная reaсt-query либа, но заточенная под gql, в нем есть мидлвары и глобальный onError.
Аксиос тоже как пример привел. В любом случае в проекте будет какая то переиспользуемая дрисня над всеми запросами или как мидлвар.
И rxjs все ошибки за тебя не обработает тоже, тебе все равно придется их пропихивать по пайпам и где то обрабатывать в единой манере, а не писать на каждый запрос.
Еще раз: apollo≈reaсt-query≈swr != rxjs , тут нехуй даже сравнивать, они не взаимозаменяемы, абстракции разного уровня для разных целей, чтобы говорить о них в одном контексте. Это как сравнивать подводную лодку и топор(гыгы ебать вы тупые, вот я себе плот вырублю из пальм топором и буду так же плавать как вы на подводной лодке - мы тебя услышали)
Ты либо дурачка из себя строишь, либо не понимаешь нихуя о чем толкуешь.
Если тебе нравится писать свои велосипеды - пожалуйста. Но не надо подменять понятия и говорить что вот это настоящая АРХИТЕКТУРА, когда изначально и до сих пор речь шла лишь про инструменты.
Стандарт, но некст это кал полный. Ремикс чуть лучше, но тоже калом прямо смердит. В итоге самый норм вариант это либо полное отсутствие сср, либо свой велосипед поверх renderToPipeableStream
>то придется оборачивать каждый запрос
class Api {
async fetch(...) {
if(status === 403) {...}
}
}
...
const api = useApi()
useQuery({queryFn: () => api.fetch(....)}
мимо
>А без этого никак?
Слишком большой шанс вымереть, как вымерли честнозавры в позднем триасе. Их подвиг не забыт, но тем не менее.
Не люблю пиздеть, так что сперва попробую залететь вьюшником на пхп галеры в своем городе, а если не получится и меня проигнорят еще на этапе отклика, то походу без волчизма никак. Тебя без пиздежа в резюме на собесы хоть приглашали или ты сразу слету приписал себе пару лишних лет опыта?
Меня в 2023 не звали на 150к собесы с 2 годами опыта, как накрутил до 3х сразу залетел на 300к как раскаленный нож по маслу.
мимо
Не мог несколько месяцев поменять место в том году с 3-мя годами коммерции, пока не натянул петы на глобус как сову до 4-ёх.
Начали хотя бы звать, но отбривали ещё на скрининге по ожиданиям, а я уже даже просил как было. Вот и думой.
мимо
>Тебя без пиздежа в резюме на собесы хоть приглашали или ты сразу слету приписал себе пару лишних лет опыта?
Я не особо пиздел в резюме про опыт, скорее я пиздел про уровень владения тем-то и тем-то. Например, записал себя в фуллстеки, хотя на ноде делал всего лишь скрин-скрепер для одного агрегатора авиабилетов.
Вот нахуя велосипед писать когда тебе некст и ремикс готовое решение дают? Тебе платят за фичи или за написание велосипедов?
> Например, записал себя в фуллстеки, хотя на ноде делал всего лишь скрин-скрепер для одного агрегатора авиабилетов.
И что будешь делать если тебя кинут на проект где микросервисы с чистойархитектурой™ на несте с кэфкой и хитровыебанными sql запросами?
Разберусь на месте. Раньше так и делали, это в последнее время кабаны привыкли набирать тех, кто способен в первую минуту приступить к работе с низкого старта.
Имаджинируй в СССР сантехника, которому бы сказали "ваши 20 лет опыта это всё хорошо, но вот конкретно трубы такой марки вы не прокладывали, так что мы вам перезвоним по дисковому телефону".
Пока ты в этом калопроводе будешь разбираться пройдет дохуища времени, звучит как повод выкинуть на мороз
1) определить функцию f, вну ри которой будут всякие this, а потом делать new f()
2) описать класс.
Вопрос: как лучше поступить? Что будет более хорошим решением при создании объекта?
>Что будет более хорошим решением при создании объекта?
Функция, которая return {}
Слишком широкое понятие "объект".
Если тебе нужен словарь ключ-значение, это одно. Если экземпляр класса с методами - другое.
Если ты имеешь ввиду, стоит ли в 2к24 писать функции-фабрики, вызываемые через new, то не стоит, для этого придуман сахарок "class", который кроме прочего страхует от вызова без new.
С одной стороны я понимаю что структура папок должна брать за основу что то.
С другой стороны вся дока у них - это 3 странички описания общих концепций, которые в принципе не обьясняют смысла, пользы и мотивации предложенного подхода - просто делай так и все.
Все примеры напоминают хуево сделанный MVC, и разветвленный по 4-6 корневым папкам, при этом в каждом примере widgets и shared это основная помойка на половину кодбазы, где каждый кусок кода внезапно не подошёл под семантику фичи или сущности. Термина компонент вообще нет, и оглядки на композицию компонентов.
Не понятно почему у подхода за пару лет возникло уже 4 версии. Просчитались, но где?
Так же не слышал чтобы этот подход упоминался хоть как то на западе. Все мейнтейнеры в основном из СНГ, все доклады и статьи про этот подход тоже в основном из СНГ. Сложилось ощущение что в основном он нравится командам, занимающимся аутсурсом.
Говнина, которая вносит 0 пользы и дохуя вреда. Баззворд, популярный у российских вкатунцов.
Ты правильно мыслишь. Все эти базворды - мусор. Ты ищешь какой-то правильный способ писать код. Но его нет. Просто пиши, то, что тебе нужно. Со временем начнёшь видеть места, в которых ты делаешь несколько раз одно и то же, места в которых можно написать короче, инструменты, которые помогают делать, хорошие библиотеки, которые делают именно то, о чем ты только успел подумать, или к чему ты сам бы пришёл со временем и говняк, с кучей шизоконцепций
И твоя проблема в том, что ты видишь нахуй ненужную хуйню, но сомневаешься, когда надо смело и чётко заявить, что это писали идиоты. Пока себе верить не научишься, тебе так и будут всякий мусор рассказывать.
Из минусов - иногда ты всё же будешь неправ, и тебе пояснят за это, придётся извиниться, но со временем таких ситуаций будет меньше
А что во фронтенде в принципе писали не идиоты? Ангуляр, солид, свелт? Vite, vitest, playwright, zustand какой-нибудь, socket.io неплох, хоть и очень стар, остальное всё какое-то через жопу...
>Для SSR Next.js - стандарт? Не окунаться в него нет смысла?
Next - это не SSR.
>>3298291
>Вот есть два способа создать объект:
Есть еще литерал объекта. Собственно, рекомендуемый для 99% кейсов способ.
>Что будет более хорошим решением при создании объекта?
Более хорошим будет понять, что если ты хочешь работать с объектами, ты взял не тот язык.
>>3298411
>Что скажете насчёт feature sliced design?
Скажу так: открой мейнтейнеров этого говна. Там реальные школьники, у которых мышление "архитектура - это структура папок."
>Next - это не SSR.
Его часто используют для SSR, он ведь предоставляет такой функционал.
>Его часто используют для SSR, он ведь предоставляет такой функционал.
Его используют для ISR
>socket.io неплох, хоть и очень стар
Просто сокет.ио больше не нужен. Он был хорош во времена жиквери, когда в разных браузерах всё работало по-разному. Вот там он действительно творил волшебство, автоматически фалбэкаясь с вебсокетов на флэш сокеты, с них на лонг поллинг, с него на аякс и с аякса на голубиную почту.
Почему не нужен? Он до сих пор очень удобен, на беке удобные фичи из коробки.
>Write pages inMarkdown, useVuecomponents and enjoy the power ofNuxt.
Я понятия не имею, что такое vue и nuxt, но каким-то образом это собрал, запустил, даже смог подключить plotly и написать методом тыка vue-компоненты для их отображения (очень красиво).
Единственная оставшаяся проблема – mathjax, для набора формул как в latex. Всё сука хорошо, но не получается сделать inline формулы, они всегда переносятся на новую строку блядь. Я не понимаю как "дебажить" или разбирать эти триллионы стилей (есть какое-то слово для этого?), чтобы понять откуда вылезает сраный перенос строки.
Может кто-то за деньги возьмётся? Мне просто нужно сделать красивые формулы в этом Docus'е блядь.
я плюсовик, не бейте
Скинь хотя бы код компонента в котором происходит перенос
Так я не понимаю, как это вообще всё работает. Я в шоке, че там фронтендеры современные наворотили.
Ну ты же пишешь:
>не получается сделать inline формулы, они всегда переносятся на новую строку
Зачит ты куда-то поместил эти формулы, где-то они находятся
Там страницы документации просто в markdown пишутся. Формулы должны на $$ $$ подхватываться.
>я плюсовик
>Мне просто нужно сделать красивые
Ловите самозванца!
Я вспомнил, что "деббагер" для фронтендера это инструменты разработчика в браузере. Как-то я ловил get/post методы и функции javascript в хроме, но я не замечал, что он полные списки стилей подгружает, там ещё интерактивно можно галочки у стилей пожамкать! Короче какой-то tailwind.css ставит стиль display: block, который надо вырубить. Пфф, делов то.
>>3299278
Я перфекционист пиздец. У меня до этого получилось другую библиотеку с формулами подгрузить, но там шрифты некрасивые лол.
>не для ssr а для isr
Сорта одного говна. Главное что браузер получает готовую разметку.
Автор пишет, что первый код не очень, потому что каждый объект Car будет переопределять метод toString. Почему?
Я до этого читал учебник по JS и там говорилось, что все методы будут отправлены в прототип и когда происходит обращение к методу объекта, по факту идет обращение к методу прототипа. А тут автор во втором коде явно задает метод прототипу, хотя JS автоматически должен был его назначить.
Я читаю хуевую книгу или чего-то не знаю?
>Я читаю хуевую книгу или чего-то не знаю?
Да. Тут или пример перепутан и в первом случае должен был быть код без классов на чистых прототипах, либо автор долбоеб. Про нюансы языка советую почитать лучше YDKJS https://github.com/azat-io/you-dont-know-js-ru
Хорошо, спасибо за книгу.
Я сейчас пытаюсь сделать обзор анти-паттернов в JS и вот в поиске материала, потому что чувствую, что пишу говнокод и хочу исправиться.
Наоборот питухонщики попутали. "Импорт из" звучит логичнее чем "из импорт".
Ага сначала пишешь что хочешь импортировать, а потом откуда, лол. Конечно, тулинг подогнали под кривизну, и он просто подсвечивает популярные базворды, но прикинь как работало, если сначала писали пакет, а потом уже из пакета была подсветка именно того апи, который есть в текущем пакете, а не пачки базвордов со всех концов.
Чел, никто импорты вручную не пишет, вскод автоимпортит всё что угодно.
>functions are redefined for each new object
Это какой-то bullshit, можешь передать автору please learn джаваскрипт.
>Автор пишет, что первый код не очень, потому что каждый объект Car будет переопределять метод toString
Автор в принципе не очень понимает, что он пишет. Инкапсуляцию предоставляют и литералы объектов, классы для этого не нужны. Наследования в JS нет вообще. А методы не переопределяются для каждого экземпляра, именно для избежания ебки с прототипом функции-конструктора классы и ввели.
>"деббагер" для фронтендера это инструменты разработчика в браузере
Что значат эти кавычки?
Вообще-то у фронтендера есть дебагер для javascript кода, а не только общие девтулзы
Вот случайно наткнулся на свежий доклад об истории успеха внедрения react-query на одном из сервисов Яндекса. Адептам ебки с rxjs и любителям все пихать в глобальный стейт обязательно к просмотру.
Или все зависит от галеры в которой работаю и никаких стандартов нет?
А если нет в доступе дюжины анальников и неограниченного бюджета?
Я без негатива. Просто для меня дебагер это когда вместе с программой идешь по исполняемому коду и следишь за состоянием. Думал, может есть какое-то слово для описания процесса, когда пытаешься декодировать иерархию стилей и выяснить, откуда лишние три пикселя margin у элемента.
>что не знаю когда использовать тип а когда интерфейс
Типами делаешь ток словари ключ-значение с определённым набором полей. Всё, что инстанциируется, делаешь интерфейсами. На каждый класс хуяришь интерфейс как джавапидоры делают и в сигнатурах везде пишешь интерфейсы и нигде не пишешь классы напрямую (кроме new). Гугли SOLID, короче.
>дебагер для javascript кода
А где-то вообще есть дебагер для жопаскрипт-кода, который выглядит как дебагер, типа перлового/питонового, а не как говно для хипстеров с вебвью?
Тогда тем более нужно брать готовое решение в виде react query, потому что велосипеды над rxjs пилить некогда, да и знание rxjs далеко не у всех есть, нахуй кому нужна эта борщехлёбская фп-шиза в 2024, тем более во фронтенде.
Так он первый в гугле выходит когда гуглишь паттерны проектирования
>сначала пишешь что хочешь импортировать
Оба подхода говно. Самый близкий к нормальному подход в C++, где есть инклюды и не надо руками прописывать, какую ты хочешь функцию
А норм подход, когда сборщик сам понимает, что откуда брать и ругается, только когда есть два и более вариантов, никто не сделал
Что за хуйню я прочитал?
Мимо, умею в готовку, но не знаю, как нагреть сковородку
Спасибо!
>>3300087
Это ничего, но если ты будешь отвечать на все вопросы, которые не можешь понять, ничем хорошим это не закончится.
Там нет заголовочных файлов. Но там импортится модуль, а не отдельные функции и структуры
Понимаю, что днищевопрос, но я нубас и только начал все изучать.
Дай ссылку на макет, тоже хочу поупражняться в верстке
мимо другой вкатун
Проходил собес в одну компанию, собеседующий посоветовал после провального собеса.
Суть - есть обс, из него льется rtmp стрим видео. Льется он в node-media-server. Потом на клиенте стрим открывается в ffplay и все работает.
Но появилась задача замутить так, чтобы можно было открыть страницу в браузере и там html5 плеер какойнить локально(в локальной сети дело происходит, доступа в интернет нету) играл этот стрим. Пытался найти плееры какието, там вообще ничего не понял, то скрипт грузится из инета, то вообще не понятно что это и куда вставлять, именно проблема что я пытаюсь чтото запустить не понимая даже то ли это что мне нужно.
Вопрос - чем это правильно делается? Чтобы стрим из node-media-server показать в браузере. Я аникейщик, если что, все это на линуксе, знаю про npm, копнуть в жаваскрипт тоже при необходимости могу, но не глубоко. Еще момент - хотелось бы обойтись без всяких докеров и прочего. Сервер уже в вм крутится, уходить за пределы этой вм очень не хочется.
как ты, вообще, до такого возраста дожил?
https://github.com/illuspas/Node-Media-Server?tab=readme-ov-file#via-flvjs-over-http-flv
>>3300153
Или гриды
Если не ошибаюсь у них большие фичи выкатывают именно в чётных версиях
Автор дурак, который не разобрался, как работает кейворд "class" в JS. Его и ввели, чтобы вручную прототипами не жонглировать, бля.
Там нет дюжины анальников. Средний проект на 200к строк и команда из 3 фронтов, об этом в начале доклада говорится. Ты ведь даже не смотрел, но уже выдумываешь контрвспуки?
О назначении догадайтесь сами.
https://www.youtube.com/watch?v=m1Sa1Sbyejg
>>3300472
https://github.com/tc39/proposal-pipeline-operator
предложению 7 лет, "Stage: 2"
значит, не примут.
похоже, что даже это не примут
https://github.com/tc39/proposal-record-tuple
да и нахер не надо так-то
>Это вроде еще не приняли
И слава богу. Нахуя этот фп-сахар тащить в язык без остальных примитивов фп - не понятно.
Оператор так же неудобно набирать с клавиатуры(возможно дело привычки).
Не удивлюсь если эта хуйня еще и с JSX клнфликтовать начнет при разборе AST. Как в TSX например приходится запятую добавлять после дженериков.
Опытные просто сидят на 5.1 и зоонаблюдают за всем этим.
Типа включить флекс врап, чтоб они были с переносом на новую строку, а элайн через justify content?
Тем, что с интерфейсами можно делать такие приколы
Это типа расширение такое? Без всякого дополнительного кейворда? Херовато выглядит. А если надо переопределить?
Создай с другим именем,
interface Anon2 extends Anon {}
export { Anon2 as Anon }
или импортируй с другим именем
import { Anon as Anon2 } from './anon'
export interface Anon extends Anon2 {}
мимо
Или если под переопределением ты понимаешь не наследование, а создание нового с такм же имнем
то просто определи и экспортируй Anon в новом файле или в том же файле в другм неймспейсе
А как сделать без него, чтоб First name и Last name вдвоем в одной строке были? И Email с Phone.
flex-wrap нужен для того чтобы дети внутри флекс-родителя могли переноситься на вторую строку. А установка нескольких элементов на одной строке это дефолт поведение флекса.
Если просто флекс сделать, то все 5 элементов в одну строку поставятся.
Так сделай эти элементы по 50%, и flex-wrap на родителя, по итогу они будут падать вниз по два элемента на строку. Лучше бы гриды освоил. Там это проще.
Интерфейс менее выразителен, чем тип, тип это супер сет интерфейса.
Надо не флексы и грибы осваивать, а умение комбинировать элементы по контейнерам
А это подходит? 70 000 000 скачиваний в неделю.
https://github.com/jonschlinkert/is-number/blob/master/index.js
Сам видишь, какую. Обеспечивает единообразный перебор пяти разных типов.
Нихуя, круто. Зачем это использовать на проде, где уже есть форматирование в сентри?
не сработает, если в родительском окне заллогировать что-либо из фрейма. Переделывай.
в 2к25 кто-то все еще пользуется фотошопом вместо фигмы?
Да, на момент создания это было удобным и надежным способом для проверки на число, сейчас это легаси которое тянется от других пакетов.
Тогда используй type.
Интерфейсы нужны именно для того, чтобы их вот так расширять. Например, когда хочешь добавить переменные окружения в import.meta.env
Или новый метод в String.prototype
>Например, когда хочешь добавить переменные окружения в import.meta.env
Точно такое же сработает и с типами, интерфейс тут не критичен
>Или новый метод в String.prototype
За такое бьют по рукам еще со времен, когда тайпскрипта не было.
все похуй, кто хочет уже давно их использует через бабель или аналоги
>Точно такое же сработает и с типами, интерфейс тут не критичен
Не сработает, у import.meta.env уже определён интерфейс, и ты можешь его только расширить. А был бы определён тип - ты бы никак не мог его поменять
Речь о всяких "Принять", "Отмена", "Вы уверены, что вы хотите продолжить без сохранения?". В общем любых текстах, что у вас на страницах приложения
У вас локализация есть?
Вообще насколько это ок практика так делать (хранить строковые константы в одном месте)?
>У вас локализация есть?
На 20 языков.
>Вообще насколько это ок практика так делать (хранить строковые константы в одном месте)?
Вообще подобные константы у нас хранятся в отдельном сервисе с гуем для переводчиков и мы их по api получаем. Но если у тебя сервис на один язык и гарантируется, что он не будет интернационализироваться - можешь на похуях прямо в компоненте хардкодить.
>На 20 языков.
rtl поддерживаете?
отдельный набор стилей под это имеете?
А если я малограмотный, и в 10 местах напишу фразу без ошибок а в других 10 местах ту же фразу с ошибкой? Не проще ли будет в одном месте отловить такой расклад?
>rtl поддерживаете?
Да
>отдельный набор стилей под это имеете?
Нет, просто селектор html[dir=rtl] & {...}, и чанк со стилями грузим асинхронном поверх основного. На арабов похуй абсолютно, пусть терпят, один хуй бабла не так много приносят что бы с ними ебаться
>>3301762
>А если я малограмотный, и в 10 местах напишу фразу без ошибок а в других 10 местах ту же фразу с ошибкой?
Курсы грамотности стоят не так дорого. Плагин для IDE, чекающий грамматику - того дешевле. А еще на проекте должны быть QA.
Да как и везде:
Если используешь 1 раз, то хардкодишь, если больше, то выносишь в отдельную константу
Денег нет на курсы, а QA проебались, например, или сами малограмотные?
Не нарушает ли такой хардкод строк принцип не повторения? Нахуя например мне харкодить из раза в раз "Принять" или "Отменить"?
Что у вас юзается для работы с такими константами? Что юзаете чтобы склонять слова по числам? (одно яблоко, 2 яблока, 5 яблок)
родительский <form>, внутри три <div>
в первом <div> имя, фамилия, во втором email, телефон, в третьем сообщение
input, textarea {width: 100%}
div {display: flex; gap: 37px;}
div+div {margin-top: 19px;}
У нас нет сервера с переводами. У нас вообще один язык. Чо делать?
Модули с прототайпами вместо классов, Float32Array, и массивы vec3[3] вместо vec3 {x,y,z}?
Речь о всяких "Принять", "Отмена"
если у вас один язык, вообще не парься, хардкодь в шаблонах
>>3301762
>А если я малограмотный
придёт тестер, даст по башке, один раз исправишь и всё, это нормально, не парься
Я об этом {x:0.1, y:0.2, z:0.3}
Насколько это
vec3add(a,b)
{
return [a[0]+b[0], a[1]+b[1]]
}
производительнее вот этого?
Class vec3
{
add(a,b)
{
return {x:a.x+b.x, y:a.y+b.y}
}
}
Для функций мемоизация вычислений например.
Что-то больше ничего адекватного и потенциально полезного в любом коде не придумывается.
Помоги с парсингом странички.
Есть один сайт, по сути это лента постов. богомерзкий https://pikabu.ru/ , еслишто
Под каждым постом прикручен счетчик реакций пользователей.
При нажатии на кнопку "эмоции" появляется менюшка со значениями счетчиком - пикрелейтед.
Посмотрел код страницы - счетчиков нет. При нажатии кнопки динамически добавляется новый объект.
Посмотрел через браузерный Dev-tool в Network - при нажатии на кнопку есть только запросы к яндексу(статистика, вестимо).
Поискал класс кнопки в сорцах - нашел пару вхождений, но толку не дал.
Помоги, анон. Как это работает? Как это парсить?
> Class vec3
> {
> add(a,b)
> {
> return {x:a.x+b.x, y:a.y+b.y}
> }
> }
тащемта
Class vec {
private x
private y
add(a: vec) {
this.x += a.x
this.y += a.y
}
}
>Как это работает?
по нажатию "Эмоции" в dom добавляется .popup .popup_animate .popup_show с эмоциями
>Как это парсить?
триггерить нажатие на "Эмоции", ждать, пока отработает js, добавляющий попап, парсить попап
зачем парсить пикабу?
что тебе предлагать, для тебя страница в браузере это какая-то магия, тут предложения бессильны, иначе даунов уже давно бы гениями сделали.
>>триггерить нажатие на "Эмоции", ждать, пока отработает js, добавляющий попап, парсить попап
Цель - спарсить счетчики для условных 100 постов. В автоматическом режиме.
Нужно понять механизм получения счетчиков браузером с сайта чтобы потом использовать этот механизм/запрос напрямую из кода парсера.
>>3301882
>Подрочи сетевые запросы
Не, я конечно понюхал вирешарком.
Но тут httpS, ничего не видно же.
>Нужно понять механизм получения счетчиков браузером с сайта чтобы потом использовать этот механизм/запрос напрямую из кода парсера.
Ну вот ты и ответил на свой вопрос, от нас что нужно? Исполнителей среди фрилансеров ищи
>Исполнителей среди фрилансеров ищи
Справедливо.
С одной стороны.
А другой стороны, я же не парсер прошу, а направление куда можно копать чтобы разобраться как оно работает.
Это я с веб технологиями не очень и для меня это долго/сложно, но вы то мастера, вам такие вещи выяснить - 2 минуты посмотреть.
На вебгл работы нет. Вакухи зарабатывают меньше среднего реактера раза в 1.5. Если честно, я охуел от такого расклада.
Я вот посмотрел пропозал с декораторами - почти ничего не понял из той переусложнённой дичи. Короче, если примут, это будет ещё один yield, которым никто не пользуется, но которым валят на собесах.
Я на фулстэк вот перекатываюсь с фронта, в понедельник первый день. Закупился книгами по ноде. У фронтов на мой взгляд и конкуренция выше, и зепки ниже, и эйджизм самый жёсткий. После 35 актуально.
Так а че ты собрался на вебгл делать из серьёзного? С вебгл во-первых без обёрток никто не работает, нужен трижс или бабилон. И нужна видимо игровая контора, которой бы приспичило делать браузерное 3д.
Ты предлагаешь каждый раз указывать первый вектор-слагаемое отдельным вызовом? А зачем?
А если мне нужно несколько разных пар векторов сложить?
это что ж за проект такой был, чтобы разраб за 450 окупался? не важно, фронт, бэк, хуек
то есть разраб работает месяц, и это приносит конторе больше 450к... ну я хз...
Любой финтех или диджитал. В том же сбере в мск сеньки как раз под 450 и имеют. Что тебя удивляет, вкатунчик?
Че за проходки во вкатунцы? Зачем?
>В том же сбере в мск сеньки как раз под 450 и имеют
Это точно не фуллстек, когда они и ноды настраивают и фронт пилят?
> когда они и ноды настраивают и фронт пилят
Что за "ноды"? Node.js? Так любой фронт должен с ним уметь работать базово, хотя бы чтобы сборку настроить и поднять локально.
Просто открыл 3 актуальные вакансии в сбере, где требуется опыта больше 3 лет. Где ты тут видишь какие то требования не релевантные фронтам?
https://developers.sber.ru/kak-v-sbere/vacancies/frontend-developer-dcb
https://developers.sber.ru/kak-v-sbere/vacancies/frontend-developer-sd
https://developers.sber.ru/kak-v-sbere/vacancies/frontend_epm
>хотя бы чтобы сборку настроить
Нет, я имею ввиду что ты будешь бекенд ковырять "ведь язык-то один"...
>Где ты тут видишь какие то требования не релевантные фронтам?
Я там и зарплат не вижу.
Говорят в сбере топ синьора 350к.
>Говорят в сбере топ синьора 350к.
На позиции в мухосрани - да. В МСК позициями по 450к еще год назад было мало кого удивить.
>Нет, я имею ввиду что ты будешь бекенд ковырять "ведь язык-то один"...
Ну так сходи, пособеседуйся и спроси. Там даже можно по этим ссылкам напрямую тимлиду в телегу написать, лол. Так и спроси у него "надо ли мне будет ковырять бекенд на ноде на этой позиции?"
Бэкенд на ноде это не то чтобы в целом популярная история. Да и большинство такого бекенда это BFF где просто json'ы перекладывать с разных ручек в ответ и SSR обеспечивать. Так что даже статистически нарваться на такие требования и обязанности меньше, более того - к окладу это имеет отношение довольно опосредованное.
Сам поймёшь, когда тебе будут прилетать автоматические отказы на 2 из 3 вакансий при полном совпадении твоего резюме и требуемых скилов.
Мне хватило пары минут для того чтобы понять источник каунтеров, пока ты это дерьмо разворачивать будешь, я уже спаршу весь пикабу
>получает 300к что на уровне мексиканки-уборщицы в штатах, если не считать чаевые
>не может программист за месяц столько прибыли приносить, не-мо-жет
В голос с раба
>это что ж за проект такой был, чтобы разраб за 450 окупался?
Фактически любой крупный проект, который не может существовать без поддержки нормальным программистом. Программист окупается не только тем, что вот он реализовал фичу и она принесла полмиллиона за месяц. Программист окупается тем, что без него компания теряла бы из-за всяких поломок и отказов больше полумиллиона в месяц.
Но я в 39 из 4 собесов получил 3 офффера и в итоге пошел в мяскот на 400к.
У меня оклад под 400к + годовые премии в 3-4 оклада. Итого больше 450к.
Из фулстековости во мне максимум это бфф на пару ручек прокси поднять, чтобы на клиенте меньше логики было, да токены доступа к сторонним сервисам не светились.
Ты смотри не пропозал внутренностей, а примеры использования готовых декораторов. В общем, декораторы традиционно используются для выноса общего поведения.
Если не брать в расчет всякие ангуляры, у которых декоратор на декораторе и декоратором погоняет, то самое частное и самое полезное, что можно и удобно делать в виде декораторов - это мемоизация вызовов функций. Для режима разработки - логирование.
И теперь ты такой описываешь как за пару минут все понял иначе ты хуй простой и пиздобол.
Чел, мемоизация это костыли, если это самое частое, то значит у тебя нет опыта работы с архитектурно грамотно построенным приложением. Декораторы это про метапрограммирование, а не костыли, запомни.
Поставил брейкпоинты в код, изучил запросы в дев тулзах.
Чел, метапрограммирование в рубях, где с его возможностями буквально просто написать свой собственный язык под задачу.
Джсовые декораторы - по сравнению с возможностями рубей - не более чем вынос общего кода и к настоящему метапрограммированию не имеют ни какого отношения.
На рельсах столько всего понаписано, что руби будет умирать как Дельфи - вечно.
Но это не суть. Суть в том, что там метапрограммирование, а в декораторах жс им и не пахло никогда. Чел себе про декораторы какую-то хуйню навыдумывал, прочитав где-то умное слово.
Не бывает умных слов, бывают люди для которых они такими кажутся. Например дебилы которые не знают что декораторы это аспект метапрограммирования, а не способ вхуячить неявный костыль.
Еще умное слово изучил, и теперь везде суёшь аспекты?
Декораторы могут применяться при реализации метапрограммирования если в конкретном языке позволяют изменять сам декорируемый код и нагенерировать на его основе другой, но никаким аспектом метапрограммирования декораторы не являются. Метапрограммирование возможно и без декораторов. В жс же это вообще синтаксический сахар над оберткой, которая просто меняет входящие\исходящие данные.
constructor (scenes) {
scenes = { ...scenes }
...
}
штоб не было сайдэфектов, когда ты в scenes удаляешь или меняешь свойство
хотя, конечно, не спасет от ссылок во вложенных объектах
Чтобы жс макака без типизации не начал мутировать поля объекта и не выстрелил себе в ногу. В тайпскрипте этот костыль не нужен, решается добавлением readonly модификатора полю.
Сяп, нашел, ты душка, анон :3
Из релевантного для резюме было пара лет опыта фулстека и 3 года фронта реакт+тс.
Так как за спиной был фулстэк, то и в систем дизайне было понимание, да и в вопросах ci/cd, всякими докерами и куберами в свое время интересовался, поэтому кроме чистого фронта на собесах мог спокойно показывать свой "кругозор" в смежных областях.
Когда и фронт и бэк делаешь. Но в реальности невозможно быть профессионалом в обеих областях - они слишком разные, а время на учебу и получение опыта ограничено.
Поэтому это всегда какая-то точка между двумя крайностями. И обычно ты либо бэкендер, но можешь сделать несложные шаблоны, либо фронтендёр, но если что можешь написать пару прокси-ручек на бфф. Если попытаешься сильнее погрузиться в другую крайность - в своей останешься середнячком.
Обычно именно полные фулстэкеры, кто реально делает и фронт и бэк целиком - зарабатывают меньше, чем настоящие бэки или фронты, так как по сути остаются обычными мидлами.
Есть смысл становиться фулстэком - это когда только вкатываешься в айти и ещё не решил на чем специализироваться, получить опыт везде и на следующей работе уже выбрать конкретнее, либо когда изначально выбрал одну специализацию, но она тебе осточертела и хочешь прекратиться.
Просто оставаться фулстеком дольше года-двух - абсолютно бессмысленно с точки зрения роста и увеличения доходов.
Слышал и буквально знаю двух таких людей, но в России мало компаний столько платят сеньору, не техлиду/тимлиду. А вот на валютной удалёнке такая цифра это примерно нижняя граница для сеньора.