24 декабря Архивач восстановлен после серьёзной аварии. К сожалению, значительная часть сохранённых изображений и видео была потеряна. Подробности случившегося. Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!
Если рассчитываешь получить дельный ответ, сформулируй правильно вопрос: «что я хочу получить, что я для этого делаю, что я вместо этого получаю». Если когда самостоятельно найдёшь решение — поделись в треде, мы за тебя переживаем.
>>1950945 А как тогда синглтон делается? Я думал, что синглтон - это просто единственный экземпляр какого-то класса. По крайней мере так в примерах Википедии или где-то ещё видел.
>>1950945 >>1950972 А, перечитал Вики, короче синглтон должен запрещать создание новых экземпляров, возвращая самого себя в случае попытки пересоздания. Ну, это всё мне не важно, меня интересовал только синтаксис.
>>1950940 Мне синтаксис тут не нравится, через class удобнее. Тем более что можно использовать наследование (extends) и есть конструктор...
>>1950978 В зависимости от ситуации. Если у тебя есть набор логически связанных действий и данных, служащих одной конкретной цели, то удобнее и красивее будет объявить хорошо названный класс с продуманным интерфейсом, чем дрочиться с обычным объектом-хэшмапой. Если же ты просто хочешь запихать что-то в одно место, мержить это что-то с другим чем-то, убирать оттуда куски и т.д, то удобнее будет просто сделать объект, чем дрочиться с конструкторами и this.
>>1950979 >дрочиться с this Эээ... я уже обдрочился этим this, есть способ обращаться к полям/методам класса без обязательного указания this? В других ЯП я никогда не встречал такого частого обращения к this/self (пытаясь убрать this, консоль срёт сообщениями "ололо не найдено").
>>1950986 >не встречал такого частого обращения к this/self В php погляди на любой класс, он на половину состоит из $this-> или python, там тоже кругом одни self в классах. В других языках просто поведение this более предсказуемо, чем в js
>>1950987 Ладно. А локально сокращать код как-нибудь можно? Вот у меня часто бывает что-то вроде такого: >for (let i in this.parent.items) >if (this.parent.items[ i ] !== this) >this.parent.items[ i ].close(); В некоторых языках есть оператор with, можно ли сделать так: >with (this.parent) >for (let i in items) >if (items[ i ] !== this) >items[ i ].close(); ? А то конструкции уж больно монструозные получаются. Предполагаю, можно сделать так: >const p = this.parent; >for (let i in p.items) >if (p.items[ i ] !== this) >p.items[ i ].close(); Т.к. parent - объект, то в p копируется только ссылка. Но не сильно ли такой способ "сокращения" загружает JS-машину?
>>1951000 >Но не сильно ли такой способ "сокращения" загружает JS-машину? Ты рофлишь? Если только у тебя на 1 миллион таких объектов, вообще нет смысла делать эти микрооптимизации. То же касается циклов, нахуя тебе for если есть forEach, map, reduce.
>>1951014 Я знаю только что интерпретаторы медленные и сайты с обилием JS на моём компе/телефонах часто тормозят, NoScript их ускоряет. Не хочу идти по чужим граблям и нагружать интерпретатор мусором.
>если есть forEach, map, reduce Слышал о таком, никогда не использовал, надо погуглить.
>>1951015 Я привык всё вручную делать, императивно. ФП вообще боюсь, тёмный лес. А это делается только для удобства программиста или filter() и forEach() будут быстрее одного for с if'ми? Просто как по мне, for и if читабельнее, ближе к тому, как я представляю решение задачи. Я читаю это примерно так: "для каждого i в items, если items не этот объект, то закрыть его". А твоя запись хоть и понятна, но не читается, что-то вроде "фильтровать items, убрав этот объект, затем каждый закрыть"? Мастера Йоды получается код)
>>1951021 Это вообще непонятно, это ФП или что-то новое? Как гуглить? >>1951025 Согласен.
>>1951037 >Не хочу идти по чужим граблям и нагружать интерпретатор мусором. Это как говорить что не хочу портить океан и ссать в него. Нужно нагрузить очень много джаваскрипта в память, чтобы вызвать тормоза хоть на пару миллисекунд на уровне языка. 99% тормозов в веб-приложениях из-за DOM, то есть обновления самой страницы и ререндеринга, а не из-за вычислений переменных в JS'е. В примере выше
Мы делаем 2 цикла, вместо одного, как в императивном подходе, но это не имеет никакого значения пока у тебя в массивах меньше 10к элементов.
>>1951037 >Я привык всё вручную делать, императивно. ФП вообще боюсь, тёмный лес. Ну тогда тебе будет тяжело найти работу, т.к. на фронте сейчас ФП подходы более приветствуются, т.к. читаемость и расширяемость кода это одна из главных характеристик хорошего кода, а не пикосекунды исполнения. Вызывание функций намного более читабельнее и реюзабельней, чем портянки из if и for. Конечно, в твоем примере разницы никакой нет, но добавь туда еще 1-2 проверки и еще одно действие которое надо будет выполнить над items (а это зачастую и нужно сделать в реальных проектах рано или поздно) и ты уже получаешь лапшу:
>for (let i in this.parent.items) >if (this.parent.items[ i ] !== this && this.parent.items.isOpened) >this.parent.items[ i ].close(); >if (this.parent.items.hasSomething) >this.parent.items.doSomething();
Это нечитабельный и очень императивный код в своей основе. Конечно, он кажется читаемым потому что ты написал его 5 минут назад и ТЫ написал его. Но для других программистов нужно прикладывать когнитивные усилия, чтобы осмыслить цикла, доступа к объекту, проверке !== и вызове метода. В подобном коде легко сделать ошибку.
В функциональном подходе из-за того что код разделен на мелкие, но хорошо делающие свои работу функции, код очень легко расширять, менять и читать. Циклы, проверки и другие частые операции уже вынесены в функции и тебе не нужно переживать что кто-то где-то скипнул часть цикла или поменял элемент внутри массива по ошибке.
Но, безусловно, есть некий порог входа и в самом начале изучения ФП код кажется более СЛОЖНО читаемым. Но через некоторое время практики ты будешь удивляться, как теперь весь код для тебя это процесс вычислений значений и будет сложно писать в императивном стиле (потому что на него нужно тратить больше усилий).
В любом случае, не обязательно нырять в функциональный подход на 100, более того зачастую это невозможно, потому что код над которым ты работаешь это легаси от прошлых разрабов или команда в которой ты работаешь слабая по скиллу и может только хреначить портянки на jQuery сам начинал с подобного.
В твоем случае forEach и filter предпочитаемы итеративному обходу и проверке, просто небольшой совет.
>>1951076 А чем по-твоему школьники отличаются о не-школьников? Хочешь чтобы коров с собачками считали и картинки красивые? Бери обычные курсы и не выебывайся.
Нормальная ли это практика делать один эвент листенер на ресайз окна в сторе, и потом передавать его во все необходимые компоненты? Есть много разных компонентов, и в каждом из них отдельно вешается эвентлистенер, и потом применяются стили в зависимости от размеров. Если я просто в сторе этот эвентлистенер повешу это нормально? Какие могут быть недостатки у такого подхода?
>>1951207 Окей, переформулирую. Хорошо, представь себе список, где каждый шаг описан в декларативном стиле. Вот это то, что позволяет тебе саги. >>1951202 Я сравнил разные стейт-менеджеры и не нашёл ничего такого, что побудило бы меня начать юзать другой STM. redux-saga - до сих пор лучшее, что есть для асинк флоу логики.
>>1951233 То что ты выше перечислил выглядит естественным.
Неестественным это становится, когда ты смотришь на какой-то код и не понимаешь, что он означает, потому что он написан таким образом, что зависит от многих других частей.
Задача программиста - выразить сложный флоу естественным образом, чтобы он читался как рецепт, а не мешанина хуй знает чего.
Охладите естественное траханье в этом треде на минутку и задекларируйте тут ваше видение идеальной модульной архитектуры на жс. И как бы вы распиливали бы на модули огромное монолитное приложение, которое становится уже сложно поддерживать и которое собирается целую вечность.
>>1951206 Так. У меня другая проблема. Я повесил эвент листенер. И он нормально передает значение в компоненты при ресайзе. Но вот в чем дело, мне нужно как-то считать initial размер окна еще до любого ресайза. Я бы мог просто присвоить начальное значение из текущего размера окна winWidth = windows.innerWidth. Но вот очевидно что ssr такое не понравится. И я не знаю как обратно к серверу передать значение из клиента. Чтобы на сервере тоже размер окна брался сразу с клиента, потому что если использовать всякие юзэффекты, то стили будут прыгать, потому что изначально значение будет браться из стора. В какую сторону гуглить?
>>1951277 Один раз об такое уже споткнулся. Оказалось, что крайне неудобно бегать с репозитория туда-сюда, когда фактическая зависимость между кодом в разных репах осталась высокая. Многие изменения требовали вносить правки сразу в несколько репов, что оказалось просто болью.
Это, впрочем, не проблема разделения на отдельные репозитории, а проблема, что огромный монолит распилить красиво, что бы потом все было удобно и без зависимости друг от друга, действительно сложно. В итоге тот проект вернулся в один реп, но был поделен на несколько кусков которые могли собираться независимо друг от друга.
Ладно, а что вы делает (идеально в контексте ts, но вообще не столь важно) с огромными классами в js? Extend? Mixins? Subclasses? Можно еще часть логики выделить во внешнею и пихать как DI.
useEffect вызывается как только компонент отрендерился, но в нем же делают запросы к api, без запроса к api нахуй рендерить компонент если в нем еще нет нужных данных?
>>1951056 >из-за DOM, то есть обновления самой страницы и ререндеринга Кстати, как это правильно делать, если нужно вывести (div.append()) сразу много элементов?
>это не имеет никакого значения пока у тебя в массивах меньше 10к элементов Я обычно программирую как привык. И если привыкну к неоптимальному подходу, буду использовать его всегда, а потом тратить время на поиск узких мест. Зачем писать неоптимально, если более быстрый вариант пишется нетрудно? Я же не ассемблерные вставки пишу. А то здесь два цикла, там два цикла, так и накопится снежный ком лишних действий, а потом поди разберись в нём.
>найти работу Так а я и не ищу) Для работы нужно иметь кучу других качеств и навыков, кроме программирования на уровне любителя. Я пишу программы для своих задач и удовольствия, остальное меня не интересует.
>читаемость и расширяемость Знаю и понимаю. Но функции - это не уникальная черта ФП. Портянку из for и if я дроблю на субфункции, когда становится непонятно, что происходит. И эти субфункции я могу назвать в соответствии с контекстом, не полагаясь на стандартное название из какой-то библиотеки.
>получаешь лапшу Лапша - это когда в коде много связей между случайными участками, т.е. из многих мест идут обращения во многие места, из-за чего становится трудно понять, что на что влияет и как оно вообще работает. А длинный код не обязательно "лапша", его обычно можно разделить на отдельные функции, передавая результат от одной к другой.
Твой пример можно переписать читабельнее, но, во-первых, данными управлять должен сам элемент. Если данные нужно сохранить перед закрытием, то проверка и сохранение данных происходят в методе item.close(), а не в item.closeSiblings(), следовательно код упрощается. Во-вторых, проверка открытости элемента производится опять же самим элементом в методе item.close(), потому что наше дело предложить ему закрыться, а ему решать, может ли он закрыться. Тогда будет только: >for (let i in this.parent.items) if (this.parent.items[ i ] !== this) this.parent.items[ i ].close(); А вот уже в close() будет что-то вроде: >if (this.opened) { this.saveData(); this.toogle(); } В saveData(): >if (this.needToSave) { ... }
...ну, ладно, один .forEach тут бы не повредил, типа >this.parent.items.forEach(item => { if (item !== this) item.close() }); Но смысла в .filter() здесь не вижу. Фильтр был бы полезен, если бы мы потом с этим списком что-то сложное делали, т.е. сохраняли отдельно и редактировали...
А вообще я не пойму, в чём тут ФП? Это же императивные команды "сделай это", даже порядок соблюдается слева направо, а не наоборот. Против такого кода ничего не имею, пока названия функций имеют смысл (forEach = для каждого, в данном контексте нормально). Но большая часть виденного мной функционального кода читаемых имён не содержит (зато куча спецсимволов).
>код поделён на мелкие функции Так и мой код тоже поделён на мелкие (по возможности) функции. Только у моих функций название есть и соответствует контексту/области видимости, а в функциональщине названий либо нет, либо они из спецсимволов и скобок.
Тот же цикл forEach, по-хорошему, часть императивного кода: >for item in items do if item <> self then item.close(); Вот это максимально читаемый код, читается как русский язык: >для каждого итема в итемс проверяем что это не мы и закрываем соседей А если оборачивать в скобки и спецсимволы, получается нечитабельная фигня.
Вообще я фанат алгол-подобных языков, хочу обмазываться длинными словами из букв и не хочу контактировать со спецсимволами. Увы, в вебе есть только JS, но я уже не против, тут не так много спецсимволов, как во всяких сях.
>>1951233 Декларативные языки вообще несравнимы с императивными и имеют свою нишу, в которой императивные просто не нужны (пример - html).
Твой императивный пример: - выйти на улицу: - - одеться: - - - снять домашнюю одежду - - - надеть нижнее бельё - - - надеть верхнюю одежду - - обуться: - - - надеть ботинки - - - зашнуровать ботинки - - надеть шапку Он чётко описывает, что нужно сделать и как, задаёт последовательность. Машина просто считывает команды друг за другом и выполняет их как они есть, если они выполнимы данной машиной.
Декларативный: - нужно выйти на улицу - для выхода на улицу нужно быть одетым в уличную одежду, обутым и в шапке - чтобы быть одетым, нужно надеть одежду - чтобы надеть одежду, нужно снять одежду - сейчас я в домашней одежде - домашняя одежда это одежда - уличная одежда это одежда - чтобы быть в шапке, нужно надеть шапку - чтобы быть обутым, нужно обуться - чтобы обуться, нужна обувь - ботинки это обувь - после обувания в ботинки шнурки должны быть завязаны и т.д. Я точно не знаю, набросал как сам понимаю. Суть декларативного подхода в том, что ты просто сбрасываешь в одну кучу описания разных объектов и действий, а затем говоришь: "я хочу объект с такими-то характеристиками". И машина, используя описания объектов и действий, по каким-то своим алгоритмам находит способ создать требуемый объект, затем создаёт его и возвращает пользователю. Тебе не важно, как работает машина и какие решения она принимает для создания желаемого тобой объекта, тебе нужен только объект с какими-то характеристиками.
Вот более реальный пример: ><div style="border: solid 1px black; width: 100px; height: 50px; background: white"></div> Это декларативный подход. Мы говорим машине: мне нужна коробка размером 100 на 50 пикселей, с чёрным контуром в один пиксель толщиной и белой заливкой. Как и что она будет делать нас не волнует, нам нужен результат. В императивном стиле было бы так: >canvas.pen.color = black; >canvas.pen.width = 1; >canvas.brush.color = white; >canvas.rectangle(0, 0, 100, 50); Здесь мы явным образом задаём параметры конкретных инструментов (canvas, pen, brush) и используем их для создания прямоугольника конкретным способом (описанным в методе rectangle). Нам важно, чтобы задача была выполнена именно с помощью этих инструментов и именно в такой последовательности. Когда же мы описываем <div> в html, нам совершенно без разницы, что и как будет делать браузер, лишь бы результат соответствовал ожиданиям.
Короче, декларативный подход используется чаще, чем кажется, и не нужно на него фукать, у него просто своя область применения.
>>1951459 Во-первых, зачем ты это все написал, если анон, которому ты отвечаешь, написал все то же самое, только короче. Во-вторых, нить дискуссии была о том, с чего ТС взял то декларативное описание ЕСТЕСТВЕННЕЕ императивного. И вот теерь посмотри на свои описания алгоритмов в императивном и декларативном стиле, и скажи - какой из них ЕСТЕСТВЕННЕЕ для ЧЕЛОВЕКА.
>>1951418 >И если привыкну к неоптимальному подходу, буду использовать его всегда, а потом тратить время на поиск узких мест. Я даже представить не могу что нужно делать, чтобы узким местом было использование filter и foreach вместо одного for, ты там совсем ебанулся? Ты мне почему-то напоминаешь одного чувака, который, когда учился играть на пианино, спрашивал какой стороной подушечки пальцев нужно нажимать на клавишу.
Хочу тип, который бы принимал только те поля объекта (>Node), которые имеют тип Connection<любая хуйня>. Сделал вот так:
type Connection<T> = ... type RequireConnection<T> = T extends Connection<infer X> ? T : never; type Config<T extends Node, K extends keyof T> = { connection: RequireConnection<T[K]> ... }
При записи все нормально, иде подставляет нужные поля, но при чтении дженерика Config<any, any> она говорит А ВДРУХ БЛЯТЬ ВСЕТКИ НЕВЕР, и сует connection: any. Что изменить?
>>1951510 Два цикла подряд вместо одного = в два раза дольше обработка данных.
>>1951056 >В твоем случае forEach и filter предпочитаемы Я нашёл фатальный недостаток forEach: >Error: Cannot read property 'forEach' of undefined Т.к. forEach - метод класса Array, если мы получаем откуда-то вместо массива пустышку, код валится с ошибкой. Можно вставить проверку на undefined, но зачем, если цикл for не сделает ни одной итерации безо всяких дополнительных проверок? Вместе с проверкой на undefined кода становится больше, чем с обычным циклом for.
Я создаю экземпляр класса, давая конструктору массив, в котором вторым элементом может быть вложенный массив, и конструктор создаёт вложенные экземпляры того же класса по той же схеме. Вложенность, естественно, ограничена размером стека, но мне хватит. Так вот последний по вложенности класс получает вместо массива undefined, т.к. в прошлом массиве был всего один элемент. С for работает без проверок, красиво и просто, с forEach придётся костылить проверку на undefined. Нибуду((
>>1951272 Нахуй серверу знать вьюпорт клиента, совсем поехавший? Или пердолишь свой ебаный styled components, абсолютно не зная, что у `<link>` есть аттрибут media, позволяющий условно загружать стили?
>>1951486 >какой из них ЕСТЕСТВЕННЕЕ для ЧЕЛОВЕКА Естественнее в каком плане?
Если тебе нужно пошагово объяснить ребёнку/дебилу/старику/иностранцу какие-то действия для достижения какого-то результата - да, тут императивный подход только и можно применить. Чтобы человек не метался в панике и не пытался делать то, что делать опасно, неэффективно или бесполезно. Например, показываешь ребёнку, как надевать курточку - "левую ручку сюда, правую сюда, и смотри не прищеми пальчики молнией" (хотя последнее уже декларативное).
Если же тебе нужно дать задание взрослому здоровому адекватному человеку, тем более специалисту в какой-то области, то тебе достаточно сформировать запрос: "нужно то-то и то-то, в таком-то виде и объёме к такому дню". Ты же не будешь учить уборщицу мыть полы типа "воду наберите в ведро, тряпку макаете в воду и трёте тряпкой пол, пока вода не загрязнится, меняете воду и повторяете пока пол не станет чистым" (она посмотрит на тебя как на поехавшего), ты скажешь ей только "вот здесь чтобы пол был чистым, через час проверю".
Окей, уборщица может быть новенькой и не знать, где инвентарь. Но ты не говоришь ей "иди до двери, возьмись за ручку, открой дверь, отпусти ручку, наклонись, возьми ведро и швабру, закрой дверь ногой, развернись на 180 градусов, пройди до начальной точки". Ты говоришь ей "швабра и ведро находятся в подсобке, подсобка по коридору прямо за маленькой дверью". Дальше она сама находит в своей памяти нужную программу для достижения двери, извлечения инвентаря и его использования для мытья пола. Или не находит и увольняется))
То есть мы общаемся в основном в декларативном формате: - подай соль - принеси табуретку - расскажи о прочитанной книге - сделай мне сайт, где я буду весь такой хороший - помогите решить задачку, вот ошибка, вот что хочу сделать, не выходит И так далее. Мы не пишем программы, мы запрашиваем желаемый результат. Даже обучение не всегда основано только на создании программ - часто предлагается самому найти решение, эксперименты помогают в обучении.
>>1951674 >for of О, спасибо, про for in я узнал из предлагаемых шаблонов кода в редакторе, а for of загуглить не додумался. Это как раз то, чего мне не хватало.
Привет, аноны, неdавно начал параллельно с основной работой поdрабатывать на смежном стеке, который мне интересен. Проблема в том, что работа заклuyчается в том, что мне скиdываuyт тз в телеге, а я в ответ архивом результат, потом dеньги на карту, dаже не знаuy как завут чела, который мне платит, лол. Вот тут заdумался, а веdь с этого наdо налоги платить, dа? Ну и вопрос куda и как и сколько и что буdет, если того? Там не много, буквально пара к в неdелuy, поэтому и не dумал об этом раньше...
>>1951719 Даже в этом примере видно, что разница в пять раз. Добавь в конец третий цикл конструкции some и разница увеличится до 10 раз. А теперь умножь таких конструкций по несколько штук на каждый чих, когда у тебя по всему проекту эти маленькие коллекции. Разница возрастает на порядки.
>>1951722 >разница в пять раз 0.00005 вместо 0.00001? >А теперь умножь таких конструкций по несколько штук на каждый чих Которые все выполняются одновременно в одном потоке?
>>1951304 Энтри левел вкат: Functional Light JS - я бы советовал начинать всем с этого, прагматичное ФП, очень хорошо разжевываются самые основы. Книга полезна не только как вкат в ФП, а как учебник по JS и построению программ в целом. https://github.com/getify/Functional-Light-JS
Некст лвл вкат: Mostly Adequate Guide To FP - ФП с корабля на бал, намного больше терминологии и объясняются основы теории категорий, но если вдумчиво читать, то одно из самых приятных введений в функторы и монады которые я видел. Желательно хорошо знать JS перед чтением. https://drive.google.com/file/d/1NAlmEylllMM5zS8xke6pd16k2ULvbBZ0/view?usp=sharing
>>1951722 Они везде и есть. У меня на работе есть супер сложный редьюсер, которые наверное массивов 20 по 1000 объектов перебирает по несколько раз и всё это занимает 1.7 мс.
Все эти перфоманс дрочки это лишь отсутствие практического опыта разработки. Тот кто шарит понимает, что в вебе узкое место это апдейт DOM, а не джаваскрипт.
>>1951740 Да у тебя один Layout пересчитываться будет десятки миллисекунд спасибо реактоговну, дрочка на фреймы бред. Тот, кто шарит знает, что код пишется не для машины, а для человека в первую очередь, особенно на высокоуровневых языках программирования. Про фреймы будешь рассказывать коллегам, когда они охуеют из твоих for-if'ов и мутаций переменных и будет невозможно добавить новый функционал без ебли.
Салам, боги. Помогите полному долбоёбу плз почему response.status возвращает undefined? при том, что сервер отвечает кодом 200
Еще вопрос - почему в этом коде если поставить await перед fetch, то выскочит SyntaxError - требуется async функция, хотя в учебнике на learn.javascript подобное написание прокатывает?
>>1951735 И ты наверняка замерил, что твой код куда-то там не укладывается по времени и лагает? Ты же не просто так фантазируешь о преждевременных оптимизациях без всякого на то основания, правда?
Анончики, посоветуйте книг для вката в js с упором на обмен данными с сервером. Желательно поновее со свежим взглядом на ленгуадже и технологии. Можно и на английской мове
>>1951339 Если стремишься к реюзабельности компонента, его изолированности от окружения и тестируемости (хотя простые компоненты и так нехуй тестировать), то, очевидно, всю логику, в т.ч. IO поебень выносить в отдельные сущности, а клеить тонкой прослойкой типа контейнера, который осуществит необходимые подписки и пробросит пропсы в целевой компонент. Это если делать по уму. А ежели просто ебошить - то делай, как удобно.
Как принято в ангуляре: 1. Нужно соединить 1 обсерваблу из самого компонента, и одну сверху. Если кроме как тут она нигде не нужна, то передавать сверху собственно готовую обсерваблу, или простое значение, а в компоненте уже пулять локальную по изменению?
2. В методичке просят переданное сверху не мутировать, но в то же время реактивные формы этим внаглую занимаются, т.е. их считают за сервис, хотя они не инжектятся, а дриллятся. Как тогда понять, когда это норм, а когда зашквар?
>>1951977 А инкапсулировать будет кто, Пушкин? Без инкапсуляции и с константами прямо в логике твой слайдер может быть только один на странице, на которой кроме него нет никаких картинок (ты же вообще все <img> зохавал?).
Нужен класс: class ImageSlider { constructor(name, images, owner) {} } Где: - name определяет CSS-класс, по которым один слайдер отличает элементы других слайдером от своих. Все картинки и кнопки должны иметь этот класс. - images определяет набор картинок, которые нужно воткнуть в этот слайдер, потому что создавать мы его будем динамически (кому нужна статическая страница с жыс-слайдером картинок в 2021?). - owner определяет элемент, к которому этот слайдер сам себя добавит (чтобы нам не нужно было его вручную добавлять, просто сделал new ImageSlider() и забыл про него, пока не понадобится удалить).
>>1951977 >>1952023 Забыл ещё, ты перезаписываешь свойство стиля display, а что если тебе нужно картинки отображать не как block? У этого свойства много значений.
Правильнее будет присвоить картинкам определённый класс, в нём обозначить свойство display и присвоить ему нужное значение (block или что угодно другое кроме none), а в твоём коде вместо display = "block" делать просто display = "". Так восстановится значение класса, перезаписанное присвоением display = "none". А первоначальное присвоение none должно быть в конструкторе класса, который размещает предложенные картинки внутри слайдера.
Сам недавно переписывал свой код, когда потребовалось абстрагироваться от значения "block", решение оказалось неожиданно простым.
>>1952030 Он ведь нужен только если ты что-то возвращаешь. Если нечего возвращать, то и ретурн не нужен. А если ты что-то хочешь вернуть, то как ты забываешь про ретурн? Во большинстве языков возвращаемое значение нужно куда-то присвоить/передать явным образом.
>>1952029 Согласен, переписал на изменение классов сплавным переходом. Про конструктор на классах читал. Но вот энта инкапсуляция на практике пока мне не попадалась, все что ты написал я понял. Но реализовать на практике пока не хватает опыта.
>>1952034 >инкапсуляция на практике пока мне не попадалась Я недавно вот такую менюшку себе сделал, суть такова: есть меню с выбором вариантов ответа, каждый вариант может быть вложенным меню со своим набором вариантов ответа, и так далее. То есть рекурсивная структура. Сделано просто рекурсивным созданием новых объектов одного и того же класса, а запускается созданием самого первого объекта передачей в него всей необходимой информации. Внешний вид, цвета, расположение и форма, даже сортировка (выбранный пункт поднимается наверх, к заголовку группы) - это всё на CSS, на JS только логика создания/открытия/закрытия группы и передача результата (тому, кто создал это меню) с его самоуничтожением в случае успешной обработки результата. По-моему гениально, осталось только отрефакторить и убрать мусор из кода. Короче, без инкапсуляции в класс это было бы намного труднее сделать.
Вряд ли кому-то понадобится делать галерею в галерее в галерее, но несколько одинаковых галерей на одной странице - это очень распространённая ситуация, например, в газетных статьях и на страницах-демонстрациях какой-нибудь программы/библиотеки/технологии.
>реализовать на практике пока не хватает опыта Это очень просто на JS, сравнивая с другими ЯП)
>>1951014 >нет смысла делать эти микрооптимизации https://habr.com/ru/company/vdsina/blog/544218/ >O(n^2) — оптимальное время для плохо масштабируемых алгоритмов — достаточно быстро, чтобы попасть в продакшен, но достаточно медленно, чтобы ломать всё, после того, как он туда попал. >Если вы пишете код, который будут запускать другие, то убедитесь, что он достаточно хорошо масштабируется для обработки любого возможного множества данных, вне зависимости от его разумности. Квадратичные алгоритмы обычно проваливают эту проверку.
Это просто к слову о том, почему задумываться о том, как код будет работать с большим объёмом данных - полезно, даже если сейчас ты не собираешься загружать его такими объёмами.
Алсо, в чем проблема делать фетч в компоненте, а потом полученное записывать в стор? При условии что запрос в компоненте уникальный. Это просто для удобства организации кода делается?
>>1952249 >экшены Экшены будут а actions created вызываться как и раньше , только уже будет функция которая диспатчит через ac результат работы метода из api.ts, все обращения в внешним ресурсам будут в одном файле
В чем прикол делать запросы внутри компонентов? Это же пиздец нелогично и как это потом все мокать для тестов? У меня все проходит через сервис, который состояние запросов записывает в стор, а компоненты лишь отрисовывают контент в зависимости от состояния стора и наличия данных в кешируемых хранилищах данных.
>>1952347 Тайпскрипт же заставляет указывать типы? А с описанием типов кодить становится труднее и дольше. Да, меньше времени уходит на отладку, т.к. система типов предотвращает некоторые ошибки, но речь шла про написание кода, как я понял.
>>1952401 >кодить становится труднее Лол. Пиздец же так трудно типы указать, да? А без тайпскрипта потом сидишь и охуеваешь, в каком месте у тебя число стало строкой в тридцатикратно вложенном компоненте
>>1952424 Лол, я сам большую часть сознательной жизни кодил только на строго типизированных языках (Паскаль и подобные ему). Так что я знаю, зачем нужны типы, регулярно создавал новые и всегда указывал их (иначе не складируется), а от слабо типизированных языков шарахался. Но сейчас понимаю, что слепить прототип программы без указания типов на порядок быстрее и проще, а ошибки если и бывают, то не критичны - не прошивку ракеты/самолёта же кодим. Но я-то опытный, хоть и любитель, а вот новичкам, конечно, слабо типизированные языки только вредят, имхо.
>число стало строкой И часто оно у тебя так случается? По-моему это возможно только когда ты пытаешься сложить строку с числом, вместо сложения происходит конкатенация. Зачем, спрашивается, делать конкатенацию там, где она не нужна?
>тридцатикратно вложенном компоненте Ты должен делать тесты каждого уровня вложенности начиная от первого изменённого уровня до самого верхнего. Сделал изменение - провёл тест и убедился, что всё работает. Как только тест показывает ошибку, ты уже знаешь, что эта ошибка возникла из-за последнего внесённого тобой изменения, потому что до этого все компоненты тесты проходили успешно. Ну или у тебя ошибка в тесте, лол)) А если ты тестов не делаешь и пишешь сотни строк кода без единой проверки - зачем ругаться на язык? Сам виноват.
Меня вот Паскаль приучил тестить программу после каждой строчки/изменения в коде. Даже после написания комментария предпочитаю перекомпилировать, а то вдруг где-то что-то поломал. Ну а с JS всё ещё проще: компиляции как таковой нет, достаточно переключиться на браузер и нажать F5, все изменения и возможные ошибки будут сразу же явно видны. Т.е. городить систему типов особого смысла нет, зато время на выдумывание этой самой системы уходит намного больше, что замедляет прототипирование.
Вот, например, ты боишься, что у тебя integer превратится в string. Но это цветочки, ты не должен указывать x: integer, ты должен придумать новый тип, например, TValue = Integer, а затем следить за тем, чтобы TValue не попадало в Integer, потому что это разные типы, хоть и числовые. В языке Ада такие проверки из коробки, но вряд ли тебе понравится на ней программировать (очень долго и очень трудно выдумывать новые типы)...
12 страница, там где автор сначала пишет через класс Flock - реально надо минимум когнитивных способностей чтобы понять что происходит. Потом начинает городить фп ересь, где уже реально нихуя не понятно сходу. Вот и ответ о применимости фп как подхода.
>>1952433 >Но сейчас понимаю, что слепить прототип программы без указания типов на порядок быстрее и проще Вот именно что прототип, для большого приложения чистый js это пиздец полный, мне по крайне мере от него просто блевать тянет. Даже если через неделю к коду вернешься уже нихуя непонятно куда какие объекты передаются и какие у них поля/методы. А так у меня даже с ts бывают ошибки когда я неправильно тип возвращаемый с бэка указываю, боюсь представить что бы было если бы вся прилага была без ts. Я что долбоеб запоминать какие значения у меня могут быть undefined, чтобы проверки добавлять? Тем более в ts есть пиздатый синтаксис object?.field. Короче ванильный js это калище дикое, а ts тупо кайф.
>>1952433 >ты не должен указывать x: integer, ты должен придумать новый тип, например, TValue = Integer, Никому я ничего не должен, и вообще в тайпскрипте структурная типизация
>>1952476 А ты не всегда можешь знать наверняка. Я буквально недавно пилил бэк для личного проекта и решил не заморачиваться с тайпскриптом, в итоге я напридумывал новых фич и следить за всем и держать все типы в памяти стало очень больно. В итоге пришлось все на ts переписывать. >>1952496 Я лично по настоящему больших проектах не писал, но участвовал по крайне мере в средних и везде использовался тайпскрипт, а там где не использовался был постепенный переход. Был еще проект, где некоторые типы в комментах указывались, не помню уже как такой подход называется, но как по мне проще уже реальный ts подключить.
Не то чтобы я дохуя сеньер, но по моему личному опыту ts выручал дохуя раз.
Каким образом в реакте используется классовый синтаксис, если не используются классовые компоненты? Есть пример? Какие-нибудь репозитории, в которых можно посмотреть как все сделано? А то фриланшу сейчас на реакте, делаю все на функциональных, но хочу стать полноценным рабом, а на собесах наверняка про всё вот это вот спросят
>>1952602 Без жс надо будет всю галлерею хранить на странице, лол. Конечно можно попердолитья с ленивой загрузкой, но один хуй будет дохуя элементов в доме сидеть.
>>1952303 >Это же пиздец нелогично и как это потом все мокать для тестов? В чем именно по-твоему заключается проблема замокать запрос внутри компонента? >У меня все проходит через сервис Который работает магическим образом сам по себе, и к которому компоненты не обращаются вообще никак и не говорят ему, что фетчить и когда?
>>1952722 И что это по-твоему, если не "делать запросы внутри компонентов"? Чем твое api.getSomeData() отличается от fetch(), и почему ты считаешь, что первое вдруг мокабельное, а второе нет?
>>1952727 Я мимо проходил, хз что там про моки. Это лучше тем, что всё спрятано в service/api, в компоненте ты только функцию вызываешь которая возвращает response либо ошибку если она была.
Вот тут другой анон уже писал про это: >>1952278 Удобнее держать все обращения к апи с клиента в одном месте
>>1952724 Каким боком тут ООП? api может быть просто объектом с методами.
>>1952735 >Каким боком тут ООП? api может быть просто объектом с методами. То есть импортиурешь ВЕСЬ объект, чтобы вызвать функцию у него? Ты вообще в курсе как ES6 модули работают?
>>1952771 Эм. Я нуль, ты имеешь в виду, что если вот у меня слева нет src, то он и не возьмется в переменную? Или под показом дом ты что имеешь в виду? Консоль пустая.
Сука, че за пример такой на первой же странице по js для желторотиков, который не работает.
>>1952454 Поэтому я и скахал что про лвл вкат. Никто не говорит, что ФП это 1 страницу книжки прочитал и выучил за день. Если выглядит как ересь, значит у тебя либо мало опыта разработки, либо опыт твой это писанина на реакте была.
Без опыта это месяц как минимум изучения подхода к написанию кода и обработке данных, ведь нужна практика, конечно же. Зато потом ты становишься намного лучше разработчиком даже на ООП, даже если ФП не используешь в повседневном кодинге, мозги прокачиваются хорошо.
Здравствуйте, у меня проблема с библиотекой Chart.js, конкретно не могу изменить ширину графика типа line - он растягивается на всю страницу. указываю размеры здесь: <div class="container"> <canvas id="lineChart" width="600" height="400"></canvas> </div> высота графика меняется, а ширина всегда остаётся одной и той же.
пробовал в опциях графика разные комбинации responsive:false и maintainAspectRatio: false, но ничего не помогло. Так же прописал Chart.defaults.global.maintainAspectRatio = false; (до этого даже высоту нельзя было поменять) Подскажите пожалуйста, что делать?
>>1952762 Затем что вот здесь хуйню спизданули: >>1952703 > Который работает магическим образом сам по себе, и к которому компоненты не обращаются вообще никак и не говорят ему, что фетчить и когда?
Если кто-то несёт хуйню, то почему бы не поправит его? Но тут походу безнадежный случай, человеку ООП мерещится там, где его нет. Вкатыш походу
Вообще реакт должен отвечать исключительно за UI. Все остальное должно быть за его пределами. Именно поэтому хуки по типу useReducer и useEffect налево направо превращают реакт в лапшу из сайд эффектов. Мне кажется во времена классовых компонентов они выглядели хоть и более многословными, но почище.
Почитал пасту про вкат. Вы ебанулись? Чтобы вкатиться веб-макакичем джуном мне надо учить прототипы, хулиард фреймворков, вебпаки, говнопаки? За 30к рублей? Зп кассира в Магните.
Есть классы A, B, C. В классе C есть конструктор, в котором инициализируется условная конфигурация, получаемая от объектов класса A и B. В классе C есть так же статичные методы, которые задействую эту информации и выводят на экран. Учитывая асинхронность ноды, мое приложение выглядит так: const a = new A(); a.run(...); const b = new B(); b.run(...); const c = new C(a.getInfo(), b.getInfo()); c.run(...); В экземплярах объектов a и b метод run(...) вызывает те самые статичные методы класса C.staticMethod() и выводит корректно информацию, хотя конструктор этого класса еще не был вызван, а значит информации от a и b там быть не должно. Даже, если представить, что конструктор C вызвался раньше, чем отработал любой из методов run(...) a и b, и вывел эту информацию, то можно заблокировать главный поток перед инициализацией c на 5 секунд, но метод run(...) объектов a и b все равно выводит корректную информацию статичными методами по расписанию и без задержек, после чего через те самые 5 секунд срабатывает вывод из конструктора C, что подтверждает то, что главны1 поток был прерван до вызового этого конструктора. Почему так?
>>1952847 Я думаю что все адекваты спят, а ты сидишь от нехуй делать и скроллишь ночной. Еще и не понимаешь нихуя, но почему-то решаешь, что можешь говорить за всех, лол.
>>1952851 >начал вертеть жопой и петросянить, вместо того, чтобы просто попросить больше информации >получил ответ в таком же стиле >рррряяяяя не огрызайся дай пример лучше >буквально на пальцах, оперируя тремя буквами/объектами, объяснил все изначально максимально подробно с кодом в 3 строки
Подскажите тупице. Я сделал небольшой проект с роутами, сбилдил, закинул на бесплатный хостинг, все работает, но если зайти на роут и перегрузить страницу, то ошибка 404. Как это решается?
>>1952828 >Вообще реакт должен отвечать исключительно за UI. За UI должен отвечать html/css. Жабаскрипт - за логику. >Все остальное должно быть за его пределами. Яскозал? >Именно поэтому хуки по типу useReducer и useEffect налево направо превращают реакт в лапшу из сайд эффектов. То ли дело вызывать сайд-эффекты через глобальный стор. Зато ООП! >Мне кажется во времена классовых компонентов они выглядели хоть и более многословными, но почище. Это ты ебанину с дублирующей логикой назвал "почище"?
>>1952861 > За UI должен отвечать html/css Как там в 2010? > Жабаскрипт - за логику. Конкретно реакт — библиотека для отображения UI. > То ли дело вызывать сайд-эффекты через глобальный стор Что не так? Это самая удобная модель. > Зато ООП! Где в редаксе ООП? Ты вообще понимаешь о чём говоришь, или просто так бредишь лишь бы спиздануть?
>>1952845 В общем, я разобрался, все работало правильно и конструктор C все-таки срабатывал раньше, чем вызывались его статичные методы внутри методов A и B.
>>1952877 От сюда появляется вопрос: как лучше спроектировать классы? Ведь то что у меня сейчас, это неправильно. У меня в одном приложении есть 3 основных класса: Server, Database и Console. Server - обрабатывает http запросы. Database - работает с бд, обновляет в ней информацию и т.п. Console - интерактивная обертка над stdin, позволяет вводить команды для экземпляров Server и Database.
Сonsole в своем конструкторе вызывает конструктор класса Messages, который содержит информацию о конфигурации и состояниях экземпляров Server и Database.
В самом низу я закомментировал свое решение этой проблемы, оно самое очевидное, но хочется как-то сделать все универсальным, чтобы порядок вызова конструкторов и методов был не важен при этом сохранить класс Messages, потому что мне нравится, когда есть всего один класс со всеми возможными сообщениями, вызов которых происходит повторно в разных участках кода.
Повторю проблему: конструкторы ClassConsole и ClassMessages могут (и делают это в данном примере) срабатывать позже отработки методов run() экземпляров ClassServer и ClassDatabase. Как можно изменить архитектуру классов, чтобы получить универсальную и независимую работу этих классов?
>>1952898 Также, я не знаю что у тебя console делает, он он похоже должен имплентировать IMessages и называться ConsoleMessageLogger. Если тебе еще и контроллер нужен, делаешь IController и ConsoleController. Жаль что интерфейсов то нет. Если консоли еще нет, а писать в нее уже нужно, пишешь буферизующий декторатор для логгера. Ммм, ООП.
>>1952889 Выглядит как бэковый код, поэтому можешь присмотреться к typedi, он удобно реализует dependency injection архитектуру, возможно тебе полезным окажется.
>>1952901 Возможно. Просто я такой человек, который может часами думать над названием переменной, поэтому подобного рода проектирования для меня - лютый пиздец.
>>1952906 Ничего особого не делает да и не будет, скорее всего, только число команд будет расти. Вот реальный код на текущий момент: https://pastebin.com/jqeeVYDW Про существование интерфейсов я уже и забыл, даже не помню для чего они нужны. Спасибо, почитаю.
>>1952909 Я хочу свести к минимуму использование готовых библиотек/фреймворков. Пишу в первую очередь с целью понять/изучить.
>>1952911 Можно, если имя не зарезервировано. В моем случае server и database работают, console тоже, но начинаются проблемы, когда нужно в этом же коде вызывать console.log(). Надо наверное лучше сразу тогда придумать какой-то префикс для полей класса (для экземпляров объектов он уже есть).
>>1952915 >console тоже, но начинаются проблемы, когда нужно в этом же коде вызывать console.log() Какие проблемы у тебя начинаются при такой ситуации?
>>1952915 >Можно, если имя не зарезервировано Да я прекрасно знаю, что можно. Можно даже кириллицей переменную объявить, но не лучше ли придерживаться общепринятому стилю кода? Сейчас может быть ты пишешь исключительно для себя, но однажды, если планируешь связаться с программированием, ты будешь трудиться в составе Команды. Лучше уже сегодня привыкать к тому как принято
>>1952916 const server = new ClassServer('server'); const db = new ClassServer('db'); const console = new ClassConsole(server, db); console.log('asdas'); >ReferenceError: Cannot access 'console' before initialization
>>1952924 Ты в конструкторе классСервер используешь консоль.лог, а ниже по коду зачем-то переопределяешь переменную консоль. Потому и не можешь ее есипользлвать
>>1952928 >>1952930 Если я привел код в пример, это не значит что я его использую. Просто иногда для быстрого дебажного лога проще что-то подобное написать и стереть сразу же. Поэтому в main() у меня не console, а lfConsole = new LFConsole(...), но в полях классов я еще не придумал правила именования, потому что конфликтов не было, потом исправлю.
>>1952915 в методе stop() лучше вызывай остановку сервера, дисконнект бд и остановку процесса, а в кейсе defines.COMMAND_CONSOLE_EXIT вызывай this.stop()
>>1952915 >Я хочу свести к минимуму использование готовых библиотек/фреймворков. Пишу в первую очередь с целью понять/изучить.
Чувак, если ты хочешь _изучить_, то изучать надо то, что наработано другими. Понимаешь? Пытаться понять, почему так, а не иначе. Много читать (код и книги), и не очень много писать (больше заметок, чем кода). И только потом - пытаться делать своё.
Иначе будет такая же хуита, как и у других 16-ти летних мидлов и синьёров, прости г-споди. Которых, почему-то, никто не хочет брать на работу.
>>1953026 Вообще с тобой не согласен. Читая чужой код, ты учишься делать чужие ошибки, а не только получаешь какую-то полезную информацию. Эту информацию нужно еще и самому обработать. И выходит, что это ни чем не отличается от обычного самообучения на практике. Дохуя людей, которые пишут код, считают себя синьорами, рубят 300к/нсек, а на деле хуи моржовые с клавиатурой в руках. Почему в софте, над которым трудятся сотни человек, имеет ту же сотню багов, которые "фиксят" и находят новые? Не потому что код пишут 16 летние мидлы, а потому что это люди, которые считают что делают что-то лучше и правильней, другой считает по своему, третий аналогично и т.д. Все доходит до того, что ведущий погромист, видит это написанное говно, мерджит в мастер и ахуевает, потому что он 100ый в этом списке, да и вообще он написал даже книгу свою по архитектуре кода, которая выстрелила и ее до дыр читает другая сотня-тысяча вайтишников-шахтеров, которые потом с ноги ворвутся за своими 300к/нсек, щеманут омежек и начнут диктовать свои условия команде. Все это конечно утрирование, но примерно так оно все и работает на самом деле.
А что я? Я просто сижу и по фану пишу свой код, в котором я ориентируюсь. Пишу программки для себя, начиная с меньшего, чтобы потом написать что-то большее, например, свою игру. Поэтому да, чем меньше я использую прослойки в коде, которые скрыты, тем больше я понимаю код и имею над ним контроль. Никогда не понимал выскочек, которые про велосипеды что-то там бормочат. Велосипеды - это хорошо, если ты понимаешь зачем он тебе нужен.
Я учился еще в вузике на погромиста, закончил, но интерес к нему у меня пропал. Я не работал ни в каких командах, все что писал выше это не более, чем мой субъективный взгляд на вещи со стороны. Ну а спустя годы, я просто решил к этому говну вернуться и расшевелить его. Ни на какие лавры не претендую, устраиваться никуда не хочу, но хочу понимать свой код и иметь контроль над ним. По возможности использовать более элегантные решения, я же все-таки не против клир кода и прочих концепций в подходе к написанию его, что-то даже в памяти еще осталось после вуза.
>>1953068 > Читая чужой код, ты учишься делать чужие ошибки, Ебать ты альтернативно одарённый.
А не читая чужой код, ты обречён сделать все те ошибки, которые уже были сделаны до тебя, за всю историю программирования, плюс добавить ещё и своих уникальных тараканов.
Но, вообще, каждому - своё. Кто-то - перфекционист. А кто-то - онанист.
Во-вторых - как это меняет тот факт, что JS - дрисня, а TS - рулит? И что единственный способ починить JS - это писать тонны JSDoc комментариев, в которых, в итоге, получается сильно больше знаков, чем если бы ты писал типы в TS?
>>1953094 Речь была вообще о том, что нельзя однозначно сказать "читай чужой код - становись профессионалом". Чаще даже узнаешь что-то новое/полезное, когда сам пишешь и пробуешь разные варианты, эксперементируешь, а сидеть книжным червем и надрачивать на макконела или ковырять гит такого же самоучки - это дорога хуй пойми куда и зачем, в которой ты идешь только по наитию и принимаешь все за чистую монету. Я не против книг и поиска информации из всех возможных источников, но говорить "иди ковыряй чужой код и читай мою любимую книжку, иначе не стать тебе погромистом" это... Действительно, каждому свое, тут не поспоришь даже.
>>1953103 >или ковырять гит такого же самоучки Должна быть природная интуиция, чтобы отличать добро от говна. И, если она есть, то чтение правильного чужого кода и правильных книг - это великое благо.
>>1953106 И чем отличается анализ незнакомого тебе кода от написания кода, когда оба этих процесса изначально основываются на интуиции с твоих же слов?
Алярм, мужички. Я сделал небольшой проект с роутами, сбилдил, закинул на бесплатный хостинг, все работает, но если зайти на роут и перегрузить страницу, то ошибка 404. Как это решается?
>>1953245 Советую вкатится в вебпак, ручками настроить вебпакдэвсервер, тогда все поймёшь , cra заставляет неверно конфигурировать package.json, дропай эту хуету, один раз напишеш шаблонный конфиг и все будет заебца
>>1953089 >Дроч с конфигами — главная боль фронтенда имхо Это ж фича бабеля - плагины конфигов пресетов. >>1953098 >в которых, в итоге, получается сильно больше знаков, чем если бы ты писал типы в TS? ЖСдоковые каменты по крайней мере в тело функции не протекают и ими можно назначать тип функциональным объявлениям. И проиграл от количества знаков, какая тебе нахуй разница сколько там знаков в сырцах?
>>1953295 Ну хуй знает. Взял только что рандомный проект из Гита, тоже сбилдил, залил в папку хостинга и нихуя. Все роуты при перезагрузке выдают ошибку хостингового сервиса. Может их надо ещё как-то на хостинге настраивать?
>>1953360 Бери да делай, хули тут на дваче спрашивать, половина в этом треде долбоебы, которые максимум alert("Hello, world!"); написали. Я знаю тех кто в 40 вкатился, главное просто не ссать, а что-то начать делать.
>>1953245 >на бесплатный хостинг Наверное никак, чтобы не было 404 тебе нужно в конфигах сервера прописать что все роуты идут через твою страницу (например index.html) если там nginx и у тебя нет доступа к конфигам, то земля тебе пухом, есть Apache, пробуй .htaccess конфигурировать. Сейчас у тебя скорее всего по роутам сервер ищет физически расположенный файл по этому адресу, а его нет вот и 404. А в проекте у тебя все работает потому что роуты без перезагрузки страницы и js меняет url в адресной строке.
>>1953419 Видимо так и есть. Перенаправляет на страницу, ссылка на которую записана в htaccess. Хостинг hostronavt.ru, может кто сталкивался. Как это делается в реальных проектах? Меняется конфиг сервера хостинга? Или может на хостинг заливать билд спроектированный на экспрессе, который на гет запросы будет отправлять файлы ? Или это совсем хуйня?
>>1953426 >htaccess >Как это делается в реальных проектах? Обычно Apache не используется, он остался только на говнохостингах, все юзают nginx, гугли конфиги под свой стек на конкретном сервере. Телепатов тут нет.
>>1953428 >Обычно Apache не используется, он остался только на говнохостингах, все юзают nginx Ты невежда и максималист. Кто все? Я юзаю виндасервер. Апач удобней для небольших проектов на виртулках. Энжиникс удобней для дедиков.
>>1953588 ООП тут при чём? Стейт меняется через вызов функции экшн-криэйтора с последующим возвратом нового стейта через редьюсер. ООП тут вообще не при чём.
>>1953073 Пофиксил, кста Убрал флаг debug в .babelrc. Зачем его вообще ставят в туториалах? Нах мне смотреть какие там плагини что скомпилировали, если я макак всё работает >>1953330 >Это ж фича бабеля - плагины конфигов пресетов Но лучшего у нас нет..
Написал небольшой коммерческий интернет магазин на реукте. До сих пор ссусь проходить собесы. Есть разные вещи, которые я понимаю как работают, но когда доходит до четких ответов, начинаю скулить, мычать и нести хуйню. Что делоть? Пару раз давно проходил собесы, уходил обоссанным, флешбеки из шольных лет, где училка ставит тебя к доске, понимает, что ты нихуя не знаешь, но все равно закапывает тебя вопросами, наслаждаясь твоей беспомощностью
>>1953672 Для собеса надо знать только базу - замыкания, прототипное наследование, сортировка, это стандартные вопросы на всех собесах. Срякт и остальное что выучил можешь на пальцах объяснять. Главное еще что бы пет проект был вылизаный, заходишь на него и все блестит. Так обычно в джуны и набирают.
В любом случае лучше пробовать идти на собес, когда будешь работать - в тиме будешь расти быстрее, нежели дома.
>>1953806 Но скорее всего у тебя не прокачаны софт скилы и социально взаимодействие. Потому что тот кто заинтересован в работе - обычно проявляет инициативу и настойчивость - в ходе беседы понимает где его минусы, интересуется как минимум чего ему не хватило для оффера, хотябы в обратном письме эйчару. После того как узнал что компания в тебе не увидела - дрочишь эти темы и дрочишь. Потом пробуешь еще раз проходить собес, можно в том же месте можно в другом.
>>1950886 (OP) Сап, джигиты. Пытаюсь в редакс и появился вопрос - если я обращаюсь к стору в родительском компоненте, насколько правильно передавать стейт стора/экшены как пропсы дочернему? Или это говнокод, а в дочернем компоненте нужно еще раз подключиться к стейту?
>>1953932 Смотря что ты хочешь сделать. Я вот пилю интернет-магазин-PWA на гатсби и у меня компоненты там двух видов - UI, которые нужны чисто чтобы рендерить UI элементы и собсно родительские, которые задают структуру и получают данные из редукса, которые потом передают в UI компоненты по надобности, а также они же диспатчат экшоны в редукс, который потом меняет стейт, запускает thunkи, которые общаются с API и так далее.
>>1953947 Интересуюсь у тех кто давно в теме - нужно ли там досканально изучать его настройку, или достаточно знать как подключать файлы для компиляции и модули?
>>1953949 Блять, анон, странные у тебя вопросы. Вебпак, как и вообще любой фреймворк, библиотека, пакетменеджер и прочая хуйня - созданы исключительно для твоего удобства. Ты сам решаешь насколько хорошо тебе надо ознакамливаться с инструментом, который облегчает тебе жизнь. Никогда не понимал откуда у людей такая тяга устраивать себе специальные олимпиады на ровном месте.
>>1953953 КАК В РАБОТЕ ИСПОЛЬЗУЮТ ВЕБПАК, НА РАБОТЕ? В ОФИСЕ? ПОСЛЕ ВЫПИТОГО СМУЗИ?? КАК ВЕБПАК В ИДЕАЛЕ НАСТРАИВАЮТ??? КАК ВЕБПАК НАСТРАИВАЮТ ХИПСТЕРЫ БОРОДАТЫЕ В СТАРТАПАХ???? КАК ВЕБПАХ ИСПОЛЬЗУЕТСЯ В КРЕЕМНЕВОЙ ДОЛИНЕ??? КАК ВЕБПАХ НА ГАЛЕРЕ НАСТРАИВАЕТСЯ??? ВЕЗДЕ ОДИНАКОВО??? +-???? ЕСТЬ ОТЛИЧИЯ ГДЕ ТО????
Можно ли в темах стайлед компонентов хранить какие-то глобальные переменные? Т.е. у меня не будут менятся темы сами по себе. Но я просто хочу вынести туда то, что будет указываться часто, типа набора размеров шрифтов, цвета всякие и т.д. Это так делается у стайледов? Или просто создать отдельный .js файл, и оттуда по мере необходимости экспортировать нужные переменные?
>>1950886 (OP) Есть те, кто работая в одной компании становился из JS джуна мидлом? (Ну или те, кто увольнялся с джуна и шёл на мидла). Какой багаж знаний и сколько коммерческого опыта вы имели на этот момент?
Кто со стайлед компонентами работал, объясните пожалуйста, а где можно собственно выбрать, какую тему в провайдер передавать? К примеру в нексте нужно обернуть в компоненте app всё компоненты, чтобы передать в них стор, потом обернуть всё в themeprovider. А из какого компонента я потом выбрать тему могу? Ведь доступ к стору я из самого app получить не могу, поскольку этот компонент в стор не обернут. А значит из всех дочерних компонентов я переключить тему не смогу. Мне кнопку же не в самом app компоненте делать? Придется еще одну обертку для провайдера делать в каком-то нижнем компоненте и туда уже передавать текущее значение для темы?
>>1954025 Ну и да, в доке styled-components они просто в app компоненте делают кнопку, которой эти темы меняют. Но очевидно что в реальности в этом компоненте кнопку держать неправильно
>>1954020 Ну на столько ебнутых ситуаций ИРЛ не видел(если специалист не меня стек), но про грейд +- таких историй полно. Меня интересует просто различный опыт людей, который от компании к компании может быть разный.
>>1953854 Продолжай дрочить на терминологию и думать что теперь знаешь подноготную JS, раз оказывается под капотом функции это объекты. Только на практике это тебе никак не поможет, хоть ассемблерными вызовами их назови, важно их поведение на высоком уровне.
>>1954060 Спасибо, понятно теперь. А то обработчик ошибок стянул с прошлого проекта и тут внезапно ошибки посыпались. Могли для msql библиотеки и запилить это свойство
>>1954061 >Очевидный Sass Бестолочь, твой сасас неуправляем средствами js, в итоге ты будешь использовать и сас и инлайн стили, и кучу условного применения стилей
>>1954160 У тебя могут быть почти одинаковые по сути компоненты, но которые могут менять свой внешний вид в зависимости от каких-то состойний, заглушенные кнопки, и т.п. Либо делай всё стилями, либо в стайлед компоненты передай пропсы. В первом случае у тебя будет каша css стилей и условного рендеринга. Во втором у тебя будет только один единственный стайлед компонент с пропсами
>>1954114 А стили и не должны управляться джсом. Джс управляет классами, стили применяются к ним. Styled components как идея бред. Конечно, это работает, но даже простые стили выглядит как пиздец смесь CSS и JS, страшно представить как это выглядит в больших проектах с вложенными селекторами и со сложным CSS. Стили вообще не должны никакого отношения иметь к компонентам, все что их волнует это конечные HTML селекторы.
>>1954109 >Наоборот убирают слой css классов, которые загрязняют JSX. Поперхнулся. Как можно загрязнить то, что и так уже является грязной смесью разметки и кода?
>Просто не пишешь говнокод и ничего не будет тормозить. Просто любое реактоговно даже от реакторазрабов тормозит, видимо не родились еще люди которые могут идеально писать реакт код.
>>1954174 Ты охуеешь, но можно просто вынести твои состояния в отдельный компонент и переключать классы в нем, если очень сильно нужно. Будет точь-в-точь styled components но лучше. Но обычно даже это не нужно, и ты избавляешь себя от необходимости писать десять импортов кастомного говна, чтобы табличку сверстать, а просто пишешь html с классами.
>>1954182 Дурачок, а сколько у тебя будет комбинаций на 10 различный состояний? Или css-in-js уже вознесся над основами логических комбинаций и там тебе не нужно 10 модификаторов для 10 состояний, все делает зубная фея палочкой?
>>1954183 Дело тут в том, что стайледы находятся в одном месте и все, что там внутри происходит сразу же у всех на виду. А что ты там в классах с десятикратным условным рендерингом понаписал, не всегда знаешь даже ты сам.
>вынести твои состояния в отдельный компонент Поздравляю, ты только что styled-components
>html с классами Неудобное говно само по себе, тут даже обсуждать нечего, если только у тебя там не тудулист из 4х элементов без переиспользования
>>1954185 Научись пожалуйста излагать свои мысли, я тебя с трудом понимаю. У тебя есть один стайлед компонент, внутри которого ты можешь делать все, что угодно использую все средства js. У классов говно мамонта 1000 летней давности. Предлагаешь писать отдельный класс на каждый пук, где у тебя isMobile, isDisabled, isActive, isHuiNane? Я просто не понимаю что тут вообще можно обсуждать. Может у тебя конечно там 10 захардкоженных компонентов на каждое дуновение ветра, но тут уж земля бетоном тогда
>>1954177 > А стили и не должны управляться джсом. Джс управляет классами, стили применяются к ним В итоге реакт компоненты засраны этим управлением классами, в то время как в случае со стайледами просто аккуратно предаются пропы.
> Styled components как идея бред. Конечно, это работает, но даже простые стили выглядит как пиздец смесь CSS и JS, страшно представить как это выглядит в больших проектах с вложенными селекторами и со сложным CSS. Выглядят как sass, только не замусорены классами и дата-атрибутами.
> Поперхнулся. Как можно загрязнить то, что и так уже является грязной смесью разметки и кода? Если ты грядет пишешь JSX, то это твоя проблема.
> Просто любое реактоговно даже от реакторазрабов тормозит, видимо не родились еще люди которые могут идеально писать реакт код. У меня не тормозит, и у многих других.
>>1954185 Передаешь объект с возможными состояниями как проп один раз вместо говномесива из переключений классов и всё.
>>1954183 Чем лучше? Правильно, ничем. Дожили, даже в js-среде ретрограды есть, хотя казалось бы — самая динамичная среда в разработке.
>>1954197 >А что ты там в классах с десятикратным условным рендерингом понаписал Ну так не пиши классы с десятикратным условным рендерингом, поехавший. sass тут при чем? >У тебя есть один стайлед компонент Один на каждый пук в приложении и все стили с нуля пишешь? Или может они все-таки что-то между собой имеют общее? Если второе, то не один. >>1954202 >Передаешь объект с возможными состояниями как проп один раз вместо говномесива из переключений классов и всё. А в кастомный компонент ты объект с состояниями передать не можешь или как?
>>1954207 > А в кастомный компонент ты объект с состояниями передать не можешь или как? Каждый span в реакт компонент что ли оборачивать? И там разводить дрисню из переключения классов, когда я могу одной строчкой это через стайледы сделать?
В общем, хотелось бы увидеть реальные ощутимые примущества сасс перед стайледами. Но вот что-то ни разу никто не выложил пример, где было бы видно в коде, что сасс лучше стайледов.
>>1954197 >Дело тут в том, что стайледы находятся в одном месте и все, что там внутри происходит сразу же у всех на виду. А что ты там в классах с десятикратным условным рендерингом понаписал, не всегда знаешь даже ты сам. Не поверишь, селекторы по классам состояний тоже в одном месте находятся, в скоупе базового класса.
>>1954209 >одной строчкой это через стайледы сделать Как будто говно, которое ты импортируешь свой стайлед, не состоит из дрисни ифов. >Но вот что-то ни разу никто не выложил пример, где было бы видно в коде, что сасс лучше стайледов. Странно, что ты тоже нихуя не выложил, а доказывать тебе должны тебе.
>>1954210 >селекторы по классам состояний тоже в одном месте находятся, в скоупе базового класса. Ну теперь стал понятен уровень дискуссии. И вот такую срань ты предлагаешь в качестве альтернативы стайледам? Это так верстальщики свой загон охранять решили? Ну тогда понятно
>>1954209 >хотелось бы увидеть реальные ощутимые примущества сасс перед стайледами Нет дружок, речь как раз о том, что сасс делает все то же самое, что делает любая js-дрисня для стилей, но выглядит лучше, воспринимается легче, работает быстрее и понимается любым человеком, знакомым с азами css-html. Так что показывать и доказывать преимущество js-дрисни на сассом должен именно ты или другие подобные тебе, а не наоборот. Пока этих преимуществ не видно.
>>1954223 >Ну теперь стал понятен уровень дискуссии. И вот такую срань ты предлагаешь в качестве альтернативы стайледам? Твоя альтернатива - хранить такую же срань в отдельном модуле, заместо отдельного файла стилей. >Это так верстальщики свой загон охранять решили? Неплохая боль неосилятора CSS, языка для макак между прочим. Интересно конечно про загоны слушать от жсдебила, который даже свою маму в скрипте хранит.
>>1954224 Толстота полилась. Покажи компонент кнопки, который может иметь 3 разных стиля, 2 разных варианта для мобильной и десктопной версии, состояние активно и заблокировано. И чтобы в любой момент ты мог 3 изначальных стиля расширить. Мне страшно представить какое количество говна ты туда понапишешь своим сасасом, который ты сам не сможешь разобрать уже через полчаса после написания.
>>1954226 >неосилятора CSS Ну тут уже в шепот, как будто бы я не верстал никогда сложных интерфейсов, и решил на стайледы перейти просто из вредности тебе, хуя маняутешения сразу нашлись
>>1954242 Ну вот о том и речь, теперь подумай как это выглядит на самой кнопке, где у тебя будет миллиард условий для рендера отдельных классов, вместо тех же самых условий в самих полях стилей которые видны сразу. Ты ушел не так далеко от того, чтобы сделать это еще удобнее. 3 вида кнопки, это изначальные стили, а уже к ним применяется состояние активно или заблокировано, в итоге тебе все равно нужно будет создавать отдельный компонент, который еще и стили будет подгружать, вместо того чтобы этот компонент изначально на стайлед компонентах и сделать чел пчел пчелибас, тут просто не может быть никакого смсысла в добавлении стилей к тому, что изначально стилями можно описать
>>1954244 Не вижу твоего варианта, видимо не прикрепилось. Попробуй еще раз. >как это выглядит на самой кнопке <button className="btn btn-primary"/> >в итоге тебе все равно нужно будет создавать отдельный компонент Создам я его только тогда, когда он мне понадобится, не раньше. У меня же нет невынимаемой sc-затычки в жопе, которая требует кастомного комопнента на любой пук.
>>1954251 То, что ты мне показал, вообще к изначальному условию, которое я описал не применимо. Очень похоже на то, что ты просто верстальщик, и не хочешь терять своё место, либо учить js ><button className="btn btn-primary"/> Даже в этом простейшем примере у тебя уже на первой же итерации начала выходить дристня. Объясни мне, а лучше сначала себе, зачем в этой цепочке нужна прослойки из css классов?
>Не вижу твоего варианта, видимо не прикрепилось. Попробуй еще раз. Я твоего тоже не увидел, но забавно то, что даже в твоём урезанном до предела примере всё уже выглядит как говно. Представь, что у тебя btn-primary1, btn-primary2, btn-primary3, для каждой active, disabled, и для каждого варианта wide/mobile. И попробуй убедить себя в том, что классами это можно сделать элегантнее и читабельнее. И это при том, что тебе все равно нужно будет создавать компонент. В итоге ты сделаешь бессмысленную прослойку видимо только из вредности мне?
>>1954258 >То, что ты мне показал, вообще к изначальному условию, которое я описал не применимо Шизик, твое начальное условие описанное тобой же, это: 3 разных стиля, 2 варианта для мобильной и десктопной версии и два состояния. Все соблюдены до точки. Что ты там нафантазировал у себя в голове я прочитать не могу, только то, что написано текстом. >Объясни мне, а лучше сначала себе, зачем в этой цепочке нужна прослойки из css классов? Ну наверное потому что просто кнопка и кнопка с primary стилем - это разные кнопки и это стандартная практика шеринга стилей, чтобы их не дублировать несколько раз в итоговом коде? Лично ты можешь сделать миксин кнопки и включать его внутри btn-danger/btn-primary, тогда даже btn писать будет не нужно, если готов заплатить за это несколько килобайтов. Разрешаю. >Представь, что у тебя btn-primary1, btn-primary2, btn-primary3 Представить не могу, если не дебил с цифрами в классах. То, как мои кнопки будут выглядеть, я уже написал: <button className="btn btn-primary" disabled={isDisabled}/> <buttom className="btn btn-danger" disabled={isDisabled}/>
Расскажешь, почему для это вдруг "нечитабельно" и как js-дрисня сделает это лучше? И все еще жду пример твоей js-дрисни, а то в воздух ты пердел-пердел о конкретике, а в итоге сливаешься без примеров.
>>1954214 Сначала дай хоть один внятный аргумент чем архаичный sass лучше стайледов.
>>1954215 > Как будто говно, которое ты импортируешь свой стайлед, не состоит из дрисни ифов. Ничего никуда не импортируется, пропы в стайледы прикидываются как в обычных реакт компонентах и дрисни из ифов нигде нет. Только однострочные тернарники.
> Странно, что ты тоже нихуя не выложил, а доказывать тебе должны тебе. Первым было утверждение, что стайледы говно, вот и доказывайте, сасс-шизы
>>1954224 > Нет дружок, речь как раз о том, что сасс делает все то же самое, что делает любая js-дрисня для стилей, но выглядит лучше, воспринимается легче, работает быстрее и понимается любым человеком, знакомым с азами css-html Но стайлдеы могут всё то же, что и сасс, но при этом больше из-за возможней js. Стайледы выглядят красивее и легче воспринимаются, потому что в них нет дрисни из css-классов, и в них нет ничего сложного, из понимает любой человек, который уже работает с реактом.
>>1954299 >Но стайлдеы могут всё то же, что и сасс, но при этом больше из-за возможней js Каких возможностей тебе в сассе не хватает, подскажи? > Стайледы выглядят красивее и легче воспринимаются Перетолстил. >>1954302 Ну вот видишь, уже выглядит как дрисня с магическим кастомным DSL и у этих людей хватает наглости кукарекать про "неявность" сасса, а теперь возьми стандартный реакт компонент с десятком разных элементов. Будешь каждый раз хуячить 10-строчные импорты своих кнопок, таблиц, лейаутов?
>>1954302 Блен. Не обессудь пчел. Как по мне это всё слишком нагромождёно смотрится и читается. И это я так понял маленькая простыня, а если большой компонент будет...
>>1954342 По объему не больше sass, так что не вижу нагромождения. Ну и читается не сложнее, как по мне, тем более подсветка синтаксиса в vscode лучше, чем в codesandbox. Огромный компонент будет не больше, чем sass, но удобнее. Выше в треде был пример с sass, там не меньше объём.
>>1954337 > Каких возможностей тебе в сассе не хватает, подскажи? Возможностей js, очевидно.
> Будешь каждый раз хуячить 10-строчные импорты своих кнопок, таблиц, лейаутов? Импорт всего лишь несколько строк в начале файла занимают, это вообще не мешает, в отличие от засирания jsx css-классами и логикой из переключения. Но ещё одно преимущество стайледов в том, что локальные компоненты можно объявлять прямо внутри реакт компонента, а импорты будут только для общих компонентов типа кнопок.
>>1954350 Попробовал этот стайлед, если размещать стили в самом компоненте приходится туда сюда скролить постоянно, хуй знает с другой стороны удобно что все в одном месте, прям пиздец хуй знает че делать
>>1954350 >Возможностей js, очевидно. Каких? Одну назовешь? >в отличие от засирания jsx css-классами То есть засирание импортами говна тебе не мешает, а обычные html-классы вдруг мешают? Ты поехавший? >и логикой из переключения Не засирай, вынеси логику переключения в отдельный компонент, прямо как выносишь любую другую. Зачем тебе для этого ебаный sc? >Но ещё одно преимущество стайледов в том, что локальные компоненты можно объявлять прямо внутри реакт компонента Это называется "антипаттерн" и "говнокод", а не "преимущество".
>>1950886 (OP) Нужно получить JSON с данными с сервера. Есть условие, что в респонсе должен быть ответ со значением {stop: true}, тогда типа все ок, JSON готов. Я решил поиграться в браузере - вбил строку с реквестом, и смотрю в консоле респонс, там stop всегда false (пробовал отправлять реквест несколько раз снова и снова, в итоге сервер просто обрубил меня). Это как - в промисе ждать, пока в респонсе тру не будет, не резолвить? Или другой способ? Почему в браузере не получается?
>>1954342 Чел пчелибас, то, что ты видешь это буквально весь код. То, что высрал сасасозащитник, это только css код, который уже выглядит хуже и каждый пук еще и свой УЖАСНЫЙ НЕНУЖНЫЙ JS КОД будет просить, но этого он отчаяно не хочеть видеть и не хочет показывать
Когда через скрипты меняем например текст в html документе.
Где хранится этот измененный DOM ? В кэше?
Типо если обновить страницу, то HTML страница возвращается к стандартному DOM который был прописан в HTML до выполнения скрипта. Измененный DOM типа временный получается.
Как бы мне SASS не нравился, но он пососет, когда надо будет делать стилизацию вложенных компонентов. В SASS амперсанд селектор нельзя ставить не в начале селектора, а в SC можно (&&). Это нужно для правильной семантики, не всегда родительский компонент должен диктовать как выглядит дочерний. Также CSS-in-JS позволяет лучше отслеживать модули и их импорты, что упрощает рефакторинг и переход к имплементации по клику в IDE. В SC ты можешь импортировать компонент и вставить в литерал вместо CSS класса компонента, что не позволяет оставить старое имя класса, после его переименования. Все, что по факту предъявляют SASS-шизы в треде - импакт по производительности. Который на деле является микроскопическим, если ты делаешь все правильно и не дрючишь стили 60 раз в секунду. А если ты настроишь SSR, то этот импакт вообще устремится к нулю.
Про отвал всего приложения на SC: приложение надо тестировать и ошибки оборачивать в ErrorBoundary
>>1954666 можешь border заменить на box-shadow, он не будет ничего сдвигать. Если игнорировать сам факт того, что ты делаешь какую-то хуйню. Ну или просто использовать гриды
>>1954353 > Каких? Одну назовешь? Уже не раз назвал возможность передавать пропсы, например, или темизация, но ты копротивляешься ради архаичного пердолинга с классами, дата-атрибутами и написанием большего количества кода просто потому что у тебя иррациональная неприязнь к новым, более функциональным инструментам. Сасс-шизы это прямо неолуддиты из мира фронтенд разработки.
> То есть засирание импортами говна тебе не мешает, а обычные html-классы вдруг мешают? Ты поехавший? Импорты во-первых ничего не засирают, их вообще не видно потому что они в самом начале файла, а вот css-дрисня гадит прямо посреди jsx.
> Не засирай, вынеси логику переключения в отдельный компонент, прямо как выносишь любую другую. Зачем что-то куда-то выносить и засирать проект лишними файлами, когда я могу в стайледах аккуратно, красиво и удобно а одну или пару строк это сделать?
> Это называется "антипаттерн" и "говнокод", а не "преимущество". Ты скозал? Single file components в vue тоже антипаттерн? Лол. Я для тебя ещё раз повторю: внутри реакт компонента иногда люди могут оставлять локальные стайледы. Common вещи вносятся в отдельные файлы, очевидно. Но импорты — это последнее, что засирает код, потому что их тупо не видно на экране во время работы.
>>1954555 >возможность передавать пропсы sass у тебя эту возможность не отнимает, хочешь - делай логику и передавай. В 99% случаев тебе так и так нужно эту логику писать, потому что это рабочая логика приложения, а стили просто приходятся сверху дополнением, как и должны. Схуев ли ты решил, что завязывать стилизацию и рабочую логику переключения стейта в одно месиво это хорошая идея - большой вопрос. >или темизация Что тебе мешает сделать темизацию css-методами вместо ре-рендеринга всего приложения нахуй? >написанием большего количества кода Но больше кода пишут как раз sc-шизы, потому что выкидывают в окно готовые инструменты(html-классы) и пердолятся со своим инлайн говном и кастомными компонентами. >их вообще не видно потому что они в самом начале файла Охуительные истории, 30 строчек импортов - это заебись, они в начале файла и их не видно. Представляю твои файлы. > Зачем что-то куда-то выносить и засирать проект лишними файлами См. выше. Логика переключения стейтов - это рабочая логика, и писать для нее "лишние файлы" ты будешь так и так. А если не будешь, то инлайн добавить класс по условию нихуя не проблема. >Ты скозал? Single file components в vue тоже антипаттерн Да, я скозал. Что там в vue не ебу, но хуярить sc внутри комопнента - это точно то же самое, что хуярить инлайн-стили вместо классов. Почему это плохо и говнокод, можешь спросить в 2010 году, еще тогда все выяснили.
>>1954782 >Что там в vue не ебу Во .vue файлах пик, scoped аттрибут изменяет любой селектор и добавляет доп. условие, чтобы в других компонентах/дом элементах с таким классом ничего не применялось. Ну еще можно сделать <style lang="scss"> и у тебя сасс работает (да что угодно, главное чтобы вебпак понял о чем ты), импортируешь свои миксины и дрочишься. И еще можно несколько <style> тагов, например хочешь прямо из компонента срать в глобальные стили. Короче хз нахуя я это пишу но лично мне вью очень нравится тем что его можно постепенно очень хорошо внедрять в уже существующее легаси говно.
Подскажите такой вопрос. Есть сервер простой на экспрессе. Где хранить в нем всякие api keys и прочие приватные данные? Установить dotenv, и через него получать доступ к моему созданному файлу .env с переменными? А как в продакшене это будет работать ? Я сбилджу, мои переменные из моего файла закодируются и у приложения к ним будет доступ без dotenv?
>>1954850 Ну правильно я понимаю, что дотенв - пакет только для того что бы можно было из созданного мною файла брать переменные для разработки ? А в проде мои переменные подтянутся в окружение.
>>1954849 1) Создаешь .env файл, пишешь в него все свои ключи, добавляешь этот файл в .gitignore 2) Создаешь .env.example файл пишешь в него все те же самые ключи, только без секретных значений, чтобы можно было окружение воспроизвести на другой машине или другому разработчику без заебов. Коммитишь этот файл и обновляешь по мере надобности. 3) Добавляешь в README как часть сетапа строчку `cp .env.example .env` 4) На любом новом сервере с проектом просто выполняешь команду выше и заполняешь все ключи, либо проставляешь эти ключи в ENV переменные контейнера, если у тебя какой-нибудь докер, а файл оставляешь пустым.
>>1954434 >должен быть ответ со значением {stop: true} И что, вечно будешь ждать? Может сервер его не пришлет. Нужен лимит времени, setTimeout, установить какой-либо.
Начал проходить эпический курс по js на 100 часов.
Так вот в конце курса проходим реакт. А в начале щупаем es6 и пишем свою библиотек по типу jquery, мол что бы понимать как классы работают и вообще библиотеки. Пока сидели разбирали как jquery работает я чуть не охуел от перегрузки, эта тема действительно нужна или можно скипать и учить реакт?
Какие иде еще можете посоветовать кроме ВСК и ВЕбшторма для реакта+тс? В ВСК вроде бы неплохо, но в целом интерфейс какой-то тормознутый, я хз. Вебштормом пользуюсь полгода, даже платную версию купил, в целом все работает круто, но как доходит до каких-то нестандартных фич, он шлет тебя нахуй и отправляет в загон багрепортов, которые там годами висят.
Сейчас смотрю курсы htmlacademy по html, у кого-нибудь есть весь html и css файл по сайту barbershop? Курс невозможно смотреть, много воды + эти два деятеля не печатают код сами, а показывают какие-то картиночки. КАРТИНОЧКИ, БЛЯДЬ!!!
>>1955017 ну первый пик про версточку которая типа на работе учится и dom, к которому настоящие реакт-интеграторы не притрагиваются Знать конечно это все нужно, но ты же уснешь
второй - это ооп за 24 часа ы, объект - значит ооп)) и ajax через jquery. jsonp хорош для кругозора, cors на работе почитаешь
третий неплох, но вот эти декораторы через бабель поняты не будут. mobx для начала тоже сомнителен, надо сразу погружать в редакс, чтобы spacex dragon завидовал жопной тяге, но это субъективное
4 был бы норм, если бы побольше хуков и поменьше классов, ну и смотря что там в разделе про формы
Все эти полифилы для фетча попахивают 2018. Ну и ни слова про тайпскрипт.
>>1955027 Это все так, для общего кругозора, беру так сказать колличеством. А качеством буду брать на курсе буры, там по реакту полный порядок. Спасибо анончик, хорошего вечера!
>>1955004 Ну пизда в общем, видимо придется продать душу дъяволу и уходить обратно в ВСК. Пиздец конечно, бесплатный опенсурс уделал платный редактор. Нормально там у них вообще всё в джетбрейнсах? Голова не болит? Срут нормально?
>>1954585 Какой вопрос - такая, знаешь ли, и реакция, создается ощущение, что ты вообще не понимаешь что такое dom. Браузер получает html, браузер у себя в памяти строит модель по этому html - DOM, и показывает ее тебе. Если ты вносишь изменения в DOM - они разумеется не сохраняются в полученный с сервера html, даже если он кеширован, и сбрасываются, как только ты закроешь или обновишь вкладку.
>>1954782 >sass у тебя эту возможность не отнимает, хочешь - делай логику и передавай Как передавать? Через дрисню из классов и дата-атрибутов? Нет, спасибо.
>Что тебе мешает сделать темизацию css-методами вместо ре-рендеринга всего приложения нахуй? Неудобная и всратая ебля с css-переменными.
>Но больше кода пишут как раз sc-шизы Ну, это просто не так. Стайледы наоборот сокращают количество css-дрисни.
>Охуительные истории, 30 строчек импортов - это заебись, они в начале файла и их не видно. Схуяль 30 строчек? Сас-шиз, откуда ты себе это придумал?
>Что там в vue не ебу Охуенно. "Не читал, но осуждаю". Типичный долбоёб, которому лишь бы спиздаануть своё охуенно важное мнение о том, в чём он даже не разбирается.
>хуярить sc внутри комопнента - это точно то же самое, что хуярить инлайн-стили вместо классов Нет, не то же самое. Я скидывал codesandbox и там видно что это не так.
>>1955077 >Как передавать? Через дрисню из классов и дата-атрибутов? Через дрисню из пропсов, прямо как ты передаешь в sc >Неудобная и всратая ебля с css-переменными. Действительно, очень сложно 10 переменных объявить и поменять по мере нужды, лучше ре-рендерить инлайн дрисню во всем приложении каждый раз. >Я скидывал codesandbox и там видно что это не так. Там видно только то, что лично ты ленивый дурачок и написал все в одном файле. Если ты так пишешь в реальное приложение, 200 строк компонента и 100 строк стилей в один файл, то это нахуй из профессии.
>>1955094 > Через дрисню из пропсов, прямо как ты передаешь в sc Не вижу в sc дрисни, это же не цсс-классы
> Действительно, очень сложно 10 переменных объявить и поменять по мере нужды, лучше ре-рендерить инлайн дрисню во всем приложении каждый раз. Каждый раз? Один раз при смене темы, только делать это удобнее через ThemeProvider
> Там видно только то, что лично ты ленивый дурачок и написал все в одном файле. Если ты так пишешь в реальное приложение, 200 строк компонента и 100 строк стилей в один файл, то это нахуй из профессии. Всё — это что? Одну кнопку? Я говорил, что компоненты вроде кнопок выносятся в отдельные файлы потому что они для общего пользования. Но именно здесь кнопка используется только в одном реакт компоненте поэтому она объявлена в нём же
Не совсем понимаю, почему я до сих пор не услышал ни одного преимущества саса, сас-шиз? Даже преимущество в 0.0000001 ms скорости обходится через linaria (компиляция стайледов в цсс). Какие твои оправдания, сас-шиз?
>>1955142 Шизло, я же тебе сказал, преимущества должен указывать ты, потому что именно ты пытаешься заменить стандартные ксс-классы на дрисню из магических темплейт строк с функциями и бексконечными ?. && чеками на любой пук, не предоставляя своему шизобесию никаких оправданий, кроме пердежа "итажи жапаскрипт, значит он удобнее". Пока преимуществ, кроме "можно серить там же, где и ешь" я не услышал. Пытайся лучше.
Аноны, подскажите, пожалуйста, где можно попрактиковаться в браузерном джаваскрипте? Не всякие задачки, которые можно и на других языках решить, а именно проработать всякие добавление/удаление узлов, фетчи, события, координаты окна/документа, формы итд
>>1955153 >>1955094 Шизы, хватит срать. Просто покажи мне условный медиазапрос в css, когда у тебя один и тот же элемент должен делать запрос по разной ширине, если к примеру слева какая-то менюшка открыта или закрыта. И таких медиазапросов у тебя может быть 4 штуки. В СК это делается парой строчек. В ЦСС ты будешь срать кровавым поносом
>>1955172 >если к примеру слева какая-то менюшка открыта или закрыта Ты ради всплывающих менюшек будешь весь лэйаут пидорасить? Но вообще-то относительные величины поддерживаются даже третьим эксплорером. Теперь понятен психопрофиль потребителей стайлед элементс.
>>1955177 Психопрофиль стайлед-бояр: стремятся изучать новое, применяют современные, более функциональные инструменты в разработке. В отличие от сас-шизов не стремятся пилить бревно перочинным ножичком, а используют для этого бензопилу. Быстрее делают свою работу благодаря более рациональному подходу и владению эффективными инструментами. В них живёт дух молодости, исследования, открытости, прагматичности. Предпочитают находиться в авангарде технологий, их стек всегда востребован, им постоянно предлагают работу с всё более крупной компенсацией, их любят коллеги-зумеры и тяночки из HR-отдеда, а коллеги-бумеры их боятся и избегают зрительного контакта с ними. Их профиль на линкедине спамят рекрутеры из США, Австралии, Сингапура и Нидерландов, в то время как сас-шизы довольствуются редкими подачками предложений с пост-советских актсорс-параш.
Психопрофиль сас-шизов: ретрограды, имеют нездоровую привязанность к архаичным моделям, их психика утратила гибкость и подвижность. В общем, это закостенелые бумеры, боящиеся вылезти из зоны комфорта. Неолуддиты из мира разработки интерфейсов. Отсутствует понимание о том, что такое чистота в коде, эстетика им чужда. Любят защищать громоздкие конструкции, к которым они привыкли, ведь из-за ригидной психики новые изменения приносят им боль. Их существование наполнено страхом потерять работу из-за неактуально стека технологий, который они используют. Фронтенд разработка приносит особенно много боли сас-шизам, ведь здесь скорость изменения технологий наиболее высокая. Сас-шизов презирают сообществах наиболее сильных и высокооплачиваемых разработчиков. Им рады только на галерах, где они могут с радостью для себя дрочить легаси сас-дрисню за низкий прайс, после чего спустя несколько лет они будут вытеснены с рынка из-за выборочного эйджизма, который не применяется к светлым умам стайлед-бояр, в которых живёт дух молодости даже в солидном возрасте.
>>1955179 >стремятся изучать новое Писание стилей в жс так же старо, как сам жиквери. Скорее переизобретают велосипед, причём с гексагональными колёсами и с нечётным количеством этих колёс. Зато новое!
>>1955172 Любую сложную хуйню, вроде вычисления ширины динамически на основе ширины других элементов, делать нужно через жс и изолировать от всего остального, а не пытаться накостылять это через медиа-запросы и стандартные стили.
>>1955231 ну первая просто посмотреть что у меня в стейт отправилось вторая для клика чтобы number передавался в стейт легче будет использовать хуки для этого, но мне интересно почему это не работает и что я сделал не так
>>1954025 Ахахахах Что это за ебанибала? Вы поехавшие? Наху вы выжимаете из бедного языка все соки как баба постирушка на реке Чем вам дефолтные инструменты не нравятся?
Жиквери до сих пор применибельный если лень много писать ебанины для васяна за 5000 сайт. Ты небось и в лендос интерактивную кнопку без энпиэма не пойдешь добавлять.
>>1955579 Проблемы нет, есть вопрос, как распределить время. По Реакту много вакансий, поэтому буду учить его. Хочу знать, сколько месяцев надо учить/практиковать JS перед Реактом.
>>1955646 я думал,что можно допустим нажать 10 кнопок(они должны подсветится красным),а рядом в форме шло перечисление того,что я нажал и потом одной кнопкой это все отправить пхп и в БД(советуют жсон формат исп)чтобы не херачить кучу колонок в БД
Сап, фронты, скажите как вебсервис должен отдавать файлы на фронт, пишу апи и понадобилось отдавать mp3, быстро глянул что там есть какие-то обертки для этого, возник вопрос как именно на фронте рендеряться медиа файлы, мне, например нужно сделать так как я понимаю, у пользователя есть список mp3, его фронт получает с запроса на аудио, списоком, потом они загружаются с сервера, потом пользователь может из слушать, верно? Так вот вопрос, написать api по которому можно просто скачать один файл это рабочий вариант? Как в таком случае обычно еще json отдаеться с названием, описанием и датой создания? Отедльный запрос делать на инфу по первичному ключу аудио? Помогите разобраться
>>1955863 при запросе вроде должен быть правильный майм тип, а он в хедерах отдается, хотя энивей хз важно ли это для фронта, ладно браузер понимает что делать, типа если майм тип мп3, то открыть, хтмл парсить и т.д, а как фронт это использует вообще не знаю
Сюда же вопрос, вот я сделал 2-мя способами отдачу файла - 1. Возвращает по урлу мп3 и он открывается в браузере и 2. По урлу файл скачивается, я даже не знаю как у гугля правильно спросить в чем разница, а главное как фронт с этим работать будет
>>1955893 Аудио и видео на клиентской стороне в большинстве случаев обрабатывается через `<audio>` и `<video>` тэги, которые по сути контейнеры для ссылок, как `<img>`. Хуй знает, что ты там собираешься писать, в том же экспрессе по дефолту настраивается папка `public`, которая и отдаёт файлы без всяких дополнительных движений. Если же надо оформлять ссылку на скачку, то достаточно указать `download` у ссылки. Если же прям надо кишочки работы апи того же `<audio>`, то тут только читать https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API или спеку.
>>1955918 А как-нибудь протестить эти теги можно? Паблик нельзя юзать, аудио считай голосовые сообщения и просто с медиа урла нельзя отдавать, нужна проверка прав, но при проверке получилось пока только именно скачивать, в обоих запросах и когда скачивается файл и когда именно в браузере появляется(как у картинок типа открыть оригинал, чисто картинка по урлу), в обоих запросах метод гет, майм тип один и тот же
>>1955932 >А как-нибудь протестить эти теги можно? Делаешь эти теги в шаблоне и можешь обтестироваться на тестовом сервере. >Паблик нельзя юзать, аудио считай голосовые сообщения и просто с медиа урла нельзя отдавать, нужна проверка прав, но при проверке получилось пока только именно скачивать Просмотри https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio#attributes и если никак проверку прав через аттрибуты не сделать, то придётся нырять в интерфейс HTMLAudioElement и там уже пердолить свою реализацию запроса прав.
>>1955554 >Ты небось и в лендос интерактивную кнопку без энпиэма не пойдешь добавлять Нахуя, если есть чистый жс. И исходя из этого, нахуя нужен жиквери, если все на чистом жс делается?
>>1955932 Да почти все медиасервисы так делают со статикой, урлы только хэшируют анально да от роботов прячут. Можешь при загрузке статики токен какой-нибудь в заголовке или запросе проверять для авторизации. Можешь файлы в статику складывать только после запроса за метаданными и потом удалять. Можешь DRM обмазаться если совсем упорот.
Аноны, я тут взялся пилить проект, который когда мне озвучивали я честно сказал что никогда сам от начала до конца не делал, но близкий опыт имею.
Суть моей части проекта в том чтобы написать полностью фронтенд, начиная от UI элементов с версткой до всей бизнес-логики работы с API. Проект сам это интернет-магазин PWA. Сделать надо на генераторе статических страниц Gatsby для оптимизона, при этом на него мне пришлось написать source-plugin для работы с их кастомным API. Сам Гатсби на реакте если что.
Ну так вот, я дал свой эстимейт закачику ио времени и цене, и уже поздно метаться, ибо по руками ударили, но я чет теперь думаю что я по неопытности взял слишком мало времени и денег и меня ждут бессонные ночи в попытках не проебать очередной дедлайн.
Дайте пожалуйста ваши примерные эстимейты на проект по времени и цене. ТЗ нет, потому что мне буквально точно также всё на словах раскидали, да знаю что пиздец, но кушать хочется.
Поясните, как этот ваш евент луп работает? Сколько не смотрю, не читаю - нихуя не пойму.
Возьмем к примеру нодовский модуль http представим, что я делаю 10 асинхронных запросов на удаленный сервер. Задачи ставятся в очередь, но не блокируют друг друга, т.е. возвращается ответ на запрос, который пришел первым, а не был первым поставлен в список задач.
Это что получается? Эти задачи выполняются параллельно? Т.е. не в одном потоке? Но нода однопоточна же. Гдето краем уха услышал, что многопоточность реализует не язык, а окружение, в котором язык выполняется, например в браузере - браузер, у ноды с++ (или что там).
>>1956212 Этим занимается движок браузера или ноды. И он не возвращает ответ. Он переводит промис в состояние фуллфиллд и запихивает ф-ю, которую ты вписал в then в конец очереди микрозадач.
>>1956191 >Но нода однопоточна же. Однопоточна в том смысле, что у тебя один event loop и одновременно может выполняться только одна строчка JS кода. Но fetch и setTimeout это не JS-код и они там могут быть хоть 100-поточными. Когда ты пишешь fetch то тебе в ЖС сразу (!) возвращается промис, на этом JS переходит к следующей строчке, а самим XHR занимается уже браузер и как -- это его дело. С таймером то же самое, ВСЕ джуны валятся на этой хуйне. setTimeout возвращает идентификатор таймера МГНОВЕННО и сразу после этого JS выполняется дальше, таймер тикает в браузере и когда таймер заканчивается, то браузер просто ставит переданный в setTimeout callback в очередь макрозадач. Ни таймеры ни XHR не являются фичей джаваскрипта, это фичи БРАУЗЕРА (ну или ноды или любого другого окружения).
>>1956253 Хорошо, как движок браузера понимает, когда значение зарезволилось и его можно перенести в состояние фулфиллд и отдать? Опрашивает промис раз в n миллисекунд?
>>1956273 В смысле опрашивает промис, чо ты несёшь? Движок браузера написан на С++ и он в случае с фетчем делает днс запрос, открывает соединение на нужный айпишник и шлёт туда байтики, потом получает обратно из сокета какие-то байтики, смотрит хорошие это байтики или не очень и в зависимости от этого переводит промис на стороне ЖС в одно из состояний фуллфиллд или реджектед. Ну или может быть он вообще достаёт файл из кэша, может из дискового, может из оперативки.
>Опрашивает промис раз в n миллисекунд? Што? Промис это просто объект в JS - его не опрашивают. Он создаётся и при создании получает значение пендинг. Потом он обязан быть переведён в фуллфиллед или реджектед, после чего в очередь микрозадач движком ставится соответствующая таска.
>>1956259 Можно сказать, что все асинхронные операции - это не ЖС? Т.е. жс просто имеет синтаксис для вызова этих операций в отдельном потоке и обработки результата, но сама работа делается устройством?
>>1956289 >Движок браузера написан на C++ В контексте Chrome -- да. Движок firefox например на джаве написан. >в случае с фетчем делает днс запрос, открывает соединение на нужный айпишник и шлёт туда байтики, потом получает обратно из сокета какие-то байтики, смотрит хорошие это байтики или не очень и в зависимости от этого переводит промис на стороне ЖС в одно из состояний фуллфиллд или реджектед. Так уже понятней. Вот это https://chromium.googlesource.com/v8/v8/+/3.29.45/src/promise.js?autodive=0/ вроде как реализация промиса в V8.
>>1956298 >все асинхронные операции - это не ЖС На практике да, это выглядит именно так.
>>1956298 >имеет синтаксис для вызова этих операций Да
>и обработки результата Обработку в том смысле, что он ставит задачу в одну из очередей, да. С самим результатом ты уже всё разбираешься сам в коде коллбэков своих.
>сама работа делается устройством Ответ на этот вопрос не относится к ECMAScript. Он знает, что промис рано или поздно будет фуллфилд или реджектед, на этом всё и это гарантируется. Будет там браузер поднимать для этого потоки, устанавливать соединения или пойдёт в кэш дисковый или в кэш памяти - ECMAScript'у категорически похуй.
>>1956306 Знание того, как оно устроено внутри в движке абсолютно бесполезно. По крайней мере на том уровне, пока ты не понимаешь досконально то, как это выглядит снаружи, что гарантируется, в каком порядке итд итп. А как только ты с этим разберёшься, то у тебя про внутренние детали браузера вопросы сразу и исчезнут, потому что это не имеет значения. Сам там был. Когда разберёшься с event loop, у тебя пропадёт неуверенность и непонимание того, чо в каком порядке происходит в твоем коде и почему оно так делает, и браузер тогда из твоего поля внимания исчезнет. Сейчас ты чтением исходников хрома пытаешься прикрыть пробелы в понимании, не трать время.
>>1956319 В последней ссылке есть буквально ответ на вопрос, который ты спрашивал выше. Вот прям буквально про fetch, поэтому я тебе эту ссылку и кинул.
И да, тот чел рассказывает ОЧЕНЬ душно и подробно, но я не советую на первой итерации скипать. На второй-третьей уже можно, ессно.
Алсо, далеко не все курсы с того сайта я бы рекомендовал. бОльшая часть там всё же неплохие, но есть и не очень удачные и просто запредельное говно.
>>1956298 >сама работа делается устройством? Не устройством, а окружением. JS это встраиваемый язык без средств ввода/вывода. Он нужен для программирования среды, в которую он встроен. А встроен он может быть куда угодно - браузер, нода, фотошоп, автокад, ардуино, и сотни других даже есть ядра операционной системы, где js engine работает в нулевом кольце и на нем ты можешь программировать, например, планировщик потоков этой операционки или аллокатор памяти.
Вот есть язык Lua, который исторически встраивают в игровые движки, чтобы писать игровую логику. Есть тысячи других встраиваемых языков программирования. ЖС ровно для того же нужен. Только он многим мощнее и выразительнее всех прочих встраиваемых, и с ортодоксальным синтаксисом.
Как побороть NPM зависимость? Вот делаю небольшой сайт, в принципе количество нпм пакетов в нем вообще ни на что не влияет. Но суть в том, что интересно было бы и самому реализовать какой-то функционал предоставляемый нпм пакетом, но если я буду пилить его руками, то уйдет очень много времени, а тут поставил и всё. Как вы пришли к тому, что все начали пилить руками? Как вообще понять, что что-то стоит затраченного времени? Хочется с одной стороны поднимать скилл, с другой не хочется тратить очень много времени на то, что кто-то до тебя уже сделал, и вроде бы тратить время заказчика на своё обучение тоже не очень-то прилично вроде как
>>1956422 >Как вы пришли к тому, что все начали пилить руками? Зачем? Руками имеет смысл пилить какие-то учебные вещи, чтобы разобраться с концепцией. А библиотеки - это глупо. Там очень много рутинной работы, которая к повышению скиллов отношения не имеет.
Запили реализацию async/await через генераторы, например. Хорошее упражнение. Займёт у тебя от 3 минут до 1 месяца и повысит твой скилл.
Читаю Кантора. До главы "Продвинутые функции" было всё понятно на 100%. Дальше понимание снизилось до 80-90%. Когда дошел до прототипов и наследований понимание снизилось до 60-70%. На промисах понимание упало до 50%. Главу с генераторами вообще два дня читал и перечитывал, плюс на других сайтах гуглил материалы на эту тему, чтобы понять каким образом работает передача значения в генератор. Потом вроде бы понял, а на следующий день осознал, что потерял понимание. Забил хуй, стал читать дальше - работа с ошибками, главу "Разное", манипуляции с DOM - там вроде как понятно, но память стала вообще дырявая, синтаксис вообще перестал запоминаться. Чё делать? Смогу ли я вкатиться, если даже базовые вещи не особо понимаю? Ещё верстаю как дебил, не по БЭМу. Не умею в анимации, раскрывающиеся менюшки, попапы и т.д. - копирую готовые. Адаптивность делаю через жопу: верстаю сперва ПК-версию, потом начинаю понемногу уменьшать разрешение экрана (инструмент "Адаптивный дизайн" в Firefox), и когда какой-нибудь элемент перестаёт вписываться, то я останавливаюсь и через media-запрос прописываю для него новые свойства. Мне кажется, что по-умному это делается как-то иначе
>>1956689 >Вот в такие моменты решается сможешь ты вкатиться или нет. Либо бери себя в руки и долбись дальше, либо бросай это дело и пиздуй на завод. Или вкатиться, или умереть. На завод не смогу.
>>1956671 >Мне кажется, что по-умному это делается как-то иначе Правильно кажется. Есть определённый набор разрешений под которые стараются адаптировать. Чем больше набор тем больше бабла берут. Алсо, по моему опыту mobile-first делать легче.
Что за хуйня со Slick-слайдером на мобилках? Объясните раку. В адаптиве на ПК слайдер работает, когда переношу папку с файлами на телефон, слайдер отлетает. Сами стили телефон видит (решил через Total Commander), но слайдер тупо слетает. Responsive прописывал - не робит. В чем трабла? В том, что слайдер не робит таким образом, если я переношу папку непосредственно на смартфон?
>>1950886 (OP) Нужно ли подчищать что-то вил анмаунтом после того как зафетчил что-то? Например как у меня сейчас, я фетчу с апи мои обьекты, массив полученный записываю в стейт, по вил апдейту этот стейт перезаписывается (с переходом на новую страничку) Заметил что иногда страницы подружаются по 6 секунд (там 8 картинок 200х200 и чуть текста), иногда как-то подлагивает мб из-за того что где-то не анмаунтнул?
>>1956671 >Ещё верстаю как дебил, не по БЭМу Так наоборот, дебилом бы был, если бы верстал по полностью устаревшей и ненужной отрыжке яндекса из 2010 года, вместо того, чтобы пользоваться сассом.
>>1956732 >иногда страницы подружаются по 6 секунд Ну ты в девтулз посмотри сколько запрос выполняется. У тебя в теории могут быть утечки только когда руками вешаешь события.
Сап, двач. В чем проблема: есть iframe, я пытаюсь обратиться к его полю. Захожу в исходный код, смотрю нужный мне name, пишу в консоли documebt.getElementByName - все ок, нужное мне поле находится. Стоит мне обновить страницу, как все ломается и это поле больше не находится, пока я снова не зайду в исходный код и не найду его. Вар Ант того, что я меняю его кликом, пока ищу его в исходном коде исключен. Понимаю, что мало вводных, скажите, если что то ещё нужно. Жс я знаю на уровне гугления и пишу маленькое расширение для хрома для себя
>>1956732 Анмаунт нужен в основном чтобы отписываться от каких-либо событий, хз что ты там хочешь подчищать, учитывая, что стейт и так очищается после удаления компонента. Хз что у тебя с картинками, но по хорошему ты их ниоткуда скачивать не должен, должен быть хостинг изображений и ты просто вставляешь ссылку оттуда в <img />, тогда это никак работу сайта стопать не будет.
Продолжаем изучать джава скрипт вместе с аноном. Сегодня мы с помощью библиотеки JQuery и функции animate придаем нашей страничке немного мобильности и живого вида!
Так же мы научимся как делать всплывающий upbutton.
>>1956495 >Но ведь async/await это обертка над промисами... Каким образом у тебя промис может "остановить" выполнение функции, расскажи мне, пожалуйста. await может. и yield может.
>>1956638 В ещё одну отдельную очередь. Макротаски дёргаются из очереди строго по одной за итерацию лупа. Микротаски выполняются за одну итерацию все по очереди, причём, если ты будешь на лету добавлять микротаски (синхронно резолвить промисы, например), то ты застарвишь очередь (это будет выглядеть как while (true) по сути). А коллбэки rAF выполняются когда браузер решит, что он готов рендерить и они выполняются за одну итерацию все, если их несколько, но вновь добавленные уже уйдут на следующую итерацию.
Больше пары строк кода в посте или на скриншоте ведут в ад.
Для программирования на HTML https://codesandbox.io
Для Node.js с консолькой https://repl.it/languages/nodejs
Если рассчитываешь получить дельный ответ, сформулируй правильно вопрос: «что я хочу получить, что я для этого делаю, что я вместо этого получаю». Если когда самостоятельно найдёшь решение — поделись в треде, мы за тебя переживаем.
Документация - https://developer.mozilla.org
Руководство для вката - https://github.com/acilsd/wrk-fet#javascript
Старая паста, частично устарела - https://pastebin.com/9yRADC0s