Больше пары строк кода в посте или на скриншоте ведут в ад.
Для программирования на HTML https://jsfiddle.net
Для Node.js с консолькой https://repl.it/languages/nodejs
Если рассчитываешь получить дельный ответ, сформулируй правильно вопрос: «что я хочу получить, что я для этого делаю, что я вместо этого получаю». Если когда самостоятельно найдёшь решение — поделись в треде, мы за тебя переживаем.
Руководство для вката: https://developer.mozilla.org
Легитимный тред
что за глупый вопрос
то что во первых меньше запросов надо, а во вторых ты замучаешься определять когда надо делать запросы потому что корзина поменялась где-то в другой части приложения
Это жаваскрипт.
Жаваскрипт это имплементация экмаскрипт. А экмаскрипт - это встраиваемый язык без средств ввода вывода. На голом ес ты даже console.log не напишешь. Все, что ты делаешь на жс - это то, что предоставляет ранйтайм куда он встреон. И рантайм везде разный - нода, браузер, ардуино, фотошоп, автокад, что угодно еще. Даже nginx.
>то что во первых меньше запросов надо
Или писать эндпоинты нормально, а не высирать весь список джейсоном на каждый пук.
>а во вторых ты замучаешься определять когда надо делать запросы потому что корзина поменялась где-то в другой части приложения
Можно подумать со стором ты не заебёшься определять состояние корзины, когда сайт на двух страницах открыт. А если ещё и воркеров сверху насыпать, то там вообще анал карнавал начинается.
Питон изначально делался для УЧЁНЫХ, но не инженеров-программистов. Вот для тех, кому язык нужен в научной работе, и у кого культура соответствующая. Это чувствуется. В этом его уникальность, кстати.
Потом уже на питон начали навешивать инженерные фишки, чтобы дружить его с прикладным программированием.
А точнее, история языков:
Питон делался для учёных не программистов.
JS делался для того, чтобы добавить динамики в простенькие веб странички.
PHP делался для того, чтобы добавить чуть динамики в сгенерированные сервером странички.
Это такое родовое происхождение языков. Все три серьёзно выстрелили, и их уже стали конвертировать в серьёзные индустриальные инженерные языки для профессиональных разработчиков. Но во всех их "родовые травмы" проявляются.
Ну пили язык для фронта. А потом убеди произвоителей браузеров, что его все должны внедрить, в полном соответствии со стандартами.
С другими языками проблема в том, что они сначала выросли, потому что были в нужной нише, а потом стали думать, что не очень удачные. А при этом уже накоплена огромная кодовая база.
А переделывать сложно, вон как больно питон с v2 на v3 перекатывался, при том что изменения были умеренные.
https://www.smashingmagazine.com/2013/07/introduction-to-photoshop-scripting/
А вообще - набираешь в гугле photoshop javascript, и охуеваешь от открывшихся перспектив.
Не совсем то, что я ищу. Мне нужно что-то, типо, тех документации js с пояснениями операторов и всего такого.
https://www.w3schools.com/js/default.asp
И операторы, и хуяторы, и всё остальное.
Что я пробовал: разворачивать сайт через npm run deploy, указывал там в package.json все что нужно, делал по этому туториалу https://create-react-app.dev/docs/deployment/#github-pages-https-pagesgithubcom и всё равно получаю хуй с маслом. Так же пробовал делать как в этом видосе: https://www.youtube.com/watch?v=ctLFWAanxcI&list=LL&index=1 и тоже не помогло. У кого-нибудь может было?
Мой браузер говорит что руководству пизда
Господе, ну какой русик? Ладно, иди на https://learn.javascript.ru тогда.
Немного полистал - годно
Встретил эту поебень в этом коде
let array = []
for (let i = sortItmAll.length >>> 0; i--;){
array = sortItmAll
}
Непонятно как работает, но работает.
Могли бы пояснить для тупых за код?
Что значит эта хуйня?
"Присваивание с беззнаковым сдвигом вправо"
Какие нахуй биты, вы чо угараете?! Вы чо угараете, какие биты??
"The unsigned right shift operator (>>>) (zero-fill right shift) shifts the first operand the specified number of bits to the right. Excess bits shifted off to the right are discarded. Zero bits are shifted in from the left. The sign bit becomes 0, so the result is always non-negative. Unlike the other bitwise operators, zero-fill right shift returns an unsigned 32-bit integer."
Учитывая, что высокоуровневые языки программирования как раз и были созданы, потому что с битами и байтами вручную дрочиться - это больно, неэффективно и не нужно в 99% случаев, то ничего необычного, что пишущий на таком языке программист не знаком с битовым представлением, если перед этим отдельно его не выдрочил по какой-то причине. Твой высокомерный пук неуместен.
Так первый как раз не хардкод. А то, что ты хочешь получить, называется абсолютизация ссылок, и нет способа как-то сделать, чтобы написал и работало.
Самый простой способ - написать вспомогательную функцию, склеивающую `Request.protocol` и `Request.hostname`, которая идёт аргументом `base` к конструктору `new URL()`, а результат этого конструктора вставляется в `href`. Жирный недостаток - ссылка будет меняться в зависимости от адреса запроса. На запрос c http будут ставится http ссылки, а на https - https, что для поискового робота будет считаться как две разные ссылки и соответственно дупликацией контента. Для решения этой проблемы нужно настраивать редиректы, но там тоже не без подводных камней. По сути хуже относительных ссылок, так как не решает проблемы и требует смены архитектуры.
Другой способ - склеивать базовую ссылку через переменные среды, а функцию, создающую финальную ссылку, запихать в `app.locals`, что сделает её доступной во всех шаблонах. Недостаток конечно же в харкоде и при смене хоста нужно не забыть подправлять конфиги ручками. А уж со всякими проксями вообще анал-карнавал начинается.
В общем ставь относительные ссылки и не выёбывайся. Если вдруг кабанчик наймёт сеошника, который скажет тебе абсолютизировать/канонизировать ссылки, тогда и будешь костылить решение.
Ты все еще не назвал причину, по которой человеку, программирующему на любом высокоуровневом языке, нужно в своей ежедневной практике знать, что такое биты и как их можно сдвигать. Если идти по бессмысленным эмоциональным кукарекам "ита же азы как их не знать", то и тебя можно отправить учиться паять процессоры и переизобретать ассемблер, потому что это еще больше "азы".
Причина простая - программирование это сложная инженерная дисциплина требующая высокой квалификации для решения постоянно возникающих нетривиальных задач по обработке информации. На рынке, конечно, до сих пор есть место для макак-формошлепов, но эта ниша, во-первых, занята индусами работающими за плошку риса, а во-вторых, понемногу закрывается разными генераторами этих самых форм
> паять процессоры и переизобретать ассемблер
Может быть процессор я не спаяю и ассемблер не переизобрету, но в том как устроены процессоры с ассемблерами я например разбираюсь
Чувачок, у тебя аргументация на уровне детского сада.
Если ты не понимаешь, что такое байт, сдвиг, побитовые операции - ты не программист.
Это как не знать, что Земля круглая, примерно.
Но, можешь утешаться тем, что таких псевдо-программистов довольно дохуя в мире.
>Причина простая - программирование это сложная инженерная дисциплина требующая высокой квалификации для решения постоянно возникающих нетривиальных задач по обработке информации.
Что же тогда в НИИ крестовики за МРОТ работают?
>но эта ниша, во-первых, занята индусами работающими за плошку риса, а во-вторых, понемногу закрывается разными генераторами этих самых форм
Ох уж эти фантазии разработчика заднего конца. Скорее бэкэнд заменят конструкторами, в котором только разбирающиеся пердолики останутся, а всяких перекладывателей джейсонов отправят на мороз.
>Может быть процессор я не спаяю и ассемблер не переизобрету, но в том как устроены процессоры с ассемблерами я например разбираюсь
Что нихуя тебе не поможет при спаивании процессора и написания ассемблера.
Все еще не назвал причину и область применения такого знания в ежедневной работе программиста высокоуровневого языка.
>Может быть процессор я не спаяю и ассемблер не переизобрету
Как же так? Ведь
>программирование это сложная инженерная дисциплина требующая высокой квалификации для решения постоянно возникающих нетривиальных задач по обработке информации.
а ты даже процессор спаять и запрограммировать не можешь, если вдруг придется решить "постоянно возникающую нетривиальную задачу" по пайке и программированию процессора, формошлеп.
>>1898910
>Если ты не понимаешь, что такое байт, сдвиг, побитовые операции - ты не программист.
Это потому что ты так сказал? Ну я тогда сказал, что если процессоры не умеешь паять, то ты не программист, парируй, непрограммист.
Пендоский не уважаю, но со временем пойму, благодарен.
>>1898934
>>1898907
Приятно, что начал срач.
>Не дрочиться постоянно с битами и байтами != Не разбираться в азах информатики
На уроках информатике мы играли в ксс, извини.
А на практике не приходилось сталкиваться с битами. До недавних пор.
>понемногу закрывается разными генераторами этих самых форм
Что за генераторы? Моя мама была не права, когда отдавала меня учиться на вебдев к хауди-хо? Генераторы, Анон, что они значат?
>>1898944
>Каким образом уровень языка программированирования >освобождает от обязанности знать азы? Ну напиши мне хекс-
>редактор без знания двоичной арифметики. Или это слишком >низкоуровневая задача по-твоему?
Вообще не интересует хекс-хуекс. Чисто для себя на жиесе кодю. Вот заканчиваю туду, что-то вроде проект-менеджера.
Ты бы видел мой php. Моя база данных - сохранение html в файл.
Мимо тот Анон, который не знает про сдвиг битов.
// Sort Priority
function PrioritetSorter(){
let sortBlock = document.querySelector('.content')
let sortItmAll = document.querySelectorAll('.prioritet')
// convert nodelist to array
let array = []
for (let i = sortItmAll.length >>> 0; i--;){
array = sortItmAll
}
// perform sort
array.sort(function(a, b) {
return Number(a.innerHTML) - Number(b.innerHTML)
});
// join the array back into HTML
let output = ""
for (let i = 0; i < array.length; i++) {
output += array.closest('.content_itm').outerHTML
}
// inner text in
sortBlock.innerHTML = output
ReloadAll()
}
//
Спиздил где-то сортировку. Работает, но не понимал ">>> ".
>Процессоры паяют электронщики, а не программисты.
Ну а с байтами тогда дрочатся байтоебы, а не программисты.
>И в JS умею лучше тебя.
Опустим твои выдумки и вернемся к вопросу - почему "настоящий" программист должен знать побитовые операции, но внезапно не должен уметь паять процессоры? Ответ будет сегодня или опять продолжишь вилять жопой?
Добрый вечер о великие фронтендеры всея двача. Обращается к вам подданый низкоуровневый грязный и немытый разработчик бэкенд серверный гречневый. Прошу о фронтендеры, дайте совет заблудшему грязному негодяю.
Короче в чем суть. Сейчас пилю пет проект ну ок не совсем пет, но будет опенсорсным, суть в том, что один из главных интерфейсов - это веб морда. Соответственно разделен он на обособленное API, которое можно будет дергать по http, апи хранит в себе основной функционал и в таком роде. Так вот, в чем вопрос - как лучше организовать SPA фронтенд? Писать буду самостоятельно, что там у вас сейчас актуально для этой темы, возможно будет обособленный бэкенд на ноде (т.к. основное апи пишется на низкоуровневом языке, если есть возможность - не тащить туда бизнес процессы типа регистраций и в таком роде), но пока все в процессе планирования. Если тут есть не только вкатуны в жс, но и состоявшиеся фронтенд боги, вертящие фреймворками и технологиями как хотят - буду рад советам.
Пока думаю просто взять vue с нодой/питоном и не париться особо, слать все запросы через бэк самого фронта, а апи так и останется внутренним изолированным сервисом с кор логикой.
IndexedDB на практике как часто юзается? Или это антипаттерн?
> nuxt
Кстати у нас он был на прошлом месте работы у фронтендеров. Постоянно слышал как у них жопа горела, когда пытались авторизацию реализовать. Я не заебусь его изучать, он кажется очень комплексным, а переквалифицироваться в фронтендера не хочется.
> nestjs
Пиздец у вас фреймворков, аж в глазах рябит
>как лучше организовать SPA фронтенд
Делай сервис чтобы дергать API, опиши модели данных с помощью классов, организуй хранилище этих данных, потом отрисовывай реактивно на страничку. Не забуть взять какой-нибудь роутер и запилить наиболее часто используемые виджеты в виде компонент
мимо гуру фронт-енда
Документация для быдла ебаного!
А если серьезно, то просто появлялась идея и гуглил ее. Именно эту сортировку вроде с стаковерфлоу украл.
Знаю, что лютый говнокод, но он работает!
>Потому же, поему не каждый фотографирующий фотограф
Потому же - почему? Опять причину забыл назвать.
>Ты настолько долбоеб с идиотскими аналогиями
Аналогий я не использовал, программирование процессоров - это не аналогия, это абсолютно такие же программистские "азы", как и дрочево битов, просто более "азовое", и почему-то такие "азы" у тебя вызывают дискомфорт.
И ответ на самом деле прост, ты путаешь историю программирования с профессией программирования. Тот исторический факт, что диды без байтоебства не смогли бы изобрести высокоуровневые языки программирования, никаким образом не накладывает обязанность байтоебствовать на современного профессионального программиста. Если хочешь аналогию, то это то же самое, что говорить "ты не настоящий повар, потому что не можешь дичь освежевать, а только с готовыми кусками мяса работаешь".
>>1899007
>Может лично тебе никогда не понадобится, но если вдруг понадобятся
А если тебе вдруг понадобится запрограммировать процессор? Или написать нейросеть? Или принтер починить? Или в жопу поебаться с тимлидом? Вдруг понадобится, а ты не умеешь и обосрешься? Срочно беги изучать.
> опиши модели данных с помощью классов, организуй хранилище этих данных, потом отрисовывай реактивно на страничку
На чем это будет проще сделать, чтобы не требовалось 2 года опыта во фронтенде, но при этом и не сделать лютое говнище неподдерживаемое? У меня опыт во фронте - это Vuejs с реактом на уровне написания компонентов в не SPA, я боюсь, что погрязну во всем этом на месяцы, а желательно побыстрее закончить. Но в любом случае фронт будет отдельно, вероятно без ноды не обойтись, ибо апи будет через гейтвей с потенциалом скейлинга в ширь.
Нукст хорошей идеей будет? Вроде все в одной коробке с сервером и фронтом, если не ошибаюсь? По сути на фронте будут личные кабинеты с регистрацией возможно нахуй, просто oauth запилю и бд юзеров по факту.
Vue+Vuex+ES7
>Нукст хорошей идеей будет?
Если SSR нужен, то бери, если не нужен - забей
>>1888626 (OP)
Сап, двач.
1. Хочу сделать такой же красивый gui, как пикрелейтед1. В окошке несколько прямоугольников c надписями(до 10^6), между некоторыми рёбра-курвы. Разумеется далеко не все прямоугольники надо рендерить одновременно, нужна навигация в таком окне + изменение масштаба - удалить, приблизить, чтобы не слишком эти самые прямоугольники руинило.
2. Хочу сделать такой же красивый gui, как пикрелейтед2
Есть ли на javascript что нибудь подходящее для такой задачи?
Ты написал хуйню, если коротко.
Ты предлагаешь запретить строки с пробелами в качестве ключей объектов?
Или брать всё до двоеточия?
Тогда запретить двоеточия?
Или смотреть - есть кавычки или нет, и, если нет, то брать слово целиком?
Так не делают форматы, чувак.
Более того, с чего ты взял, что в этой теме кого-то интересует быстродействие любой ценой? Кто тебе это сказал?
Преждевременные (микро) оптимизации - маркер ньюфага.
нормально общаться учись, а не как агрошкольник
ввести один спецсимвол разделения ключа и значения(сейчас это двоеточие), если нужно в имя вдруг его засовывать, то как и сейчас механизм через слеш, само имя просто не весь юникод, а ограниченный набор аски (например, нечно похожее в виде ограничения есть на формат 3d моделей gltf и как раз таки для упрощения и ускорения, потому что реально никто почти не использует весь юникод для ключей, а парсинг замедляет)
Ты поучи ещё меня хорошим манерам, щенок ёбаный, лол.
По самой постановке твоего вопроса уже всё понятно.
И ты упорно не читаешь ответы.
Тебе, блядь, сказали - это формат для представления JS _объектов_.
Понимаешь?
Ещё раз - ты хочешь ввести ограничения на то, какого рода строки могут быть ключами _объектов_ в JS?
Ты долбоёб?
Про биты выше не ты писал, что они не нужны?
Если тебя не устраивает скорость обработки JSON - используй свой фомат. Так раньше делали сплошь и рядом. И сейчас делают, но, реже, т.к. на быстродействие стало похуй - оно априори достаточное.
>формат 3d моделей gltf
Охуеть пример. Ты в курсе, что джейсоны используют для передачи произвольных данных, а не для пробрасывания ноликов и единиц в графическом движке? Распарси-ка таблицу с твоей охуенной идеей, погромист наверно должен сам придумывать названия всех ключей, даже если таблицу в первый раз в жизни видит.
Если у тебя от джейсона бомбит, то с XML наверно вообще сердце остановится от оптимизаторства.
У жсона относительно большая спецификация с чётко прописанными штуками типа обязательных двойных ковычек в ключах и обязательного отсутствия трейлинг запятой, например
Макакить любую хуйню в фигурные скобки тебе даёт рассчитанный на макак рантайм
Перформанс-ориентированные парсинг либы не сожрут и одинарные ковычки
Ты конечно охуеешь мой юный друг, но реальный мир использует от силы 0.1% от того что было придумано в теоретической математике. Типа суперзадач - реального применения нет, но идея интересная (в парте 6 жожо есть стенд который уменьшает тех кто бежит до владельца в 2 раза - это и есть суперзадач). Так и идёт развитие - однажды ктото думает как бы реализовать ту или иную хуйню и внезапно находит что решение уже давно было придумано в теоретических сферах наук, но никогда не было реализовано. Хаскелл это просто для теоретического дроча, почитай что сами авторы языка о нем говорят.
Не, вывод должен быть: задачи - говно. Но ты ещё маленький чтобы понять суетность мира, и почему некоторые вещи делаются по фану. Ирвинг Финкель всю молодость потратил на расшифровку правил для королевской игры Ур. Практической пользы от этого мало в итоге. Ему просто доставило это делать.
>Ирвинг Финкель всю молодость потратил на расшифровку правил для королевской игры Ур. Практической пользы от этого мало в итоге
Не, знание истории намного более практично чем кажется. Другое дело, что практичность часто совсем не понятна обычному мимокрокодилу, лишенному знания контекста
Просто оборачиваешь весь скоуп в асинхронное мгновенно вызываемое функциональное выражение и не паришься.
А по-хорошему, если ты делаешь какой-то ассинхронный запрос, то ожидаешь ответа или его отсутствия, то есть в любом случае нужно возвращать какие-то данные и обрабатывать ошибки. А такие простыни пихать мгновенным вызовом - не уважать себя и других людей, читающих твой код.
Объясните, почему при передаче одной и той же функции в разные переменные, при вызове через эти переменные, они ведут себя как две разные, но идентичные функции? Насколько я успел понять, функция это объект где-то в памяти, и тут оба counter должны ссылаться на него, но выходит не так.
По-хорошему ещё бы надо и всякие мета-данные сохранять, чтобы их сразу кормить в шаблон.
>>1899599
Ты в курсе, что у базы данных и файл-серверов взаимоисключающие требования к работе? ДБ нужно как можно более эффективно шуршать по произвольным данным, а файл-серверу нужно как можно быстрее отправлять огромные массивы.
Для браузера фетч в сто раз лучше, проще и прямолинейнее в использовании, аксиос - это нагромождение лютой хуйни, 99% из которой мало того, что не нужно и может быть заменено одной функцией(интерсепторы, две трети опций в конфиге и т.д), так еще и сделано через жопу.
>>1899669
>В фетче нужно пердолить свою реализацию прогресса загрузки
Во-первых, в фетче это сделать невозможно в принципе.
Во-вторых, в аксиосе тебе тоже нужно ее "пердолить" до хоть сколько-то удобоваримого состояния, потому что это по сути просто API XMLHttpRequest и если уж ты его готов пердолить, то сделать отдельную обертку на редкую загрузку, реально требующую прогресс бара, будет не сильно сложнее.
В-третьих это хуйня на переферии, никто не выбирает http-клиент по "а можно ли там прогресс аплоада получить".
>аксиос на старых эксплорерах работает.
Фетч с полифилом тоже работает.
откуда учить теорию js?
Это тебя просто Кантор говно заставляет писать, я НИГДЕ не видел использование промпта за пределами его справочника.
Вкатывайся лучше с гайда в MDN, там хоть по HTML/CSS сперва пробегают, так как их нужно знать для манипуляций с DOM'ом в жс.
А этот пример сразу хёвым практикам учит: использование prompt/alert, неявный возврат значений.
JS - лучший фронтенд язык?
Ты свой пилпуль оставь для своих дружков-пердоликов.
>Не умничай, клоун.
Охуенные истории от косноязычного дебиловатого педанта, пытающегося приебаться к семантике и жиденько обсирающегося в этом.
>То, что ты не особенно талантлив по части языков, это было сразу понятно.
>Зайди в гугл транслейт, и посмотри, как immediate переводится на русский.
Бля, гугл транслейт оказывается истина в последней инстанции по русскому языку! Это ты благодаря ему свой аргумент высрал?
Вот тебе определение "мгновенного" на твоём любимом и уважаемом гугл транслейте. Неудивительно, что русские доки такое говно - их переводят, советуясь гугл транслейтом, а не русским языком. Небось и ноду узлом называешь?
>И никакие говнокартинки этого факта не изменят.
Ну да, русский викисловарь это какая-то говнокартинка, то ли дело швитой гугл, который машинное обучение пользует для переводов (а значит никогда не сможет в синтетические языки).
Вдвойне приятно, что JS если откинуть ненужные this'ы вполне себе полноценный ФП язык (конечно, имею ввиду Тайпскрипт больше, писать без типов в 2020 даже иронично не смешно уже), уже успешно применяю некоторые практики на работе, в том числе пишу point free c помощью ramda в редьюсерах редакса кстати вголос проигрываю с местных обсуждений редакса и вьюкса, вы совсем долбоебы что ли не понимаете зачем нужен этот паттерн, зачем разделять экшны и редьюсеры и "добавлять код в 3 файла" чтобы сделать правку, если для вас это бойлерплейт и ваш проект просто фетчит списки с сервера, то земля вам пузом, редакс вообще не про это ало.
Советовался с сеньоромправда мое повышение на сеньора тоже не загорами, в этом году планируется весной/тимлидом/лучшим другом по совместительству, сказал что рамду одобряет, только конечно же большинство разрабов неосилит, поэтому нужно будет оставлять комменты, иметь типы @types/ramda напрягает немного, к сожалению в ТС нельзя выразить по-нормальному каррирование и некоторые функции по типу compose и обучать местных мидлов.
Кстати, работаю не с DOM, а canvas и в редьюсерах у нас таки довольно сложные вычисления, рамда идеально зашла, как и ФП подход в целом.
Подводные камни от знающих?
О ты то наверное и пояснишь за редакс. Смотри есть файл сервиса фетчаший запросы на сервак, запускаю его в экшн креаторе, диспатчу результат в стор, сам ЭК юзаю уже в компоненте, это норм практика? Долбени с ютуба за кой то хуй фетчат запросы прям из юзэфекта, это норм?
Да, так и задумано. Норм делать все что касается экшна в экшн криейторе, в том числе запросы на сервер, для этого thunk-actions и были придуманы, чтобы было удобно задиспатчить экшн, а внутри него произвести какой-то сайд эффект и задиспатчить в зависимости от результата. Пикрелейтед пример абстрактный.
Из юзефекта не норм, а полный пиздец, одна из причин почему современный реакт код скатывается в стену нечитаемого микса сайдэффектов, хуков, вычислений и JSX'а.
>>1900197
>>1900191
>>1900194
Ну что вы как шизики, нормально же общались.
>>1900189
>Ты ж почти сеньор какие нахуй советы?
И что если сеньор, я ж не один на проекте и не тимлид. Я спокойно мог бы и сам принять решение, но есть коллеги.
Касательно этого как раз наоборот, мутабельную лапшу разгребать одно дело спустя года, а чистенький ФП, где каждая функция делает что-то одно и написан как просто преобразования данных, другое дело.
Он не читал Дейкстру.
Который говорил, что профессионал никогда не будет писать clever код, потому, что он не может себе этого позволить, будучи профессионалом.
А потом на хедхантере можно увидеть экзотические вакансии, типа энтерпрайзного проекта на JRuby - очень clever, и совершенно non-maintenable. Потому, что просветлённый съебался, а для всех остальных - это бредятина и тёмный лес.
Валидный аргумент, ну тут собственно и дело в том, что правильный ФП код легко поддерживать. Но как легко говнокодит просветленный, так легко говнокодят и ООП-макаки с их "архитектурами" и "паттернами", которые проще потом просто нахуй переписать, чем рефакторить или поддерживать.
>>1900220
Если ты пишешь код, который идет в прод и про него забывают потом - да, так можно. Я работаю на проекте где поддерживаемость и читаемость кода в приоритете, т.к. долгосрочный продукт/фреймворк. Поэтому ФП идеально ложится в картину.
А то что макаки не способны писать ни хороший ООП, ни хороший ФП, это их проблемы и проблемы тех кто их нанимают.
>Подводные камни от знающих?
Если коротко, то дикий оверхед по ресурсам на поддержание иммутабельности. Особенно если ты там каждый фрейм что-то пересчитываешь на своем канвасе. Почитай вот, например:
https://tonsky.livejournal.com/322036.html
https://tonsky.livejournal.com/322450.html
бывший дрочер на рамду
> говнокодит просветленный
В том-то и дело, что речь не про говнокод, а совсем наоборот - слишком заумный (clever) код. Который пишут исключительно ради cleverness и чесания чсв, вот как >>1900185 излагает, примерно.
И который, кроме просветлённого, никому не понятен. И самому просветлённому он, спустя время, будет непонятен точно так же. Только он, при желании, ещё сможет размотать клубок, а остальные - нет.
И ФП для написания такого кода - очень благодатная среда.
И лиспы ещё.
Ну, и руби, разумеется, если кто-то ещё помнит, что такое руби.
О, наконец-то адекватный ответ. Про оверхед я, конечно же в курсе, мы не вызываем трансдьюсеры на каждый тик канваса. Тонкие места написаны как можно более лоу-лвльно. Ну и мы не обрабатываем тысячи элементов нигде, поэтому все довольно шустро работает.
>бывший дрочер на рамду
Мне кажется пути обратно быть не может.
>Ну, и руби, разумеется, если кто-то ещё помнит, что такое руби.
Веришь-нет, мой первый язык программирования был Руби и именно в нем я полюбил выразительность и чистоту кода, поэтому ФП естественное развитие событий.
И это нормально, рубисты рубистов поймут, как и ФП-господы ФП-господ. Никто же не лезет с ФП в Джаву пока что.
Ну не надо бросаться с одной крайности в другую, мне кажется ФП как минимум учит писать более организованный и безошибочный ООП код в том числе. Для среднего джсера главный урок который надо вынести это контролируемые сайд эффекты, а не то что нельзя использовать циклы и хуярить новые обьекты и массивы направо и налево.
Не то, что верю, я это знаю.
Ибо запах этого говна хуй отмоешь, и хуй парфюмерией забьёшь, лол. Как в том анекдоте.
Вообще, это известный факт, что рубибляди, как крысы с корабля, набежали в node и в js вообще, когда руби хайп закончился.
>выразительность и чистоту кода
Это вам так кажется, что оно чисто и выразительно.
Однако, на этот счёт есть и другие мнения.
Особенно, насчёт "чистоты".
>Никто же не лезет с ФП в Джаву
Пикрелейтед.
Эту книжку я купил 4 года назад.
Пойми, никто не говорит, что ФП - это плохо.
Наоборот, это хорошо, и изучение ФП делает тебя гораздо более лучшим программистом.
Но, в продакшн-коде на мейнстримных языках это надо использовать строго по месту, дозированно и с умом. А не просто потому, что тебе сегодня так нравится. Через полгода твои предпочтения изменятся, а кода, не читаемого без стакана, в прод ты уже нахуярил.
Легко читаются, если ты знаешь что абстракции обозначают.
pipe(
map(ages)
filter(eligibleToVote)
either(wasBornInCountry, wasNaturalized),
reduce(averageAgeReducer)
)(citizens)
Выразительно и легко читается? Да. Понятен ли полностью этот код, если программист не знает что такое map, filter, reduce и pipe и как работают функции в целом? Нет. По мне так даже не зная что функции делают, все равно очевидно по именам. Код читается как английский текст.
Изучив основы ФП выразительный код становится и легкочитаемым, потому что весь ФП основываеся на базовых функциях и абстракциях, котоыре ты соединяешь как тебе угодно для обработки данных.
В ООП безусловно тоже можно добиться похожего, если писать идеальный SOLID код и пользоваться паттернами. Только на практике мы видем километровые методы и лапшу из переменных, объектов, циклов, if else и т.д.
Дебил, то что ты написал делается также и в ООП коде. У тебя просто определения ООП и ФП уровня "ну ООП это там где объекты, а ФП это там где функции...". В этом и прелесть ООП - ты можешь объединять его с конструкциями, которые похожи на конструкции из ФП и получать идеальное сочетание. В то время как языки из ФП навязывают тебе городить лапшу лишь бы не оборачивать всё в объекты.
Обожаю такие объяснения, как на пике.
Хуита ни о чём.
И сразу понятно, что объясняющий - самовлюблённый пидар, а не профессионал.
>если ты знаешь что абстракции обозначают
Чувак, твой пример - это не фп, а детский сад.
Это просто value oriented programming и конвейер.
А критикуют в данной дискуссии совсем другие вещи.
>Вообще, это известный факт, что рубибляди, как крысы с корабля, набежали в node и в js вообще, когда руби хайп закончился.
Жиза, но я все еще считаю Руби лучшим языком для бекенда для стартапов. Рельсы слишком хороши и приятны, чтобы от них отказываться, и я полностью солидарен с DDD в плане что современные SPA и упор на клиентскую сторону это шиза.
>изучение ФП делает тебя гораздо более лучшим программистом
>Но, в продакшн-коде на мейнстримных языках это надо использовать строго по месту, дозированно и с умом. А не просто потому, что тебе сегодня так нравится. Через полгода твои предпочтения изменятся, а кода, не читаемого без стакана, в прод ты уже нахуярил.
Я абсолютно согласен с этим. Я и говорю, не стоит бросаться в крайности. Я замечаю за собой, что погружаюсь в просветление лол, но я так же не забываю, например, что мы работает с канвасом и что производительность > красивых композиций функций в тонких местах. И что другие программисты вынуждены будут 50 грамм наливать пытаясь прочитать мои элегантные пайпы в редьюсерах редакса.
>>1900385
>>1900387
Блять, вы шизики? Я просто пример привел рандомный.
>Это же самое пишется за 1 (один) цикл, выполняется быстрее, не дает вообще никакого оверхеда по памяти и удобнее типизируется.
И превращается в большой метод, который изменяет переменные и вместо того чтобы декларативно увидеть и понять код, я вынужден тратить полчаса чтобы разобраться что ты там натипизировал и нациклил. Знаю я эти циклы, дяди, не первый год работаю.
Возможно когда-нибудь я попаду в какой-нибудь ФП проект где нихуя не понятно, но пока что основы ФП выглядят намного приятнее чем обычный подход и УЖЕ улучшают кодовую базу на работе, мне этого более чем достаточно пока что.
>В этом и прелесть ООП - ты можешь объединять его с конструкциями, которые похожи на конструкции из ФП и получать идеальное сочетание.
Какой толк из этого сочетания, если ты все еще используешь обьекты, this'ы, инстансы и остальной мусор, который плодит ошибки? ФП языки именно поэтому и обязывают "городить лапшу", чтобы получить строгий инпут - аутпут.
>>1900388
>Чувак, твой пример - это не фп, а детский сад.
Так я сам только начал изучать месяц назад. Я тебе что, монады на монаде должен показать сейчас? Я сам хоть и понимаю, что они выразительные, не пойму сейчас такой код.
А эти "примитивные" вещи УЖЕ КАК МИНИМУМ делают дефолтную лапшу на JS намного приятнее и поддерживаемей.
>современные SPA и упор на клиентскую сторону это шиза
Да, говно.
Но, это не идеология, а способ увеличить throughput серверов для задач, ориентированных на широкие массы быдла - сотни тысяч и миллионы. Сервер выплюнул и забыл, а вся хуйня происходит на клиенте, где даже на сраной мобиле по цене доширака, уже 6-ти ядерный камень.
>Я тебе что, монады на монаде должен показать сейчас?
Монада - очень простой и полезный паттерн.
Если приглядеться - они повсюду. И ты их наверняка используешь.
Если есть проблемы с пониманием - посмотри вот это:
https://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html
>"примитивные" вещи
Я не имел в виду, что это плохо, примитивно или дёшево.
Наоборот - именно такие вещи (простые и понятные) и есть рациональное использование ФП в реальном промышленном коде.
>Если приглядеться - они повсюду. И ты их наверняка используешь.
>Если есть проблемы с пониманием - посмотри вот это:
Спасибо. Не то что бы есть проблемы с пониманием, просто был сосредоточен на более базовых вещах и практиковался + на работе пробую использовать где уместно. Теперь когда я легко читаю, пишу и понимаю partial applied функции (мне самое сложное было начать легко воспринимать это на лету) и осилил functional light JS книжку которая кстати мастхев как по мне любому JS разработчику, т.к. опять же она не просто показывает основы ФП, она в целом учит писать более качественный код и очень прагматична, буду переходить к более сложным концепциям.
Я как раз эту статью читал уже давненько, теперь интересней будет почитать с большим опытом.
>Наоборот - именно такие вещи (простые и понятные) и есть рациональное использование ФП в реальном промышленном коде.
А я о чем. Когда-нибудь я надеюсь я стану ФП-гуру чисто для себя, но я прекрасно понимаю что это далеко не серебрянная пуля в практическом применении. И я прекрасно понимаю почему большинство саркастически говорят о просветлении и почему многие плюются от ФП.
>И превращается в большой метод, который изменяет переменные и вместо того чтобы декларативно увидеть и понять код, я вынужден тратить полчаса чтобы разобраться что ты там натипизировал и нациклил. Знаю я эти циклы, дяди, не первый год работаю.
let averageAge = 0;
citizens.forEach(citizen => {
if (eligibleToVote(citizen) && (wasBornInCountry(citizen) || wasNaturalized(citizen))
averageAge += citizen.age / citizens.length;
})
Ух ебать огромный сложный код, пиздос какие страншные мутации, меньше чем за полчаса точно не разобраться. Надо рамду тянуть, иначе никак!
>functional light JS
Посмотри книгу JavaScript Allonge.
Это очень годная книга по ФП на ЖС.
Она есть в двух версиях - для ES5 и ES6.
Для ES6 - бесплатная:
(там надо поставить цену 0)
https://leanpub.com/javascriptallongesix
У тебя уже как минимум 1 левая переменная, пиздецкое условие в if и оверхед вычисления age. Есть ли выигрыш здесь от ФП? Практически нет. Но когда реальный код сложнее раза в два хотя бы и подобного кода 30 файлов с "классами" и "методами", которые делают this.averageAge и подобное, тогда дело и выходит из под контроля. К тому же, это ты написал так этот код. А другой разработчик напишет через for ... of, а третий вообще eligibleToVote напишет как citizen.age >= 18. И когда вот подобных различий становится десятки, а кода на тысячи строк, тогда наступает и пиздец.
Да, сломается от перегрузки. Мне нужно для каждого подобного случая смотреть что где меняется, потому что БАЗОВЫЕ абстракции каждый раз заново пишутся императивно. Опять же, если у тебя 3 функции подобных, вообще похуй как ты их напишешь. Но проблемы неизбежно возникают в средне-больших проектах при подобном подходе. И если тебе ни разу не приходилось разгребать подобные &&, || и let iWillBeMutated10times = 0, то могу лишь порадоваться за тебя.
У for...of так себе перформанс во всех браузерах кроме Хрома. Но я согласен, что он идиоматичнее.
>>1900466
>1 левая переменная
Нет таких
>пиздецкое условие в if
Чего? По-твоему два фильтра по всему массиву с использованием левых либ, а не встроенного в JS синтаксиса это лучше что ли?
>оверхед вычисления age
От деления-то? Интересно посмотреть на содержание твоего reduce без оверхеда.
>А другой разработчик напишет через for ... of, а третий вообще eligibleToVote напишет как citizen.age >= 18. И когда вот подобных различий становится десятки, а кода на тысячи строк, тогда наступает и пиздец.
Охуеть аргумент. А на ФП только один способом написать можно по-твоему? Я тебе ровно то же самое и про твой код сказать могу — вот будут у вас сложные ветки из десятков функций в пайпе и тогда-то пиздец и наступит бу-бу-бу. Алсо, у вас там код-ревью не изобрели еще?
Это твои выдумки и переворачивание терминов.
Когда ты пишешь map(age) ты говоришь отразить каждый элемент коллекции во что-то.
Ровно так же, как когда ты пишешь for..of ты говришь что сделать с каждым элементом коллекции.
Противопоставляя декларативность императивности все нормальные люди говорят об описании либо готового результата (что-то вот что-то отражено), либо об описании процесса (что-то во что-то отразить).
>or циклом ты указываешь пошагово
А ты ты не пошагово указываешь?
pipe(
map(ages)
filter(eligibleToVote)
either(wasBornInCountry, wasNaturalized),
reduce(averageAgeReducer)
)(citizens)
>map ты указываешь (декларируешь) что ты получаешь
Нет, ты не описал, что ты получаешь. Ты описал, что сделать.
Нет, он прав.
Императив - описание того, как получить результат.
Декларатив - описание того, что нужно получить.
Реализация же ("как") упрятана в стандартные библиотечные функции.
Но, важнее другое.
В ФП-подходе идёт трансформация _значений_. А в императивном - последовательность _команд_. Ты не можешь прервать последовательность команд и потом продолжить её в другом месте.
Но, можешь в любом месте разорвать цепочку ФП-преобразований, и продолжить потом, в другом месте, просто взяв промежуточное значение и передав его куда-то.
>>1900528
>>1900527
Вы только посмотрите на этих мамкиных специалистов по декларативности, советую быстро звонить в международный консорциум по функциональщине, ведь мы только что доказали что map(fn) это не декларативный код.
>>1900537
В pipe ты не указываешь что делать, а декларируешь чем это является. Буквально говоришь, что cредний возраст это композиция из отфильтрованных родившися в стране, которым разрешено голосовать и у которых возраст достаточный.
В императивном коде же, ты описываешь КАК ты проходишься по циклу, ПРИСВАЕВАЕШЬ счетчик i, СУММИРУЕШЬ в переменную averageAge и так дальше.
В декларативном коде детали реализации скрыты за абстракцией, в императивном нет.
Банальный пример:
// Императивно проходимся в цикле и пушим в массив
const ages = [];
for (let i = 0; i < citizens.length; i += 1) {
ages.push(citizens.age);
}
// Декларативно заявляем что возраста это мап свойства 'age' граждан
const ages = map(prop('age'));
const citizensAges = ages(citizens);
Именно так!
>Реализация же ("как") упрятана в стандартные библиотечные функции.
И самое главное, эта реализация каждой функции отточена и работает предсказуемо.
Когда я вижу map(prop('age') я знаю что я получу в итоге.
Когда я вижу for... я вынужден лезть во внутрь, потому что каждый разработчик засунет внутрь абсолютно что угодно. Пуш в массивы, присваивания в переменные, возможный выход из цикла и т.д.
Добавлю:
Например, попробуй рассмотреть асинхронные операции - колбек (императив) vs промис (фп, монада).
Ты можешь делать с промисом всё то, что ты можешь делать, например, со строкой или числом. Например, подвергнуть его цепочке преобразований. Но, ты не можешь так же поступать в коде, сделанном на колбеках.
для ДОМа это использовать -> jsdom?
Поправил тебя
const isVoter = (citizen) =>
__eligibleToVote(citizen) &&
__(wasBornInCountry(citizen) || wasNaturalized(citizen));
const voters = citizens.filter(isVoter);
const votersAgeSum = voters.reduce(
__(averageAge, voter) => averageAge + voter.age,
__0
);
const arerageVoterAge = votersAgeSum / citizens.length;
unknown[]?
Для этого тебе придётся написать дополнительный код, сохранить кучу вещей куда-то, и т.п. Это будет уже _другой_ код. Причём - каждый раз разный, в зависимости от. В value oriented - всё и так уже значения, никакого дополнительного состояния нет - всё в аргументах функций. Просто подключаешь-отключаешь-переключаешь.
Вообще, вместо того, чтобы лезть в залупу и выставлять себя дураком, лучше попробуй понять, о чём идёт речь. Это, естественно, потребует времени и усилий. Но, старание будет вознаграждено, будь уверен.
дай ссылочку на список методов плз))querySelector нихуя не работает)
>let citizensAges = []
>for(let {age} of citizens) citizensAges.push(age)
И? Типичная императивная шляпа с обьявлением 2х переменных и мутацией массива. И это лишь примитивный пример. Суть не в количестве строчек кода, а в том как ты выражаешь код.
>>1900617
Вот это уже намного лучше. Не 100% ФП, но по крайней мере код читаемый.
>>1900631
>Добавил в мой код лишних переменных, лишних проходов по массиву, немного оверхеда по памяти
Экономия на спичках и наносекундах. Читаемость кода и легкость правки в 10 раз важнее.
> и ошибку в вычислении среднего?
Все правильно там написано.
>>1900627
Функцию, которая "ждет" массив из объектов со свойством age.
const ages = map(prop('age')); // objects => map(prop('age'), objects)
const citizens = [
{ name: "Victor", age: 21 },
{ name: "Daniel", age: 33 },
{ name: "Ellie", age: 19 }
];
ages(citizens); // [21, 33, 19]
Та я сыглы, дело вкуса, зависит от проекта и разрабов. Но то как ты написал это УЖЕ на 3 головы выше лапши которую я частенько вижу и это даже не обязательно должно рассматриваться как ФП, это просто написание более чистого и читаемого кода. Как я и говорил, я бы советовал всем JS разрабам почитать functional light JS.
>Ты не можешь прервать последовательность команд и потом продолжить её в другом месте.
В обычном цикле вполне можно контроллировать течение цикла, в отличие от всяких методов массивов, где приходится костылить километровый колбэк для какого-нибудь `forEach()`, если количество элементов в массиве меняется во время исполнения.
>>1900581
>И самое главное, эта реализация каждой функции отточена и работает предсказуемо.
Пока ты только в примерах хэлловорлды приводишь, ФП быстро скатывается в неперевариваемую кашу, особенно когда мамкин ФПшник пихает анонимки заместо колбэка. Там так же будешь смотреть, не хуйнул ли Вася сайдэффект и откуда вообще переменные берёт, только это дело будет скрыто в простыне редюсера, у которого километровый колбэк идёт перед аккумулятором.
>>1900628
>Для этого тебе придётся написать дополнительный код, сохранить кучу вещей куда-то, и т.п.
Ну а в ФП коде конечно же вообще ничего не нужно писать и всё само сохраняется.
>>1900640
Пиздец, вы не видите ошибку даже когда я на нее явно указал? А где же прозрачность и читаемость фунционального стиля? Там идет деление на число всех граждан, а должно быть только на голосующих.
Алсо, это код (в отличие от моего, опять же) крашнется при передаче пустого массива из-за деления на ноль.
>А где же прозрачность и читаемость фунционального стиля?
на месте
>Там идет деление на число всех граждан, а должно быть только на голосующих
опечатался офк. Ты тоже скобку пропустил
>>1900655
>Алсо, это код (в отличие от моего, опять же) крашнется при передаче пустого массива из-за деления на ноль.
+ || 0
>Ну а в ФП коде конечно же вообще ничего не нужно писать и всё само сохраняется.
Ты даже не пытаешься понять, о чём тебе говорят.
В теме не ориентируешься совершенно.
Но, пишешь простыни поучающим тоном, и рассказываешь, как оно на самом деле.
Даннинг-Крюгер в чистом виде.
>>1900647
А, извини, я не понял, что речь именно про JSDOM.
Не знаю, не работал с ним.
Погуглил - да, там какая-то залупа с querySelector, углубляться не стал.
с каким домом работал?
какой editor с автокомплитом используешь? (sublime text с плагином не очень, vs code лагает)
посоветуй годный гайд
Например, так:
function( x, y ) {
x = 4
...
}
По-моему, этот "плохой паттерн" высосан из пальца.
А если бы я сделал деструктуризацию с переименованием типа такого?
function({ $: value, delta }) {
value = value + delta;
}
Ну т. е. я передаю в функцию 5, а она у меня заменяется на 4, потом что-то работает не так как ожидалось, я дебажу с осознанием того, что передаю 5, но нахожу баг только когда дохожу до исходного кода функции в которой долбоеб зачем то меняет передаваемый аргумент на 4, а не 5.
Поэтому это и плохой паттерн. Если ты заменяешь аргумент функции, значит нужно как минимум уведомить об этом того кто этот аргумент передаёт.
Толсто — это приходить в JS тред, изображая незнание самых азов программирования.
P.S. По поводу моего изначального вопроса, единственный реальный аргумент против переопределения параметров — это мутация объекта arguments. Но кто вообще юзает эту глючную депрекейтед херню в 2021?
Дурик, у тебя мутация аргумента происходит, этого уже достатчно для того чтобы твой говнокод стал еще хуже, хотя бы потому, что для того чтобы изменить любую функцию написанную тобой, нужно сначала проверить не захуячил ли ты там где-нибудь в середине какой-нибудь цикл который у тебя вертит на хую аргумент функции.
Во-первых, если переменная лишняя, то её не будет в итоговом коде благодаря оптимизациям компилятора. Во-вторых, зачем ты игнорируешь то что тебе говорят, в частности пример ситуации когда тебе нужно внести изменения в существующий код?
Тебя если не интересует ответ на твой вопрос, то ты сразу так и пиши - моя идея охуенная и мне похуй на опыт моих предшественников.
>Если ты заменяешь аргумент функции, значит нужно как минимум уведомить об этом того кто этот аргумент передаёт.
Что ты несешь, шизоид? Если ты не мутируешь переданный объект/массив, то на переопределение переменных внутри функции похуй абсолютно, вызывающему от этого ни тепло ни холодно, ему важно только чтобы функция сделала что должна.
>важно только чтобы функция сделала что должна.
Функция должна складывать 2 числа. Я передаю в неё два массива. Функция возвращает мне результат сложения двух единиц. Почему? Потому что важно чтобы функция сделала что должна.
В общем, поссал тебе на голову, выскочка тупорылая.
как сделать чтобы нода видела глобальные модули?
Надо понимание кучи вещей, на самом деле.
Нужно бегло разбираться в JS, CSS и HTML, иметь общее представление о клиент-серверном взаимодействии, потом скурить десяток-другой мануалов по ноде. Через полгода, когда от объёма информации перестанет кружиться голова, можно сесть и сделать мультиплеерные крестики-нолики за пару часов.
как использовать jquery в скрипте? require(jquery) не работает
есть html страница ИЗ ФАЙЛА, как использовать на неё jquery без всяких иньекций?
>>1901109
>>1901108
Вы так троллите, да?
>>1901119
>>1901114
Задача поставлена четко и ясно, взять динамическую страницу паппетиром, парсить jquery что непонятного.
сделал костылем с jsdom
const { JSDOM } = require( "jsdom" );
const { window } = new JSDOM( "" );
const $ = require( "jquery" )( window );
const puppeteer = require('puppeteer')
вариант н2
await page.addScriptTag({url: 'https://code.jquery.com/jquery-3.2.1.min.js'});
Больше не гуглится
Если ты не троллишь, то, тебе надо научиться связно излагать свои мысли.
Потому, что если ты даже этого не можешь, то, как ты сможешь написать программу?
Что такое "динамическая страница"?
Где её нужно взять?
И т.д. И т.п.
Если же ты троллишь, то тебе просто надо сходить на хуй.
Это, обычно, помогает.
Похоже, тебя больше устраивает опция 2 из поста >>1901134
Я правильно понял?
Потому, что иначе непонятно, зачем ты ебёшь тут мозги.
Но, хуй с тобой, давай покормлю:
- Тебе надо настроить node как веб сервер, для отдачи статического конента. Или использовать другой веб сервер.
- Положить туда свой html.
- Добиться того, чтобы он открывался оттуда браузером.
- Использовать куклоёба кукловода вместо браузера. Как это сделать - почитать в гугле.
У каждой записи есть собственно время записи - промежуток между начальным временем и конечным, то есть начальное время(то на которое клиент назначил запись) + время на одного клиента + время на отдых.
Апиха позволяет создать запись с выбранным парикмахером, если время записи входит в промежуток рабочего времени, и не пересекается по времени с другими записями, то все ок.
Появилась потребность отфильтровать парикмахеров по фильтру "свободен сегодня". То есть взять каждого парикмахера, посмотреть его записи, и если есть время еще хотя бы для одной записи, то пометить этого парикмахера как "свободен сегодня".
Но как перебрать все записи?
То есть надо как-то по порядку взять промежутки для каждой записи в виде "конечное время предыдущей записи - начальное время следующей записи" и вернуть парикмахера, у которого хотя бы один промежуток может вместить время новой записи - промежуток между начальным временем и конечным.
Использую библиотеку Luxon, там промежутки очень легко сравнивать методом Inetrval().contains()
Но как это сделать с помощью цикла для каждой записи у всех парикмахеров?
Отсортируй список, сделай как нибудь pairwise чтобы из [A,B,C] получилось [(A,B), (B,C)], потом мапишь в {endFirst, startSecond}, потом фильтруешь по duration >= X
Или напиши функцию, которая пилит один интервал другим, а потом appointments.reduce((freeIntervals, a) => freeIntervals.flatMap(x => split(x, a)), [worktimeInterval])
Если ты собрался парикмахеров и их записи руками перебирать и тебе абсолютно похуй на перформанс, то это просто sort на массиве с записями и потом проход по этому массиву с ужасным мутабельным прерываемым циклом, который будет проверять промежуток между концом предыдущей записи и началом следующей на наличие свободного окна, строчек в 10 чистого, читабельного и быстрого жопоскрипта уложишься, в отличие от функционального шизика >>1901200
Если же ты хочешь сделать нормально, через один запрос к своей реляционной БД, то без хеви рефакторинга не обойтись, надо менять таблицу записей на таблицу "рабочее время", которая будет включать в себя и записи, и свободное время(которое тебе так же придется добавлять каждом парикмахеру на каждый рабочий день, менять при добавлении записи и т.д).
Это не вычисляемые поля, это структура рабочего дня, которая может меняться как угодно в течение каждого отдельно взятого дня(отменили запись, добавили запись, время освободилось, рабочий день короче из-за выходных, и т.д), и каждое из этих изменений должно отображаться и учитываться при поиске. Как ты собрался это делать, кроме как руками и в БД?
Свободное время - это интервалы рабочего времени без записей, считается где угодно, как в бд, так и не в бд.
Рабочее время на каждый день хранить тоже пушка, рабочее время на конкретный день считается из расписания (рабочие дни, 2 через 2 и т.д.) плюс всякие ограничения типа производственного календаря, больничных, отпусков и отгулов.
Хранить надо то что накликал пользователь - записи, и то накликал хозяин - расписание.
Если хочется пооптимизировать - вьюшечки и кэшики, а не усложнять все остальные операции ради ускорения обной
Анонасы, как написать функцию
>new Xyeta().add(1, 2, 3).add(11).add(12).add(55555)
add может складывать все это в массив, не суть важно.
>рабочее время на конкретный день считается из расписания
Необязательно, расписание не всегда фиксированное и может меняться для каждого работника(ушел раньше, пришел позже), плюс изначально задача стоит как "найти всех работников, у которых в выбранный день есть свободный интервал рабочего времени в n часов". Как ты собрался это делать одним запросом(подразумеваем sql-базу), без перебора каждого работника вручную, если все, что у тебя в базе есть - это записи клиентов, я представить не могу.
Не оберегает, это как прикладывать подорожник к перелому. Если у тебя нет правильного метода написания и валидации кода TDD, то хоть типизируй, хоть не типизируй, баги, рантайм ошибки и прочее-прочее будет без вариантов. А если правильный метод есть, то типизация отпадает за ненадобностью.
Ох уж эти "крупные проекты", возможные только на типизированных языках. На руби и питоне-то отродясь ничего крупного не писали, а если писали, то сразу умирали в агонии потому что типов нет и поддерживать нельзя только джава, сисярп и их брат-имбецил тайпскрипт.
Вопрос, можно ли получить как-то высоту и ширину изображений?
Не произвольными. Жит умеет оптимизировать функции до 4 разных типов входящих параметров. Если тип вообще не меняется, то функция мономорфна и оптимизируется на раз.
Проседание в скорости вовсе не поэтому, а потому что алгоритм прямого доступа к полю, вызова метода и геттера сильно различен.
Страницы теперь будут загружаться моментально?
Простой пример: у мечников есть способность контратаковать врага, если враг промахнулся. Если раскачать уворот двум мечникам до небес, и направить одного на другого, они будут махаться до бесконечности, и ход никогда не завершится.
Можно, конечно, поставить кап на максимальный уворот и так далее, но это всё полумеры, и при разрастании проекта такие зацикливания будут неизбежны.
Хотелось бы придумать какое-нибудь архитектурное решение.
Да я там явно переборщил с гибкостью. С мечниками ещё относительно простой пример. А что, если у игрока есть артефакт, который повышает атаку всем существам со защитой меньше X, и есть существо, чья защита повышается пропорционально его атаке.
Всё, бесконечная гонка обсерверов.
Это действительно больше вопрос геймдизайна.
1) Ввести две "мировые константы" в игре: коэфициент затухания ε воздействия и порог срабатывания воздействия F.
2) В кажом событии передовать параметр А - силу воздействия
3) Событие распостряняется на следующий объект с силой М = ε * A
4) Если М < F то собыите не срабатывает и не распостраняется дальше.
>А что, если у игрока есть артефакт, который повышает атаку всем существам со защитой меньше X, и есть существо, чья защита повышается пропорционально его атаке.
И схуев ли тут бесконечная рекурсия? Даже если ты накриворучил, что у тебя артефакт какого-то хуя бафает существ при каждом изменении их защиты, а не работает как аура или одноразовый бафф, то он все равно должен останавливаться, когда защита превышает X.
>>1901954
Охуенно наверное переизобретать stack depth limit, да еще и вставлять его прямо в механику игры, потому что не смог поправить бесконечную рекурсию, 10/10 идея.
Артефакт следит за защитой существ, и когда она меньше 10, даёт существу +5 атаки.
Существо изначально обладает атакой 7 и способностью "защита этого существа всегда равна его атаке".
Артефакт повышает атаку --> Существо повышает защиту --> Артефакт убирает повышение атаки --> Существо понижает защиту --> начинай сначала
Разберу на примере атаки/защиты (опять же, как оно в MTG). Там порядок такой:
1. Изначальная атака/защита
2. Эффекты, которые устанавливают атаку/защиту в конкретное значение
3. Эффекты, которые добавляют или удаляют атаку/защиту
4. Эффекты, которые меняют атаку и защиту местами
>Артефакт следит за защитой существ, и когда она меньше 10, даёт существу +5 атаки.
>Существо изначально обладает атакой 7 и способностью "защита этого существа всегда равна его атаке".
1. Изначальная атака 7
2. Установлена защита 7
3. Атака модифицирована до 12
4. ...
Итого — существо 12/7.
Ну а дальше уже меняй систему как тебе надо.
>1. Изначальная атака 7
>2. Установлена защита 7
>3. Атака модифицирована до 12
>4. ...
>
>Итого — существо 12/7.
Какая-то фигня. Если я напою существо эликсиром на +10 атаки, то защита у него тоже не возрастёт, и мне придётся долго растолковывать игрокам, почему так получилось.
>Какая-то фигня. Если я напою существо эликсиром на +10 атаки, то защита у него тоже не возрастёт, и мне придётся долго растолковывать игрокам, почему так получилось.
Блэт, я же тебе написал, что это только принцип. Ты можешь поменять слои 2 и 3 местами. Или придумывать менее всратые абилки, которые не взрывают мозг игроками и взаимодействуют более очевидным образом.
У меня сейчас вот сервер тупо встал: ошибок в консоли нет, процесс запущен, при этом сервер не реагирует на запросы, будто ушёл в бесконечный цикл.
ПЕРЕКАТ >>1902322 (OP)
ПЕРЕКАТ >>1902322 (OP)
ПЕРЕКАТ >>1902322 (OP)
ПЕРЕКАТ >>1902322 (OP)
ПЕРЕКАТ >>1902322 (OP)
ПЕРЕКАТ >>1902322 (OP)
ПЕРЕКАТ >>1902322 (OP)
Мне пришла в голову дерзкая идея, как всё упростить.
Что, если показывать игрокам не актуальные статы существ, а статы на момент последнего вычисления? Учитывая, что вычисление статов на сервере происходит по требованию, получается простая логика: игрок не знает урон существа, пока это существо никого не ударило. Игрок не знает броню существа, пока это существо не получило удар. И так далее.
Это снимает целый пласт проблем с поддержанием кучи параметров в актуальном состоянии, а также добавляет в игру элемент эксплора, кек.