Больше пары строк кода в посте или на скриншоте ведут в ад.
Для программирования на HTML https://jsfiddle.net
Для Node.js с консолькой https://repl.it/languages/nodejs
Если рассчитываешь получить дельный ответ, сформулируй правильно вопрос: «что я хочу получить, что я для этого делаю, что я вместо этого получаю». Если когда самостоятельно найдёшь решение — поделись в треде, мы за тебя переживаем.
Руководство для вката: https://developer.mozilla.org
Ты посты его читал? Насрал нулом там другой разраб.
Хочу, чтобы быстро и просто. Задача: писать админки. И без всякой ёбки с пакетами.
Ещё кстати думал над Elm, что про него скажите ?
>хули в шапке до сих пор нет, для вкатывальшиков
>Руководство для вката: https://developer.mozilla.org
Ты не очень умный, да?
>жиквери
Разве эта хуйня не устарела ?
>>1892244
В том то и дело, я вообще не уверен, что брать. С js знаком плохо, но когда писал на нем, прям плохо становилось, думаю может фреймворки поменяют моё отношение. Кто-то вообще писал админки на чистом js ?
>>1892248
>Ты не очень умный, да?
Все так, мне, как обычному мимо-проходящему, понадобилось мнение экспертов, здесь и сейчас.
Как грамотней организовать эти функции?.
Просто писать функцию и после сразу вызывать? Или сгруппировать вызовы вначале\в конце? Или делать все функции стрелочными, чтобы не всплывали и вызывать по очереди?
>в реакте для этого используют передачу вниз функции обработчика
И чем же это принципиально отличается от эвентов в Vue?
В смысле - в лучшую сторону?
Алсо, передать вниз в Vue можно что угодно, просто этого не делают.
Есть другие механизмы.
Вообще, по части гибкости реакт сосёт у Vue не нагибаясь.
Тут даже и обсуждать нечего.
>>1892138 →
И (возможно) правильно делают.
Потому, что такие вещи, как incapsulation и separation of concerns можно понимать очень по-разному, в зависимости от обстоятельств.
Не надо воспринимать как догму всю хуйню, которую пишут Дядя Боб или Фаулер.
В очень многих случаях тупо иметь всё в одном месте выгоднее, чем высосанные из пальца теории о том, что надо делать по 10 файлов на каждый пук.
Просто ньюфагам такое обычно не говорят.
Как детям не показывают, из какого места они появляются.
ивенты с нагрузкой это как-то странно если честно
вот в свелте например просто биндинг по типу v-model можно сделать на проп лол
а то что во вью можно вниз обработчик передать это собственно естественно т.к. как ты запретишь передать пропом ссылку на функцию, это фишка языка, просто это не принято
ну они же инициируются при присваивании переменной а не до исполнения как обычные
fn(); function fn() { console.log(42) }
вызывается
fn(); const fn = () => { console.log(42) }
выдает ошибку
только не пони какая ему разница если критично когда их вызовут а не когда инициализируют
плюс тут важно не то что стрелочные а что присвоены переменной, короче хз что он имел ввиду, не знаю
fn(); const fn = function() { console.log(42) }
тоже выдает ошибку
https://quasar.dev/ фреймворк на основе vue.js ..тут сразу все изкоробки
Аноны, такой вопрос, научился писать я код, работаю в крупной нефтяной конторе, кругом бюрократия, нас 6 чела в команде, начальник нашей группы никакущий управленец, процесс налажен херово, задачи ставятся без четких требований, заказчик сам не знает чего хочет, короче сделаешь нормально, потом приходится переделывать и тут уже говнокодишь, лишь бы быстрее задачу закрыть. Я оцениваю себя как аппер джун, есть пробелы в базе, я их закрываю читая про алгоритмы и все такое. Но вот как и куда двигаться дальше? Я хочу пересесть на мидловский стул, я пишу код самостоятельно с практиками и хорошими манерами, но ведь мидл делает тоже самое? Что отличает мидла и джуна? Читать про архитектуру? Но ведь она уже как правила заложена ранее и лидами. Анончик, расскажи, как рос сам, что посоветуешь?
Если пишешь все самостоятельно (и не приходится доделовать именно из-за твоих проебов) то добивай опыт до какой-то красивой цифры и перекатывайся в мидла. Почекай вакансии, если будет возможность походи на тестовые собеседования посмотри что там вообще требуют.
«Можно было брать людей с улицы», — рассказывает британский кодер Джон Пайк, изучавший COBOL в 1960-х. «И, по сути, учить их, как писать программы».
Прям таки видится современный формошлеп за 50к который хуячит продающие очередную говноту интерфейсы
> попробуй сейчас вкатиться в какой-нибудь биотех
Совершенно понимаю, что это охуительно непростая задача. Вкатился бы с удовольствием за госсчет, но пока что только вкатываюсь методами превозмоганий да и то только на чистом энтузиазме. Впрочем хер бы с этими хайтеками, меня смущает что ради таких ремесленных знаний как формошлепинг приходится чуть ли не бароном делаться
вот типо таких блок схем что бы накидывать можно было
Почему сплайс изменяет "настоящий" массив, а не копию, переданную в функцию?
мутатор мыть надо, негр у тебя родился, геной назвали
https://doesitmutate.xyz/splice/
скопируй передаваемый в функцию массив и передавай копию а не референс на оригинал
>>>arr = arr.map(value => value + 1);
Доперло вроде. Таким образом я перезаписываю внутрифункционный переменную просто, а архив висящий где-то в памяти это не трогает. Оригинальный массив можно менять только методами, которые его "мутируют" ( https://doesitmutate.xyz ), правильно?
Ссылка: https://source-academy.github.io/sicp/split/
Уровень сеньор (прост с фулстака хочу чисто во фронт перекатиться, и не уверен что достаточно шарю)
Проорал с "ментора" который принципиально не ставит ; в конце statement
)) Ты первый день что ли на двачах? Вон смотри какой кадр нарисовался пару тредов назад: >>1885745 →
Главное этот джун/стажер даже не понял, насколько сильно он обосрался. Это как пытаться выпенриться сказав, что ты сдаешь недвижку и владеешь 1-2 дома в каждом регионе России, думая что это типо круто (хотя ни один вменяемый инвестор в недвижку так не сделает)
А как хочу что-то сам сделать с нуля, вижу пустую директорию в IDE или пустое поле в задачках на литкоде и такой тупёж накатывает, что не знаю что делать, смотрю, туплю и закрываю.
Что со мной не так? Как-то можно такое вылечить?
Я зашел на их сайт, а эта петушня требует авторизоваться и всякую хуйню
Внутри него допустимо аккумулятор мутировать или нужно возвращать новый или похуй? Например, если аккумулятор - массив и нужно добавить в него значение. И будет ли разница в быстродействии?
async updateData(actor, options) {}
То есть некая асинхронная функция передает какие-то данные на бэк для конкретного actor. У меня есть массив где 20+ таких actor, как мне асинхронно разом закинуть их всех на бэк? Не ждать же мне каждый раз когда закончится исполнение предыдущего await чтобы начинать новый запрос. Асинхронщина не для этого придумана
Ясно. Типичный циклодаун не знающий как работает то о чём он кукарекает.
Какое из вне?
Мутировать аккумулятор на итерациях редюса или нет? Вот в чем вопрос.
Вот на пике как правильней? Или например, если аккумулятор - объект.
Я в работе вижу практически всегда второй варик через spread, он и короче и чуть более понятен, можно еще и return убрать. А если ты пушить собрался, то больше смысла имеет определить acc во внешнем скопе и просто внутри forEach пушить. Пушить подозреваю побыстрее будет, но имеет смысл уже на 1000+ элементах.
Потому что цикл читается и понимается гораздо лучше чем дрочево редьюсов с рекурсиями. Кукареки "да ты просто не привык к функциональщине" оставь при себе, в любом современном ФП-языке рекурсия - это в 99% случаев антипаттерн и так существуют list-comprehensions, которые читаются как обычный цикл и используются в тех же местах. Никто не дрочит твои маняредьюсы каждый раз когда им надо n раз пукнуть.
Где "там"? Если в качестве аккумулятора ты используешь переменную, значит делай копию этой переменной и работай c копией, мутируя её в калбэке функции reduce.
Писать [...acc, e] вместо (acc.push(e),acc) будет только конченный дебил почему - показано на пикриле.
>смысл reduce в том чтобы возвращать новый объект на каждую итерацию, а не мутировать его.
Смысл reduce в приведении массива одного вида, в данные другого вида. Это не обязательно объект, это может быть и число.
>Есть хочешь пушить, то внутри forEach
Показывай пример. Только не говори что собираешься мутировать в forEach какую-то переменную извне.
const maxNumber = prompt('Выберите максимально возможное число')
После этого надо выполнить ряд действий, но только если юзер выбрал какое-то число а не нажал на Cancel. Мне явно проверять if (maxNumber !== null) ? Выглядит по-уебански, но я не могу же проверять на if (maxNumber) потому что оно может быть нулем...
Вот в чем суть: есть svg-изображение "стрелочка вверх" при нажатии на которую окно под ним сворачивается, при повторном нажатии - разворачивается, однако я хочу изъебнуться и не делать так чтобы стрелочка всегда показывала вверх, когда нужно развернуть окно, она должна показываться вниз. Как это сделать при помощи ванильного ЖС?
>ФП же требует не мутировать ничего.
Но ты не пишешь на ФП языке, шиз. Нет никакого практического смысла дрочить редьюсы вместо for цикла с мутацией, для потребителя API это будет то же самое, ему абсолютно поебать, спавнит твоя функция 1000 ИММУТАБЕЛЬНЫХ массивов чтобы вернуть результат, или создает этот результат сразу и мутирует его в процессе.
В конктексте жопоскрипта - да, более-менее. Мутировать переданные тебе объекты и так моветон, для этого гением ФП быть не надо, а внутри своей функции можешь хоть в жопу ебаться, главное результат отдай. И в жопу ебаться гораздо приятнее прямолинейным циклом, который любой дебил прочитает без проблем, чем дрочить редьюсы чтобы сделать ФП-шизика счастливее.
Например если в компоненте некий actionFlag = true то на элементе висит хендлер: (click) = "myFunction()"
Тебе уже ответили.
Но, так лучше не делать. И не только в Ангуляре, а вообще.
Эту проверку лучше делать в функции-обработчике. В шаблоне должно быть логики по-минимуму.
А если ты имел в виду назначать/удалять обработчик у элемента, в зависимости от, как делают в чистом жс - то так в шаблонных фреймворках не делают. Если это критично - можно по-разному рендерить элемент - с обработчиком или без, в зависимости от условия.
Аноны, кто разрабатывал игры при помощи web, вы сами рисовали элементы? Если да, то как?
"Правильно" реализовывать - это использовать http-only зашифрованную куку с сессией и вторую куку с публичной информацией о пользователе(id, имя и т.д), обе из которых должен выставлять сервер, чтобы ты мог по публичной куке в любой момент определить статус сессии. Но если сервер пишет непонятно кто, то скорее всего придется дрочить токены и локалсторы.
>import debounce from 'lodash/debounce';
вот так не работает:
>import {debounce} from 'lodash';
импортится весь модуль. Интересно, почему.
Пытаюсь не импортировать весь модуль graphql, используя синтаксис
>import {print as printGraphQL} from 'graphql/language/printer';
но он в бандл тащится весь модуль, когда мне только эта функция нужна.
Я вообще не понимаю как это работает.
this.readableAgents$.subscribe(
(x) => console.log(x)
);
Но в логах он сначала мне пишет пустой список а затем на следующей строке уже список заполненный объектами, хотя console.log я вызываю 1 раз. Почему так?
>Интересно, почему.
По кочану, да по капусте.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import
Поясните, CMS были изобретены для того, чтобы кабанчики вместо заказа сайта у разраба, платили создателю движка? В чём тогда смысл существований совсем простеньких веб студий третьего сорта, берущие простенькие заказы, если их продукты можно заменить CMS. Свой движок и возможность допилить рокет саенс при желании или просто незнание рынка заказчиком?
Мне нужен для скрипта на на сторонний сайт. Сайт на рякте, поэтому просто добавить элемент по domcontentloaded не получится.
Я делаю так - обсервер с наблюдением за дочерними и др. элементами на основной контейнер. Форичем пробегаюсь по всем мутациям и проверяю - есть ли нужный для вставки элемент-контейнер. И вызываю функцию, которая добавляет мой элемент.
Вопрос - как правильней: вызывать функцию на каждую мутацию и делать проверку в самой функции (и ретурн, если нет элемента). Или сначала проверку, а при наличии элемента вызывать функцию.
По этой теме: в rxjs есть Observable вроде этого:
availableNames$: Observable<string[]> = this.openFields$.pipe(
map(fields => [...fields.keys()])
);
Мне нужно внутрь этого массива добавить дополнительное имя "selector", если значение переменной-флага option == true. Был бы это просто цикл, я б на пофиг подмешал туда if но тут-то надо прогать в реактивном контексте, availableNames$ это Observable а не сам массив. Как туда подмешать новое значение в зависимости от переменной-флага?
Анончик, с наступающим, такой вопрос, может где лежат курсы с angular university в бесплатном доступе? Я потом, когда стану крутым разрабом, постараюсь отработать.
https://www.youtube.com/c/TimurShemsedinov/videos
Не совсем понял проблему.
Можешь просто в map смотреть на флаг и менять данные как тебе надо. Если тебе надо что бы данные из Observable менялись ещё при изменении флага, то тут только делать отдельный Observable с переменной флага и смерджить два obs в один.
>>1894631
>>1894635
>>1894676
Обычно одни рисуют, другие - пишут код.
Но, в маленьком проекте всё делаешь сам.
Есть огромное количество готового игрового клип-арта в интернетах.
Просто охуевающее количество, погугли game dev clipart.
Если надо - можно подрисовать немножко к готовому.
Также, есть куча книг по разработке игр на JS.
Там этот вопрос тоже рассматривается.
Гуглить javascript game development book.
Также - есть бесплатные туториалы и видео.
Всё гуглится.
Если не очень можешь в английский - на русском тоже должно быть дохуя всего.
Надеюсь я понятно объяснил, пример на пике, у нас есть два пседоОкна, когда закрываем одно, другое автоматически должно расшириться на его пространство
фигня какая-то у тебя а не объяснение
проще всего это сделать скрыв элемент который закрыли а поведение остальных чтобы заполнили пустое место прописать через ксс
ну а если хочешь ебаться то есть всякие методы для дом дерева типа closest ну а айди ты знаешь просто в листенере как this.id
Ну у меня спека на работе ебанутая. Надо возвращать номер билета обязательно в формате Number, блять. А номер в свою очередь приходит строкой, к примеру "00011". Естественно, при дефолтной конвертации через +, parseInt, Number и тд. оно нули обрезает. Вот я и спрашиваю может есть какой нибудь трюк, или мне просто отвечать чтоб не выдумывали хуйни и возвращали номер в строковом представлении.
вот добрался, держи пример
https://jsfiddle.net/2cqsbx5u/
вот тут
https://stackoverflow.com/questions/56186513/leading-and-trailing-zeros-in-numbers/56188557
предлагают использовать
но не факт что тебе пойдет
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat
>В ответ сервиса JSON
Так возвращай 11. В чем проблема?
>Да ладно?
Слушаю список отличий. Вообще, в JS 011 это 9, но я сильно сомневаюсь, что ты имел в виду восьмеричное представление числа.
>Ты пизданутый или что то? Прочитай еще раз выше пост. Это не моя хотелка, а по идиотски составленная спека.
Для задающего такие вопросы ты слишком агрессивен чот.
Я просто реально не понимаю. Вот ты ведь не поленился напистаь эти 13 строк. А то что это никак проблему не решило тебе вообще пахую?)
>>1895658
Ну во первых не все.
Во вторых я бы уже давно пихнул и расслабился, если не нужно было бы для этого все пересогласовывать и просить поменять спеку и другие сервисы, зависящие от моего.
>Надо возвращать номер билета обязательно в формате Number
>чтобы начальные нули не обрезались и получилось 00011
>формулируй вопросы нормально.
Как? Ну вот скажи, как мне ЕЩЕ сформулировать? Для идиота даже понятно по моему. Но ты не понял.
>>1895667
Ой, а что это у нас такое? Специалист JS треда снова обосрался? Вот не впадлу же вам спорить, когда очевидно что в вопросе ошибаетесь.
Идиоту уже пять раз объяснили, что формата "Number и шобы нули не обрезались" в жопоскрипте, да и вообще в любом языке, нет. Идиот не понял, и продолжает нести свою шизоидную чушь в тред, вместо того, чтобы переформулировать вопрос и сказать наконец, что ему нужно сделать и нахуя.
node.js
делаю реквест на www.twitch.tv/directory/game/Dota%202
получаю респонс
как из него выпарсить названия каналов?
как вызвать больше респонсов от прокрутки?
Так бля, не понимаю, что еще за функции resolve, reject которые мы передаем в Промисе?
Как в nodejs сделать GET с параметрами в URL? Сделал get но параметры не прикрепились (first, game_id)
const options = {
hostname: 'api.twitch.tv',
port: 443,
path: '/helix/streams',
method: 'GET',
first: 100,
game_id: 29307
};
Зачем ты сравниваешь две библиотеки с разными предназначениями? Лодаш библиотека с набором полезных функций-утилит, а жквери это библиотека для манипуляций с домом и сетевыми запросами. Жквери устарел, потому что, во-первых, нативный жс хорошо поднялся, во-вторых, все уважающие себя перешли на фреймворки вида Ангуляр, Реакт, Вуе.
Лодаш не устарел, потому что его функционал еще не заменён нативным жс или фреймворками.
Есть какой то способ упаковать, или сгенерировать dllлку для nodejs скрипта, чтобы он работал без установки nodejs? dependecies: 'fs' 'querystring' 'https'
Более шарящий в чём?
Кстати, восьмеричные литералы с нулём нынче deprecated, про это я подзабыл, ибо давно не имел дела с ними.
Да и в твоём случае они ни при чём - я почитал с самого начала.
То, что ты хочешь - невозможно.
И это не нужно.
Не может быть никакой причины так делать.
Так что, это у тебя либо не число, а код (строка), либо ведущие нули не нужно сохранять, чтобы работать с этим числом.
Если же это таки число, и тебе потом надо отправлять данные назад в таком же виде, с нулями - значит надо делать кастомный форматтер числа для вывода в json.
Если ты расскажешь больше подробностей - возможно, я тебе что-то посоветую.
Ты пиздишь.
Открой, блядь, консоль браузера.
Прямо сейчас открой.
И набери туда просто 011
И сразу, тут же, внизу увидишь 9.
Потом - 0011, потом - 00011 - и снова увидишь 9.
Догадываешься, почему это 9, а не 11?
Потом набери туда 0011 === 00011
Потом - 0011 + 12 === 00011 + 12
В обоих случаях увидишь true
Неожиданно, да?
Есть функция, которая делает свое дело. Как к ней приделать ивент onfinished, так чтобы в нем можно было зарегистрировать другие функции на экзекуцию после неё?
Это восьмеричные числа.
Более того - это, блядь, литералы.
Ты понимаешь что такое литерал?
У тебя там номера билетов, кажется?
Они что, восьмеричные?
Вы там ебанутые?
В любом случае - хочешь восьмеричных чисел из json - нет проблем, используй свой десериализатор, для строк, состоящих из одних цифр, и начинающихся с нуля: parseInt("011", 8)
Просто писать вызов функция() после инициализации или использовать iife?
И как лучше записать одноразовую функцию - обычной или стрелочной.
Стрелочную нельзя вызвать до инициализации.
Имеет ли смысл использовать стрелочные/функциональные выражения вместо обычных для оптимизации?
Скажем, у меня несколько функций внутри другой функции. И часть функций может не вызываться по условию. Если сделать объявления стрелочными после условия или делать обычные функции (которые заранее инициализируются), здесь будет разница?
Вот на пике два варианта.
>>1892152 (OP)
Разберись с промисами. Погугли, почитай что-нибудь.
Ничего особенно сложного, но, в двух словах это трудно объяснить.
Потом можешь задать более конкретные вопросы, если будут.
Начать можешь прямо отсюда:
https://github.com/axios/axios
https://eloquentjavascript.net/11_async.html
Как-то попадалось правило стайлинга, что не принято использовать continue и break. Так ли это? Часто ли сами используйте?
Я вот часто весьма.
val && fn()
fn1() || fn2()
я себя иногда чувствую вебпаком (:
Какие подводные? Кто пробовал такое делать?
Не задавался вопросом, почему до сих пор этот проект не переписан на ваниллу?
Проблема переписывания не столько в самом жикверике, сколько в сопутствующих проблемах, типа переменных в глобал скоупе, на которых может быть завязан огромный пласт логики, прямые манипуляции стилями, плагины к жиквери, которые не совсем очевидно как переписать на ваниллу без ковыряния сырцов.
Это дело может затянутся надолго короче, так что ещё добавь обьяснять кабанчику надобность такого переписывания.
Впрочем, ничто не мешает переписывать отдельные очевидные вызовы типа `$("div")`, пока пилишь очередную фичу в том же файле. И через код ревью проще будет протащить.
>сайты
>монетизируются
как там в 2008
>вызвал его метод
И сразу понял что у меня там, equal, lessOrEqual. При этом могу менять эту логику/модифицировать в любой момент, не ломая код который использует данный объект.
>эту же функцию
Она возвращает -1, 0, 1 Т. е. тебе помимо вызова разных функций нужно еще и проверки самостоятельно делать для того чтобы определить что там у тебя вернулось, и делать это в любом месте, либо пилить какую-то дополнительную функцию, которую ты будешь вызывать в дополнении к основным, т. е. получается размазанный и непонятный код, который сложно понимать.
При этом если ты захочешь модифицировать вывод, например в случае если значения равны, ты хочешь писать данные в лог, то тебе придётся менять все функции, а в случае с ООП ты делаешь изменения только в одном месте.
Ну вот у тебя есть какой-нибудь класс вендорский Compare с методами типа compareByZalupa, ты захотел туда что-то добавить типа comparebyZalupa1, тупо экстендишь, добавляешь. Если у тебя в вендорском коде залупа типа const compare = (matcher, zalupa) и внутри она там какие-то свои правила объявления и обработки этих залуп имеет, то ты сосешь хуй
>И сразу понял что у меня там, equal, lessOrEqual
конечно понял, ты же это написал compare.lessOrEqual(5, 10)
Так же как и я вызвал compare('lessOrEqual')(5, 10) и получил тот же результат
>не ломая код который использует данный объект
сейм
>размазанный и непонятный код
размазанный на три лишних строчки. Другое дело чётенький ООП в два раза больший по объему, и уже не страшно если в три станет
>если значения равны, ты хочешь писать данные в лог, то тебе придётся менять все функции
equal: (a, b) => {
const isEqual = a === b;
isEqual && console.log('...');
return isEqual;
}
три строчки, как я и сказал. Какие ещё функции я должен поменять?
>Почему эти функции нельзя было положить просто в объект или вообще без него?
Если ты про фабричные функции, то методы в них создаются заново с каждым инстансом, что не есть айс в плане памяти. Иначе нужно пердолиться с прототипами, что ещё хуже в плане читаемости по сравнению с сахарком.
>и получил тот же результат
Так ты от темы то не уходи. Я же тебе сказал, в случае если логика сравнения будет отличной от той что ты в своём compare указал, результат будет не одинаковый. Тебе нужно будет либо менять код compare, что повлияет на уже существующий, либо лепить еще одну функцию и дублировать в ней то что ты уже написал в compare, меняя только логику сравнения. Из этого мы и получаем:
>ломает код который использует данную функцию
>размазанный и непонятный код
>три строчки, как я и сказал. Какие ещё функции я должен поменять?
А если тебе нужно будет делать лог только в определенных условиях? Дай угадаю, теперь у тебя функция equal принимает не 2, а 3 аргумента? В общем, ты и правда такой тупой, что не понимаешь к чему подобные модификации ведут или просто неумело троллишь?
Алсо
>compare('lessOrEqual')
>'lessOrEqual'
Ты хотя бы в константы выводи подобное, хоть не такой жидкий обсер получится. Иначе другой долбоеб вроде тебя напишет lesOrEqual и вы потом как биба и боба будете неделю искать в чём же у вас там баг, почему сравнение неправильно происходит.
>Тебе нужно будет либо менять код compare, что повлияет на уже существующий, либо лепить еще одну функцию и дублировать в ней то что ты уже написал в compare, меняя только логику сравнения
пояснил в >>1896809
>тебе нужно будет делать лог только в определенных условиях
в каких? В полнолуние? Для остальных кейсов, когда у тебя функция делает миллион дел, есть параметр с опциями {логать: не}
>ты и правда такой тупой...
потише, дед, не напрягайся, а то сердце схватит
>есть параметр с опциями {логать: не}
Где он? Что-то не видно. Ах, да, щас только вон по той сотне файлов пройдусь, изменю существующее, дополню нужным, проверю чтобы ничего не поломалось и тогда всё появится! О чём и говорилось изначально: Нет ООП - нет планов на будущее.
>Где он?
будет, когда придёт время. Или ты пишешь сразу функцию со всеми возможными вариантами использования на 5 лет вперёд? Тогда моё почтение, пророк
>изменю существующее, дополню нужным, проверю чтобы ничего не поломалось и тогда всё появится
нет, я просто напишу ещё одну маленькую функцию или разделю существующую или сделаю обёртку, а может добавлю коллбек. Ведь я пишу в функциональной парадигме у меня конструктор лего, а не дубовый шкаф на века
Справедливо говоря, в ООП бывает неприятно когда в коде вендора допустим есть метод вроде ок, но там что-то проебано, типа флаг \u не проставлен у регулярки, метод написан хуево и на 500 строк полотном процедурным, и чтобы исправить такую проблему надо делать вообще хз что, то ли переопределять метод и писать в нем почти полную копипасту того что было но с исправлением проебов, либо хз, колдовать
Как сделать тут так чтобы промис не throwил, а просто выполнял fail, когда fail коллируется в GameNameToID?
>>1896938
невермайнд, так норм. Но теперь failу приходиться за собой везде this таскать, можно как сделать без него?
>Но любой адекватный программист знает, что нужно избегать прямых манипуляций с DOM
Это не так.
Любой адекватный программист знает, что все что нужно, это как можно дальше откладывать рефлоу, если он неизбежен, или избегать его вовсе, если это возможно. А для этого достаточно в дом толкьо писать и никогда из него не читать.
А программирование на шаблонах, диффах, и прочим неявным рендерингом нужно для того, чтобы тупые необучаемые идиоты, которые нихуя не умеют, не понимают, и не хотят учиться, не писали говна. Но они умудряются и без этого его писать.
>Каким боком шаблоны к неявному рендерингу.
Потому что это абстракция. Любая абстракция - это уровень невяности. Когда ты пишешь fn() - ты тоже функцию вызываешь неявно внезапно. Явно было бы если бы ты аргументы на стек складывал и управление по адресу передавал.
>И почему если только писать в дом, то рефлоу не будет?
Все изменения дома батчатся и применяются единомоментно в рендеринг-фрейме. Принудительный рефлоу вне цикла отрисовки происходит только если ты будешь читать из дома то, что требует пересчета.
Понятно.
У жсоблядков - параллельная эволюция происходит.
Они открывают для себя те вещи, которые нормальные люди уже открыли многие годы назад.
Например, то, что "явно" писать программы в машинных кодах или на ассемблере - неэффективно. Хотя, на первый взгляд, всё выглядит наоборот.
Поэтому, они с остервенением дрочат на "чистый жс" в противовес jQuery, говорят, что фреймворки не нужны, и занимаются прочими подобными вещами.
Т.е. они живут среди нас, но, ментально отстают лет на 30.
>это почему?
Потому что без параши вида JQuery UI за которым тянется JQuery, не удобно делать хоть какой-то хорошо выглядящий интерфейс.
>jQuery можно использовать с любым фреймворком.
Да, говнокод писать можно используя любой фреймворк в сочетании с любыми библиотеками. Если постараться можно и Vue вместе с реактом использовать.
>Я это делал с react и c vue.
Сочувствую.
>Мне насрать на пидарские табу
Ну если для тебя "писать чистый код" это пидорское табу, то остается только догадываться какой логикой ты руководствуешься высерая подобное.
Я посмотрел читшит по нему и редукс и охуел с того, как все отстало и ебано сделано по сравнению с vue. Особенно оподливился с редьюсеров, где коммон практис - это switch/case для мутирования стейта
В чем реакт объективно пиздат? Потому что я не увидел ни одного плюса по сравнению с vue
Думаю взять macbook air 13 2020. Хватит производительности для IDE + вкладочек браузера и еще какого-то говна сверху? Не будет гудеть, лагать, греться сильно спустя пол года?
Или подскажите свои ноуты бесшумные и не греющиеся особо
Ну о том и речь, что тут спорный плюс)
По факту вью покрывает 99.9% кейсов и потребностей и продуктов.
Если ты хочешь писать что-то супер большое и массовое, где требуется гибкость пиздец и производительность (например свой алиэкспресс, блять, ага). То наверное реакт будет поинтереснее, но шанс на это пиздецки мал.
есть какая-то (полу)готовая библиотека, которая бы позволяла решить задачу создания чего-то типа автокомплита или выпадающего по хоткею/правой клавише мыши списка, который должен генерироваться из csv/json/плейнтекста, лежащего на сервере?
(Я криворукое животное, js не знаю)
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist
С мышью надо пердолить один из мышиных ивентов.
>Реактивность на неявном создании геттеров и сеттеров (собсна сложное и неявное поведение и есть магия).
Что в этом сложного и неявного-то?
>Но иногда эта абстракция протекает и на помощь приходят костыли в виде Vue.set.
Уже давно нет, конкретнее с того времени как начали там юзать proxy
>Алсо абсолютно лютые шаблоны со своим встратым DSL и биндами через магические строки.
вкусовщина
>>1897375
Конечно
>Что в этом сложного и неявного-то?
В смысле что неявного? Ты задаешь плейн объект, а вью под капотом его неявно преобразует в свою структуру, которая работает уже не как плейн объект.
>Уже давно нет, конкретнее с того времени как начали там юзать proxy
Это с v3? Ну молодцы, новый набор костылей завезли. Вроде обычный объект, но ой, деструкция-то не работает. Алсо в консоли прокси красиво смотрятся.
> вкусовщина
В смысле вкусовщина? Использование левого DSL вместо собна JS это хорошо что ли? Как там типизация, нормально работает? Или магические строки в какой-то момент стали вопросом вкуса?
Во-первых пример вынут из жопы и если ты такое дерьмо пишешь в реальной жизни, то ты долбоеб без вариантов, во-вторых если ты хотел показать, что "мам строк кода меньше", то это решается плагином на стрелочные методы, и слева их можно сделать ровно столько же, сколько и справа, в-третьих если ты меряешь качество кода по количеству строк, то смотри пункт 1.
Спустя полгода ничего не будет.
Только сегодня видел у знакомой маши Air, которому 6 лет - пашет, как конь.
У меня 9-ми летний Pro на i7 хуярит за всю мазуту - сейчас с него пишу.
И есть 3-х летний Pro, тоже на i7 - основной, там вообще всё летает.
>Air
Лучше возьми 2-3-х летний Pro б/у.
У них характеристики могут быть даже лучше, чем у сегодняшних прошек.
Я свой 3-х летний не обновляю вовсе не потому, что денег нет, например.
Не дешевле.
Единственная реальная причина - react native, поддержка мобильной разработки.
И то - все плюются на это тупое и тормозное говно, но, под него есть инфраструктура, много наработок и т.п.
Тут другое - инерция мышления.
Люди вообще очень консервативны и инерционны.
Вчерашняя инновация сегодня становится несокрушимым железобетонным барьером на пути следующих инноваций.
Это ты немного промазал - надо было вот ему - >>1897343 - писать.
И да, ты совершенно прав.
>>1897489
Вообще, да, лучше десктоп.
Но, могут быть причины брать ноутбук.
ИДЕ нормально работают на современных ноутах, но, на десктопе - это другое.
У меня (помимо вышеописанных макбуков) есть ещё десктоп 8-ми летний, на i7 3770K, так вот, на нём всё работает несравнимо быстрее, это вообще земля и небо. И надо бы его уже обновлять, но, скорее по имиджевым причинам, т.к. хуярит он как заводной, с быстродействием вообще ниикаих проблем.
Но. это i7 3770K 3.9 GHz + 16 GB + SSD Samsung 850+960 Pro.
Нет, шизики, в мире айти популярность проходит в одно мгновение и никакие "снежные кома" и "привычки" ваше говно в присутствии объективно лучшей альтернативы не спасут, неважно насколько оно большое и популярное. Если с чем-то легче и эффективнее работать, то с этим будут работать, а инертные и менее эффективные конкуренты как всегда останутся на обочине истории, примеров тысячи, начиная от прогрессии языков программирования, заканчивая фреймворками и либами.
А причина непопулярности вью кроется не в том, что "люди тупые и ленивые и не видят что для них лучше" как любят плакать адвокаты любого псевдоинновационного дерьма, а в том, что он объективно громоздкий, неповоротливый и не приносит ничего нового в сферу. Инновационность реакта заключается в том, что они не пошли по стандартному пути "есть html-шаблон, есть жс-код, соединим их магией", а просто выкинули нахуй html-шаблоны как таковые и сделали полностью ориентированную на жс либу, где все, что ты делаешь - это пишешь обычный жс-код. Именно эта ориентированность на код(плюс интуитивно понятный и удобный DSL с минимумом отсебятины) и подняла реакт на его полностью заслуженное место.
>неповоротливый
Понятно всё с тобой.
Пройди на хуй, пожалуйста.
Вью быстрее реакта.
И это, блядь, невооружённым глазом заметно.
И это вытекает из его природы и природы реакта.
Так что, ещё раз, иди на хуй, сынок.
Он мне будет тут рассказывать про сик транзит глория мунди.
Да я код писать начал, когда тебя ещё на свете не было, лол.
>Если с чем-то легче и эффективнее работать, то с этим будут работать
Ты наивен. Рулит маркетинг в первую очередь. Ember.js был отличным фреймворком, но его до сих пор мало кто знает.
Phoenix на беке, позволяет супер быстро лепить стартапы + высокая производительность, но его тоже мало кто юзает, так как нет хайпа за ним.
С реактом тоже самое. У него куча минусов, но его продолжают юзать.
Я пропустил слово "даже".
Даже невооруженным глазом заметно.
Реакт (концептуально) - типично левацкая ебанина.
Коту под хвост пустили все принципы и best practices, наработанные десятилетиями.
Мешанина из говна - наш новый марксистский идеал.
Мы наш, мы новый мир построим.
Но, тут пришли китайцы, и дали пососать.
Потому, что, в отличие от западных полезных идиотов - леваков, они знают что такое марксизм-ленинизм-маоизм не понаслышке. Они сыты этой хуйнёй по горло.
Поэтому, они делают не сферическую хуиту в вакууме, а _практичный_ (практичный, блядь, сука, нахуй) продукт.
А левакам, естественно, неприятно.
>Рулит маркетинг в первую очередь
Это смешно, когда шизики с шапочкой из фольги рассказывают про то, что рекламой можно заставить человека купить что угодно, но еще смешнее, когда они говорят, что рекламой можно заставить разработчика против его воли пользоваться бесплатным опен-сурс фреймворком.
>Ember.js был отличным фреймворком
Не был.
>Phoenix на беке, позволяет супер быстро лепить стартапы
Писал на нем хоть что-то или маняфантазируешь? Я вот случайно так получилось писал и пишу, и хоть фреймворк и язык действительно отличные, но для "быстрой разработки стартапов" до рельс и их инфраструктуры им еще грести и грести. Так что популярность рельс и непопулярность пеникса в этом отношении абсолютно объективны.
>У него куча минусов, но его продолжают юзать.
"Куча минусов" не говорит ни о чем, потому что а) в 99% случаев выясняется, что это твой субъективный манямир и реального минуса ты назвать не сможешь б) оценка производится не в вакууме, а в контексте. И в контексте текущей ситуации фронтенд-разработки, лучше реакт нет ничего.
>>1897539
>Коту под хвост пустили все принципы и best practices
Во-первых пук в лужу без конкретики, во-вторых реакт - это либа, и его способность определять бест практики и структуру твоего приложения очень ограничена по определению. В отличие от.
>аряяя китайцы леваки марксизм
Таблетки выпил?
>заставить разработчика
Так разработчик ничего не выбирает. Выбирает СТО или владелец бизнеса если шарит. А уж эти товарищи смотрят именно на хайп и тренды. Да и разрабы честно говоря тоже. Много кто знает про hotwire и stimulus например? Нет, конечно, ведь сейчас же SPA подход суется в любое очко, даже там где он вообще нахуй не нужен. Но хайп есть хайп.
>Phoenix
Медленнее, чем руби, это еще не значит что меделенее чем на Node.js или Java.
>Ruby
Вообще не популярен. Очень мало вакансий в сравнении с всеми остальными и новые проекты на нем уже почти не стартуют вообще.
>реального минуса ты назвать не сможешь
Да пожалуйста.
1). Хоть это все голишь и либа, как любят задвигать адепты реакта, но на выходе сайт на реакте весит просто овер дохера. 500-600 килобайт на первую загрузку, как нехуй делать.
2). Отсутствие встроенной архитектуры, из-за чего кодобаза на реакте очень быстро скатывается в говно.
3). Самосборный фреймворк на базе реакта, состоит чуть более чем полностью из пакетов рандомных васянов.
4). Сама по себе разработка очень долгая, в связи с черезмерным оверинжинрингом, как и у всех СПА решений, кроме свелте разве что, (но там свои проблемы)
>Это смешно ...
К сожалению, это нихуя не смешно.
Вокруг множество примеров того, как побеждают откровенно неэффективные решения и подходы, как людей вынуждают потреблять некачественные товары, и они соглашаются с этим. При этом эффективные решения предаются забвению, производители качественных товаров разоряются и т.п.
Люди - тупое стадо.
Ты видел эти BLM баннеры на сайтах крупнейших разработчиков?
Ну и вот.
>Так разработчик ничего не выбирает. Выбирает СТО или владелец бизнеса
Владельцу бизнеса, которому хватило мозгов этот бизнес организовать, всегда хватит мозгов на то, чтобы проконсультироваться по поводу технических альтернатив и вариантов с технически подкованным человеком. Ты же несешь шизу уровня "я бы писал хороший код, да менеджер не разрешает" и пытаешься представить себя(и других разработчиков) в виде безответственного безвольного дрона, в которого менеджер/тимлид/директор загружает команды, а дальше хоть трава не расти, надо выполнять.
>но на выходе сайт на реакте весит просто овер дохера. 500-600 килобайт
Действительно огромная проблема, но ты лет на 15 с ней опоздал.
>Отсутствие встроенной архитектуры
Я просил минусы, а не плюсы.
>Самосборный фреймворк на базе реакта, состоит чуть более чем полностью из пакетов рандомных васянов
Из чего состоит любой опенсурс фреймворк, если не из "пакетов рандомных васянов" по твоему определению? Или если рандомные васяны собрали свои пакеты в один репозиторий, то это сразу меняет дело? И так же не вижу, при чем тут сам реакт.
>Сама по себе разработка очень долгая
Ты сказал или примерно почувствовал?
Знал бы ты, сколько сил и времени я в своё время потратил на это ваше руби.
Дурак был, потому что.
Интуитивно понимал, что это хуета.
Но, думал, что не может же быть, чтобы столько уважаемых людей продвигали откровенную хуйню. Думал, что это я не понимаю чего-то важного.
Потом поумнел.
А потом и время расставило всё по своим местам.
Но, в качестве концептуальной вещи (а не рабочего инструмента), руби оказался мне весьма полезен, в своё время.
Где ты увидел историю моей жизни, сынок?
Я рассказал о совершенно конкретных вещах, и провёл совершенно конкретные параллели.
С нуля это невозможно.
Надо сначала вкатиться в разработку простых веб приложений.
И не надо пытаться сократить путь, это даст совершенно обратный результат.
Рекомендую использовать Vue для фронтенда.
На этом пути тебя не будут ждать никакие подводные камни - их там просто нет.
Всё ровно и предсказуемо.
В отличие от реакта, например.
Вообще, это обширная тема.
И с чего начать - зависит от многих факторов.
Например - знаешь ли ты английский?
Что ты умеешь на данный момент?
Каков личные предпочтения в технологиях и т.п.
>>Коко, реакт даёт нам возможность писать как мы хотим и все видеть и понимать
Это нахуй не нужно почти всегда. Ты платишь эту прозрачность кучей проблем. Кодовая база везде разная, Либы везде разные, код стайл разный, архитектура разная, все почти везде разное. Новые проекты стартуют куда больше чем на вью, потому что это ебаная лиьа которая толком нихуя не умеет.
>реакт даёт нам возможность писать как мы хотим и все видеть и понимать
Это фальшивый аргумент.
На Vue я пишу так, как хочу.
И мне совершенно всё понятно.
При этом, большинство реактоблядей не могут сказать то же самое про реакт, про хуки, контексты, редуксы и прочее.
Аргумент про (якобы) "неявные" реактивные привязки в Vue - просто смешон.
Это что-то на уровне "я не знаю, что там компилирует этот ваш компилятор, поэтому, буду писать прямо в машинных кодах".
Любого, кто предъявляет подобные аргументы, нужно смело посылать на хуй, не вступая в дискуссию.
>При этом, большинство реактоблядей не могут сказать то же самое про реакт, про хуки, контексты, редуксы и прочее.
Хуки и редуксы к которым у вью шизиков всегда почему-то есть претензии - это способы менеджить стейт в реакте, причем очень прямолинейные, контролируемые и понятные, как только поймешь их принцип. Не вижу, почему они должны быть сложнее для понимания, чем вью-система для стейта, которая по сути является неявным setState, работающим через жопу и кучу оберток-проксей.
>и понятные, как только поймешь их принцип
useCallback will return a memoized version of the callback that only changes if one of the dependencies has changed. This is useful when passing callbacks to optimized child components that rely on reference equality to prevent unnecessary renders (e.g. shouldComponentUpdate).
useMemo will only recompute the memoized value when one of the dependencies has changed. This optimization helps to avoid expensive calculations on every render.
Помогло?
Я понимаю как работает vue
У меня претензии в реакте не к тому, что там что-то НЕПОНЯТНО, а к тому, что скорее убого
https://github.com/reduxjs/redux/blob/master/examples/todos/src/reducers/todos.js
Вот офишл экзампл, простейший туду апп. Что блять за свичт-кейс? Почему перезапись стейта сделана через ВОЗВРАТ значения из редьюсера?
Сравни с тем же vuex, где во-первых мутации сделаны отдельными функциями, а не пердоленьем со switch/case в 2020 (я чо бля, на первом курсе снова и пишу лаба2.цпп?) и прозрачно понятно, откуда БРАТЬ стейт, а какая хуйня его ИЗМЕНЯЕТ
Отклеилась ссылка на vuex
Тут разбили на отдельные файлы экшны и мутации, я обычно в одном файле делаю, но суть понятна
https://github.com/vuejs/vuex/blob/dev/examples/todomvc/store/mutations.js
https://github.com/vuejs/vuex/blob/dev/examples/todomvc/store/index.js
Нет, я понимаю конечно что реакт топит за функциональное программирование, и его подход в этом плане более трушный
Но ФП в промышленной разработке хуево взлетает, работает в лучшем случае какой-то гибрид типа скалы
А в реакте вангую в реальных проектах есть овердохуя костылей для сайд-эффектов, которые в реальном, а не кукаретическом программировании очень нужны бывают
Стейт-менеджмент не равно редакс. Глобальный стейт, для которого редакс и сделан, нужен примерно никогда, а в тех редких случаях, когда он нужен(сессия, например), есть менее нагроможденные альтернативы типа эффектора.
>>1897804
На редакс у меня дохуя возражений, но речь идет не про него, а про реакт, и я не вижу, с чего ты начинаешь перескакивать с темы на тему и ставить знак равенства между двумя независимыми либами.
>Вот офишл экзампл
Редакс это не часть Реакта, алое. Но поскольку в Реакт входит useReducer, то не вопрос, отвечу.
>Что блять за свичт-кейс?
В чем проблема?
>Почему перезапись стейта сделана через ВОЗВРАТ значения из редьюсера?
Потому что в этом смысл редьюсера — принять старый стейт и ничего не мутируя вернуть новый.
>Сравни с тем же vuex, где во-первых мутации сделаны отдельными функциями
Сравнил. Чем создание функции increment с this.count += payload принципиально лучше case actions.increment: return state + action.payload?
>прозрачно понятно, откуда БРАТЬ стейт, а какая хуйня его ИЗМЕНЯЕТ
И чем же обращение по this прозрачнее чем state из аргумента?
>ну город в куках ок, хотя читать куки из любого места где может город понадобится как-то не очень удобно
Город может понадобиться только в одном месте - на сервере, который его учитывает в формировании ответов, а фронт этот город должен максимум отобразить. Если ты считаешь, что читать город из локалстора и передавать его в каждом запросе удобнее, чем просто хранить в куках, то тебе надо пересмотреть свое понимание удобности.
>а вот корзину и в куки не засунешь, типа предлагаешь ее каждый раз запрашивать?
Разумеется запрашивать, или ты думаешь, что клиент должен иметь разные корзины на мобилке и в веб-версии? Корзина гостя - это просто вариант корзины клиента и реализовывать ее через локалстор, вместо такой же серверной реализации, смысла нет. Запрашивать не каждый раз, а один раз при первом рендере(или когда надо явно обновить).
Задачка
У тебя есть компонент Рынок который в конкретный момент времени показывает один из дочерних компонентов
1) Огурцы
2) Помидоры
3) Бананы
Для отображения компонента Огурцы тебе нужно забрать с сервера список с огурцами, для Помидоров список с помидорами и тд
Какой вариант ты выберешь?
1) Держать все три компонента в памяти с их списками
2) Каждый раз при показе дочернего компонента создавать новый и снова запрашивать данные с сервера
3) Держать списки помидоров, огурцов и тд в родительском компоненте Рынок
Любой компонент, который прямо основывается на данных с сервера, должен эти данные дергать каждый раз, когда маунтится впервые, кроме невероятно редких случаев. А на твой вопрос можно выбрать и 1 и 2, потому что в такой формулировке это один и тот же вариант, разницу между ними ты сформулировать не сумел.
ты думаешь только об одном обращении к апи, а ведь это все нужно и просто для отображения
простейший пример, у них например при наличии товараов в корзине на иконке корзины появляется количество товаров в ней
ты предлагаешь делать такой запрос на корзину отдельно для этой кнопки из ее компонента? а как она узнает что его снова надо сделать? может туда еще и сокет прикрутить лол
в разы проще хранить корзину в стейте
Консоль браузера - это debugging tool и ее разработчик может туда засунуть что угодно, включая возможность для удобства писать await вне функции(который под капотом все равно выполняется внутри функции, потому что в жаваскрипте в принципе нельзя по-другому).
ПЕРЕКАТ >>1897984 (OP)
ПЕРЕКАТ >>1897984 (OP)
ПЕРЕКАТ >>1897984 (OP)
ПЕРЕКАТ >>1897984 (OP)
ПЕРЕКАТ >>1897984 (OP)
ПЕРЕКАТ >>1897984 (OP)
ПЕРЕКАТ >>1897984 (OP)